HMAC-, PBKDF2 & HKDF-laskin

Laske avainpohjainen viestin todennuskoodi HMAC-MD5-, HMAC-SHA-1-, HMAC-SHA-256-, HMAC-SHA-384- tai HMAC-SHA-512-algoritmilla (RFC 2104) tekstille, heksatavuille tai kokonaisille tiedostoille — avaimet tekstinä, heksana tai Base64:nä. Tai johda avaimia PBKDF2-algoritmilla (RFC 8018) ja HKDF-algoritmilla (RFC 5869). Jokainen tulos voidaan esittää heksana, isoilla kirjaimilla heksana, Base64:nä tai Base64url-muodossa. Tavallisille tiivisteille katso Tiivistegeneraattori; tarkistussummille katso CRC-laskin; JWT:n sisällä käytettävälle HMAC:lle katso JWT-purkaja.
Toimii kokonaan paikallisesti — avaimet ja viestit eivät koskaan poistu välilehdeltä. Tiedostot enintään 200 MB.
Rakenne: Tulos:
HMAC-algoritmi: RFC 2104 — MD5-muunnelma vaatii md5.js:n (ladataan tältä sivulta).
Salainen avain (jaettu salaisuus; mikä tahansa pituus, alla oleva teksti koodataan UTF-8:na)
Heksatulkinta sietää välilyönnit, kaksoispisteet ja 0x-etuliitteet; Base64 on oltava tavallinen muoto täytteellä tai ilman.
Tyhjä avain on sallittu RFC 2104:n mukaan, mutta lähes aina virhe — HMAC ilman avainta on vain hidas tiiviste.
Viestiteksti (todennettava data, UTF-8-koodattu)
HMAC-tulos (yksi rivi: rakenne, parametrit, arvo)
Ensimmäinen rivi kirjaa käytetyt tarkat parametrit (algoritmi, tulkinta, syötekoot), joten kopioitu tulos on aina toistettavissa.
Mikä rakenne on tarpeen?
HMAC muuntaa jaetun salaisuuden ja viestin todentimeksi: avaimen tunteva vastaanottaja voi laskea sen uudelleen ja huomata väärennyksen. Se on jokaisen allekirjoitetun JWT:n sisällä oleva “HS256” (katso JWT-purkaja) ja puolet maailman API-pyyntöjen allekirjoitusjärjestelmistä. PBKDF2 venyttää ihmisen salasanan avaimeksi: se toistaa HMAC:ia tuhansia kertoja, joten jokainen salasanan arvaus maksaa hyökkääjälle saman viiveen. HKDF on protokollaavaimiin: se ottaa jo satunnaiset salaiset tavut (esim. DH-jaettu salaisuus) ja laajentaa ne turvallisesti useiksi tarkoitukseen sidotuiksi avaimiksi — TLS 1.3 johtaa kaikki liikenneavaimensa näin. Peukalosääntö: todenna → HMAC; salasana → PBKDF2 (tai scrypt/Argon2, katso Salasanatiivisteen generaattori, kun se on julkaistu); tasainen salaisuus → HKDF.
Itsetesti
Ajaa sivun moottorit julkaistuja vektoreita vastaan: 10 HMAC-ankkuria (RFC 2202/4231-tyyliin, viisi algoritmia × kaksi syötettä), 6 PBKDF2-ankkuria (SHA-1 ja SHA-256 kolmella iteraatiomäärällä) ja neljä RFC 5869 HKDF-testitapausta A.1–A.4. Mitään ei lähetetä minnekään.
HMAC, PBKDF2 ja HKDF — avainpohjainen tiivistys alusta asti selitettynä
Yhdellä lauseella: paljas tiiviste, kuten SHA-256, jonka kuka tahansa voi laskea, ei todista mitään siitä, kuka viestin lähetti — HMAC sekoittaa mukaan salaisen avaimen, joten vain avaimen haltijat voivat tuottaa (tai vahvistaa) tiivisteen; PBKDF2 ja HKDF käyttävät sitten samaa HMAC-koneistoa muuntaakseen salaisuudet avaimiksi, hitaasti salasanoille ja nopeasti jo satunnaiselle materiaalille.
Mikä HMAC on (RFC 2104)

Rakenne. HMAC on kaksi tiivistysajoa, ei yksi. Avain täytetään tiivisteen lohkokokoon (64 tavua MD5/SHA-1/SHA-256:lle, 128 SHA-384/512:lle); viesti tiivistetään kerran avaimen XOR kiinteän sisäisen täytteen kanssa, ja tuo tiiviste tiivistetään uudelleen avaimen XOR kiinteän ulkoisen täytteen kanssa. Tämä kaksinkertainen voileipärakenne on osoitettavasti turvallinen, kunhan taustalla oleva tiiviste on kelvollinen pseudosatunnaisfunktio — siksi HMAC-MD5 kestää yhä käytännön törmäyshyökkäyksiä, jotka rikkoivat tavallisen MD5:n (vaikka se on joka tapauksessa poistettu käytöstä, katso alla).

Avaimet. Mikä tahansa avaimen pituus toimii: lohkokokoa lyhyempi käytetään sellaisenaan (mutta alle 32 tavua katsotaan huonosti), pidempi tiivistetään ensin. Sama sivu sallii avaimen kirjoittamisen tekstinä, heksana tai Base64:nä, jotta 64 heksamerkin tuotantoavain voidaan liittää ilman, että se sekoitetaan 64 merkin tekstisalasanaan — tulkinta kirjataan tulostusriville juuri tästä syystä.

Missä sen kohtaa. JWT-otsakkeen HS256-kenttä on sanatarkasti HMAC-SHA-256 base64url-koodattujen tunnusosien yli (tämän sivuston JWT-purkaja laskee juuri sen, kun HS256-salaisuus liitetään). Webhook-allekirjoitukset (Stripe, GitHub), AWS SigV4, TLS-tietueen suojaus (vanhemmat versiot) ja OpenSSH:n umac-64@openssh.com-serkku kuuluvat kaikki samaan perheeseen.

Miksi ei vain hash(viesti || avain)? Pituuden laajennus: jokainen MD5/SHA-1/SHA-2-perheen tiiviste antaa hyökkääjälle, joka tuntee H(secret || msg), mahdollisuuden laskea H(secret || msg || padding || mitä tahansa) ilman salaisuutta. HMAC:n sisä- ja ulkojako tappaa tämän hyökkäysluokan. Se on yksittäinen yleisin tee-se-itse-virhe API-allekirjoituskoodissa — ja syy, miksi HMAC on olemassa.

Mikä PBKDF2 on (RFC 8018)

Suunniteltu hitaaksi. Salasanassa on ehkä 40 bittiä todellista entropiaa; hyökkääjän GPU kokeilee miljardeja raakoja SHA-256-laskentoja sekunnissa. PBKDF2 ajaa HMAC(password, salt):ia yhä uudelleen — iter kertaa — joten jokainen arvaus maksaa saman iter HMAC:ia niin puolustajalle kuin hyökkääjällekin. Oletus on täällä 600 000 iteraatiota HMAC-SHA-256:lla, OWASPin salasanojen tallennuksen huijauslehden perusarvo; liukusäädin ulottuu kymmeneen miljoonaan, koska tietoturvasuositukset nousevat laitteiston nopeutuessa.

Suola. Salasanakohtainen satunnainen suola tarkoittaa, että samat käyttäjät eivät enää tiivisty samalla tavalla, ja esilaskennat (sateenkaaritaulukot) muuttuvat arvottomiksi. Se ei ole salainen — se tallennetaan tiivisteen viereen — sen vain on oltava yksilöllinen. Yleisin on 16 satunnaista tavua.

Tunnettu heikkous. PBKDF2 on suorittimelle raskas mutta ei muistiraskas: GPU:t ja ASIC:t rinnakkaistavat sen erittäin hyvin. Siksi nykyinen suositus on scrypt tai Argon2id, kun salasanatiivisteen tallennusta suunnitellaan (tämän perheen Salasanatiivisteen generaattori-sivu kattaa ne), ja PBKDF2 on yhä oikea vastaus yhteensopivuus- ja FIPS-140-asetuksiin.

Mikä HKDF on (RFC 5869)

Ensin poimi, sitten laajenna. HKDF tekee kaksi tehtävää. Poiminta: puristaa mahdollisesti epätasaisen syöteavainmateriaalin (esimerkiksi Diffie–Hellman-jaettu salaisuus) suolan kanssa yhdeksi lyhyeksi pseudosatunnaiseksi avaimeksi PRK = HMAC(salt, IKM). Laajennus: venyttää tuon PRK:n mihin tahansa pituuteen enintään 255 tiivistelohkoa, ja jokainen ulostulolohko ketjutetaan edelliseen ja merkitään info-kentällä. Tuloksena yksi salaisuus voi turvallisesti antaa salausavaimen, MAC-avaimen ja IV:n, kaikki erillään toisistaan.

Ei salasanoille. HKDF olettaa, että sen syötteellä on jo täysi entropia — se tekee yhden HMAC:n 32 ulostulotavua kohden, joten ihmisen salasana kulkee sen läpi käytännössä välittömästi, juuri sen, mitä hyökkääjä haluaa. Salasanojen syöttäminen HKDF:n kautta PBKDF2:n sijaan on klassinen suunnitteluvirhe; info-kenttä on tarkoitusmerkinnöille ("client traffic key", "server iv"), ei lisäentropialle.

Missä sen kohtaa. TLS 1.3 johtaa jokaisen käyttämänsä avaimen kättelysalaisuudesta HKDF:n avulla; WireGuard, Signal, EAP-TLS 1.3 ja JSON Web Encryption (suorana avaimensopimus-KDF:nä) kuuluvat kaikki samaan sukupuuhun.

Ankkuriarvot — toista ne tällä sivulla

Kaksi ensimmäistä taulukkoa ovat testivektoreita, joihin tämän sivun Näyte-painike ja itsetesti perustuvat (avain "key", viesti “The quick brown fox jumps over the lazy dog”; sitten RFC-tyylinen tapaus, jossa on 16 tavun 0x0b-avain ja viesti “Hi There”). Kaikki on luotu itsenäisellä natiivitoteutuksella ja vahvistettu uudelleen tällä sivulla.

HMAC merkkijonolle “fox”, avain = keyTiiviste (hex)
HMAC-MD580070713463e7749b90c2dc24911e275
HMAC-SHA-1de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC-SHA-256f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA-384d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237
HMAC-SHA-512b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a
KDF-ankkuritParametritTulos (hex, ensimmäiset tavut)
PBKDF2-HMAC-SHA-1password / salt, c=4096, 32 tavua4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db
PBKDF2-HMAC-SHA-256password / salt, c=4096, 32 tavuac5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a
HKDF-SHA-256 (RFC 5869 A.1)IKM=0x0b×22, salt=00..0c, info=f0..f9, L=423cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865
HKDF-SHA-256 (RFC 5869 A.2)IKM=00..4f, salt=60..af, info=b0..ff, L=82b11e398dc80327a1c8e7f78c596a49344f012eda2d4efad8a050cc4c19afa97c…
HKDF-SHA-256 (RFC 5869 A.3)IKM=0x0b×22, tyhjä suola ja info, L=428da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8
Yleisiä virheitä
  • HMAC:n sekoittaminen salaukseen. HMAC todistaa eheyden ja alkuperän (jaetun salaisuuden perusteella); se ei piilota mitään. Jokainen ilman avainta näkee yhä koko viestin.
  • HMAC:n sekoittaminen allekirjoitukseen. Digitaaliset allekirjoitukset ovat julkisen avaimen menetelmiä: yksi allekirjoittaa, kuka tahansa vahvistaa. HMAC on symmetrinen: jokainen vahvistaja voisi myös väärentää. Kiistämättömyyteen tarvitaan RSA/ECDSA (katso tämän perheen RSA-työkalu, kun se on julkaistu), ei HMAC.
  • Avaimen tulkintaerot. Tekstiavainkenttään liitetty 64 merkin heksamerkkijono muuttuu 64 tavuksi, ei 32:ksi — ja HMAC muuttuu kokonaan. Tämä sivu tulostaa tulkinnan tulostusriville; kun kaksi työkalua ovat eri mieltä, se on ensimmäinen vertailtava asia.
  • PBKDF2:n liian alhainen iteraatiomäärä. 1 000 iteraatiota oli järkevä vuonna 2000; nykyään GPU-koneet syövät sen. Jos järjestelmä tallentaa yhä 1 000 iteraation tiivisteitä, suunnittele siirto, jossa tiiviste lasketaan uudelleen kirjautumisen yhteydessä.
  • HKDF salasanalle. Yksi HMAC ulostulolohkoa kohden tarkoittaa, että salasana kulkee läpi välittömästi — käytä salasanoille PBKDF2:ta (tai Argon2id:tä) ja HKDF:ää korkean entropian salaisuuksille.
  • Saman johdetun avaimen käyttö kaikkeen. Korjaus on ilmainen: johda erilliset avaimet eri info-merkinnöillä. Kaksi avainta yhdestä IKM:stä eri merkinnöillä ovat suunnittelultaan riippumattomia.
UKK

Onko HMAC-MD5 murtunut? Törmäysvastuksessa MD5 on kuollut, mutta HMAC-MD5:n turvallisuus perustuu MD5:een pseudosatunnaisfunktiona, eikä käytännöllistä murtoa tunneta. Joka tapauksessa se on poistettu käytöstä — ei ole syytä valita sitä HMAC-SHA-256:n sijaan muuten kuin yhteensopivuuden vuoksi vanhan protokollan kanssa.

Kuinka pitkä HMAC-avaimen pitäisi olla? Vähintään tiivisteen ulostulon koko (SHA-256:lle 32 tavua) ja luotu CSPRNG:llä. Tiivistettä lyhyempi avain on sallittu, mutta jokainen sen alapuolinen bitti heikentää suoraan turvallisuutta.

Muuttuuko PBKDF2 “turvallisemmaksi” loputtomiin, kun iteraatioita lisätään? Se nostaa hyökkääjän kustannuksia lineaarisesti, mutta myös kirjautumisen kustannukset lineaarisesti. Pelin ydin on valita suurin määrä, jonka käyttäjät sietävät — juuri sen OWASP:n luvut kalibroivat.

Miksi HKDF on rajattu arvoon 255 × tiivisteen koko? Laajennussilmukka on T(i) = HMAC(PRK, T(i-1) || info || i), jossa on yhden tavun laskuri i — 255 on suurin laskuriarvo, RFC 5869:n kova rakenteellinen raja, ei käytännön valinta.

Mikä on ero tämän sivun PBKDF2:n ja Salasanatiivisteen generaattorin välillä? Sama algoritmi, eri tehtävä. Tämä sivu johtaa raakoja avaintavuja käytettäviksi muualla; salasanatiiviste-sivu tuottaa tallennettavia tunnistetietomerkkijonoja (upotetulla suolalla ja parametreilla) ja vahvistaa liitetyt ehdokkaat niitä vasten.