HMAC-, PBKDF2- & HKDF-kalkulator

Beregn en nøklet meldingsautentiseringskode med HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 eller HMAC-SHA-512 (RFC 2104) over tekst, heksbyte eller hele filer — nøkler som tekst, heks eller Base64. Eller avled nøkler med PBKDF2 (RFC 8018) og HKDF (RFC 5869). Hvert resultat kan vises som heks, store heksbokstaver, Base64 eller Base64url. For rene digester, se Hash Generator; for sjekksummer, se CRC-kalkulatoren; for HMAC slik det brukes i JWT-er, se JWT-dekoderen.
Kjører helt lokalt — nøkler og meldinger forlater aldri fanen. Filer opptil 200 MB.
Konstruksjon: Utdata:
HMAC-algoritme: RFC 2104 — MD5-varianten krever md5.js (lastet av denne siden).
Hemmelig nøkkel (delt hemmelighet; hvilken som helst lengde, teksten under kodes som UTF-8)
Heksleseren tåler mellomrom, kolon og 0x-prefiks; Base64 må være i standardform med eller uten utfylling.
En tom nøkkel er lovlig etter RFC 2104, men er nesten alltid en feil — HMAC uten nøkkel er bare en langsom hash.
Meldingstekst (dataene som skal autentiseres, UTF-8-kodet)
HMAC-utdata (én linje: konstruksjon, parametere, verdi)
Den første linjen registrerer de nøyaktige parametrene som ble brukt (algoritme, lesemåte, inndatastørrelser), så et kopiert resultat kan alltid reproduseres.
Hvilken konstruksjon trenger man?
HMAC gjør en delt hemmelighet pluss en melding om til en autentikator: mottakeren som kjenner nøkkelen kan beregne den på nytt og oppdage manipulering. Det er “HS256” inne i hver signert JWT (se JWT-dekoderen) og halvparten av verdens signeringsordninger for API-forespørsler. PBKDF2 brukes til å strekke et menneskelig passord til en nøkkel: den gjentar HMAC tusenvis av ganger, slik at hver passordgjetning koster angriperen samme forsinkelse. HKDF er for protokollnøkler: den tar allerede tilfeldige hemmelige byte (for eksempel en DH-delt hemmelighet) og utvider dem trygt til flere formålsbundne nøkler — TLS 1.3 avleder alle sine trafikknøkler på denne måten. Tommelfingerregel: autentiser → HMAC; passord → PBKDF2 (eller scrypt/Argon2, se Passordhasgeneratoren når den er publisert); uniform hemmelighet → HKDF.
Selvtest
Kjører sidens motorer mot publiserte vektorer: 10 HMAC-ankere (RFC 2202/4231-stil, fem algoritmer × to inndata), 6 PBKDF2-ankere (SHA-1 og SHA-256 med tre iterasjonsantall) og de fire RFC 5869 HKDF-testtilfellene A.1–A.4. Ingenting sendes noe sted.
HMAC, PBKDF2 og HKDF — nøklet hashing forklart fra grunnen av
I én setning: en nakenhash som SHA-256 kan alle beregne, så den beviser ingenting om hvem som sendte en melding — HMAC blander inn en hemmelig nøkkel slik at bare nøkkelholdere kan lage (eller verifisere) digesten; PBKDF2 og HKDF gjenbruker deretter den samme HMAC-maskineriet for å gjøre hemmeligheter om til nøkler, langsomt for passord og raskt for allerede tilfeldig materiale.
Hva HMAC er (RFC 2104)

Konstruksjonen. HMAC er to hash-kjøringer, ikke én. Nøkkelen fylles opp til hashens blokkstørrelse (64 byte for MD5/SHA-1/SHA-256, 128 for SHA-384/512); meldingen hashes én gang med nøkkelen XOR-et med et fast indre fyll, og den digesten hashes igjen med nøkkelen XOR-et med et fast ytre fyll. Denne dobbeltsmørbrødkonstruksjonen er bevist sikker så lenge den underliggende hashen er en brukbar pseudotilfeldig funksjon — og det er grunnen til at HMAC-MD5 fortsatt motstår de praktiske kollisjonsangrepene som knekte vanlig MD5 (selv om den uansett er utrangert, se nedenfor).

Nøkler. Enhver nøkkellengde fungerer: en kortere enn blokkstørrelsen brukes som den er (men under 32 byte frarådes det), en lengre hashes først. Den samme siden lar nøkkelen skrives som tekst, heks eller Base64, så en produksjonsnøkkel på 64 heksadesimale tegn kan limes inn uten at noen forveksler den med et 64-tegns tekstpassord — lesemåten registreres i utdatalinjen nettopp av den grunnen.

Hvor man møter den. HS256-feltet i en JWT-header er bokstavelig talt HMAC-SHA-256 over de base64url-kodede tokendelene (JWT-dekoderen på dette nettstedet beregner nøyaktig det når man limer inn en HS256-hemmelighet). Webhook-signaturer (Stripe, GitHub), AWS SigV4, TLS-postbeskyttelse (eldre versjoner) og OpenSSHs umac-64@openssh.com-slektning hører alle til samme familie.

Hvorfor ikke bare hash(melding || nøkkel)? Lengdeutvidelse: enhver hash i MD5/SHA-1/SHA-2-familien lar en angriper som kjenner H(hemmelighet || melding) beregne H(hemmelighet || melding || fyll || noe) uten hemmeligheten. HMACs indre/ytre deling dreper den klassen angrep. Det er den vanligste hjemmelagde feilen i API-signaturkode — og grunnen til at HMAC finnes.

Hva PBKDF2 er (RFC 8018)

Langsom med vilje. Et passord har kanskje 40 bit reell entropi; en angripers GPU prøver milliarder av rå SHA-256 per sekund. PBKDF2 kjører HMAC(passord, salt) om og om igjen — iter ganger — så hver gjetning koster de samme iter HMAC-ene for systemet og for angriperen. Standarden her er 600 000 iterasjoner med HMAC-SHA-256, OWASPs grunnlinje i Password Storage Cheat Sheet; glidebryteren går til ti millioner fordi sikkerhetsveiledningen øker etter hvert som maskinvaren blir raskere.

Salt. Et tilfeldig salt per passord betyr at identiske brukere ikke lenger gir identiske hasher, og forhåndsberegnede tabeller (regnbuetabeller) blir verdiløse. Det er ikke hemmelig — det lagres ved siden av hashen — det må bare være unikt. 16 tilfeldige byte er normen.

Kjent svakhet. PBKDF2 er CPU-tung, men ikke minnetung: GPU-er og ASIC-er parallelliserer den svært godt. Derfor er moderne råd scrypt eller Argon2id der lagring av passordhasher designes (Passordhasgeneratoren i denne familien dekker dem), mens PBKDF2 fortsatt er riktig svar for kompatibilitet og FIPS-140-innstillinger.

Hva HKDF er (RFC 5869)

Ekstraher, deretter utvid. HKDF gjør to jobber. Ekstraher: presser sammen nøkkelmateriale av muligens ujevn kvalitet (en Diffie–Hellman-delt hemmelighet, for eksempel) sammen med et salt til én kort pseudotilfeldig nøkkel PRK = HMAC(salt, IKM). Utvid: strekker PRK til en hvilken som helst lengde opp til 255 hash-blokker, der hver utdatablokk kjedes til den forrige og merkes av info-feltet. Resultatet er at én hemmelighet trygt kan gi en krypteringsnøkkel, en MAC-nøkkel og en IV, alle adskilt.

Ikke for passord. HKDF forutsetter at inndata allerede har full entropi — den gjør én HMAC per 32 utdatabyte, så et menneskelig passord går gjennom den praktisk talt øyeblikkelig, nøyaktig det en angriper ønsker. Å mate passord gjennom HKDF i stedet for PBKDF2 er en klassisk designfeil; info-feltet er for formålsetiketter ("client traffic key", "server iv"), ikke for ekstra entropi.

Hvor man møter den. TLS 1.3 avleder alle nøklene den bruker fra håndtrykkhemmeligheten via HKDF; WireGuard, Signal, EAP-TLS 1.3 og JSON Web Encryption (som den direkte nøkkelavtale-KDF-en) står alle i samme slektstre.

Ankerverdier — reproduser dem på denne siden

De to første tabellene er testvektorene som eksempelknappen og selvtesten på denne siden bygger på (nøkkel "key", melding “The quick brown fox jumps over the lazy dog”; deretter det RFC-lignende tilfellet med en 16-byte 0x0b-nøkkel og meldingen “Hi There”). Alle ble laget av en uavhengig, innfødt implementasjon og verifisert på nytt på denne siden.

HMAC av “fox”, nøkkel = keyDigest (heks)
HMAC-MD580070713463e7749b90c2dc24911e275
HMAC-SHA-1de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC-SHA-256f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA-384d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237
HMAC-SHA-512b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a
KDF-ankereParametereUtdata (heks, første byte)
PBKDF2-HMAC-SHA-1passord / salt, c=4096, 32 byte4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db
PBKDF2-HMAC-SHA-256passord / salt, c=4096, 32 bytec5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a
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, tomt salt og info, L=428da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8
Vanlige feil
  • Å forveksle HMAC med kryptering. HMAC beviser integritet og opprinnelse (gitt en delt hemmelighet); den skjuler ingenting. Den som ikke har nøkkelen, ser fortsatt hele meldingen.
  • Å forveksle HMAC med en signatur. Digitale signaturer er offentlig nøkkel: én signerer, alle kan verifisere. HMAC er symmetrisk: enhver verifiserer kan også forfalske. For ikke-benektbarhet trenger man RSA/ECDSA (se RSA-verktøyet i denne familien når det er publisert), ikke HMAC.
  • Avvik i nøkkellesing. En 64-tegns heksstreng limt inn i en tekstnøkkelboks blir til 64 byte, ikke 32 — og HMAC-en endrer seg fullstendig. Denne siden skriver lesemåten i utdatalinjen; når to verktøy er uenige, er det det første å sammenligne.
  • For lavt PBKDF2-antall iterasjoner. 1 000 iterasjoner var rimelig i 2000; i dag spiser GPU-rigger det. Hvis systemet fortsatt lagrer hasher med 1 000 iterasjoner, bør man planlegge en migrering der hashen byttes ved innlogging.
  • HKDF på et passord. Én HMAC per utdatablokk betyr at et passord går gjennom øyeblikkelig — bruk PBKDF2 (eller Argon2id) for passord og HKDF for hemmeligheter med høy entropi.
  • Å gjenbruke én avledet nøkkel til alt. Løsningen er gratis: avled separate nøkler med ulike info-etiketter. To nøkler fra samme IKM med ulike etiketter er uavhengige, som designet.
Ofte stilte spørsmål

Er HMAC-MD5 brutt? Som kollisjonsresistent hash er MD5 død, men HMAC-MD5s sikkerhet avhenger av MD5 som pseudotilfeldig funksjon, og ingen praktisk brudd er kjent. Den er uansett utrangert — det er ingen grunn til å velge den fremfor HMAC-SHA-256, bortsett fra kompatibilitet med en gammel protokoll.

Hvor lang bør HMAC-nøkkelen være? Minst hashens utdatastørrelse (32 byte for SHA-256) og generert av en CSPRNG. En nøkkel kortere enn digesten er tillatt, men hver bit under den reduserer sikkerheten direkte.

Blir PBKDF2 med flere iterasjoner “sikrere” i det uendelige? Den øker angriperens kostnad lineært, men også innloggingskostnaden lineært. Spillet er å velge det største antallet brukerne tåler — det er det OWASPs tall kalibreres etter.

Hvorfor er HKDF begrenset til 255 × hashstørrelse? Ekspansjonsløkken er T(i) = HMAC(PRK, T(i-1) || info || i) med en ett-byte teller i — 255 er den høyeste tellerverdien, en hard strukturell grense i RFC 5869, ikke et policyvalg.

Hva er forskjellen mellom PBKDF2 på denne siden og Passordhasgeneratoren? Samme algoritme, ulik jobb. Denne siden avleder rå nøkkelbyte for bruk andre steder; passordhashsiden lager lagrede legitimasjonsstrenger (med innebygd salt og parametere) og verifiserer innlimte kandidater mot dem.