HMAC-, PBKDF2- og HKDF-beregner

Beregn en nøglet meddelelsesautentifikationskode med HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 eller HMAC-SHA-512 (RFC 2104) over tekst, hex-bytes eller hele filer — nøgler som tekst, hex eller Base64. Eller afled nøgler med PBKDF2 (RFC 8018) og HKDF (RFC 5869). Ethvert resultat kan vises som hex, hex med store bogstaver, Base64 eller Base64url. For rene digests se Hash-generator; for checksums se CRC-beregner; for HMAC som brugt i JWT'er se JWT-dekoder.
Kører helt lokalt — nøgler og meddelelser forlader aldrig fanen. Filer op til 200 MB.
Konstruktion: Output:
HMAC-algoritme: RFC 2104 — MD5-varianten kræver md5.js (indlæst af denne side).
Hemmelig nøgle (delt hemmelighed; enhver længde, tekst nedenfor er UTF-8-kodet)
Hex-aflæsning tolererer mellemrum, kolon og 0x-præfikser; Base64 skal være i standardform med eller uden padding.
En tom nøgle er lovlig jf. RFC 2104, men er næsten altid en fejl — HMAC uden nøgle er bare en langsom hash.
Meddelelsestekst (de data, der skal autentificeres, UTF-8-kodet)
HMAC-output (én linje: konstruktion, parametre, værdi)
Den første linje registrerer de nøjagtige anvendte parametre (algoritme, aflæsning, inputstørrelser), så et kopieret resultat altid kan reproduceres.
Hvilken konstruktion er det, der skal bruges?
HMAC gør en delt hemmelighed plus en meddelelse til en autentifikator: modtageren, der kender nøglen, kan genberegne den og opdage manipulation. Det er “HS256” i hver signeret JWT (se JWT-dekoderen) og halvdelen af verdens API-anmodningssignaturer. PBKDF2 er til at strække en menneskelig adgangskode til en nøgle: den gentager HMAC tusindvis af gange, så hvert adgangskodegæt koster angriberen den samme forsinkelse. HKDF er til protokolnøgler: den tager allerede tilfældige hemmelige bytes (fx en DH-delt hemmelighed) og udvider dem sikkert til flere formålsbundne nøgler — TLS 1.3 afleder alle sine trafiknøgler på den måde. Tommelfingerregel: autentificér → HMAC; adgangskode → PBKDF2 (eller scrypt/Argon2, se Adgangskode-hash-generatoren, når den er udgivet); ensartet hemmelighed → HKDF.
Selvtest
Kører sidens motorer mod offentliggjorte vektorer: 10 HMAC-ankre (RFC 2202/4231-stil, fem algoritmer × to input), 6 PBKDF2-ankre (SHA-1 og SHA-256 ved tre iterationstal) og de fire RFC 5869 HKDF-testcases A.1–A.4. Intet sendes nogen steder.
HMAC, PBKDF2 og HKDF — nøglet hashing forklaret fra bunden
I én sætning: en nøgleløs hash som SHA-256 kan alle beregne, så den beviser intet om, hvem der sendte en meddelelse — HMAC blander en hemmelig nøgle ind, så kun nøgleholdere kan frembringe (eller verificere) digestet; PBKDF2 og HKDF genbruger så den samme HMAC-maskine til at gøre hemmeligheder til nøgler, langsomt for adgangskoder og hurtigt for allerede tilfældigt materiale.
Hvad HMAC er (RFC 2104)

Konstruktionen. HMAC er to hash-kørsler, ikke én. Nøglen polstres til hashens blokstørrelse (64 bytes for MD5/SHA-1/SHA-256, 128 for SHA-384/512); meddelelsen hashes én gang med nøglen XOR'et med et fast indre polster, og det digest hashes igen med nøglen XOR'et med et fast ydre polster. Denne dobbelte sandwich er bevist sikker, så længe den underliggende hash er en ordentlig pseudotilfældig funktion — derfor modstår HMAC-MD5 stadig de praktiske kollisionsangreb, der brød almindelig MD5 (selv om den alligevel er udfaset, se nedenfor).

Nøgler. Enhver nøglelængde virker: kortere end blokstørrelsen bruges som den er (men under 32 bytes ses skævt på), længere hashes først. Samme side lader én skrive nøglen som tekst, hex eller Base64, så en 64-hex-tegns produktionsnøgle kan indsættes uden at nogen forveksler den med en 64-tegns tekstadgangskode — aflæsningen registreres i outputlinjen netop af den grund.

Hvor man støder på den. Feltet HS256 i en JWT-header er bogstaveligt talt HMAC-SHA-256 over de base64url-kodede dele af tokenet (JWT-dekoderen på dette websted beregner netop det, når man indsætter en HS256-hemmelighed). Webhook-signaturer (Stripe, GitHub), AWS SigV4, TLS-postbeskyttelse (ældre versioner) og OpenSSH's umac-64@openssh.com-fætter hører alle til samme familie.

Hvorfor ikke bare hash(meddelelse || nøgle)? Længdeudvidelse: enhver hash i MD5/SHA-1/SHA-2-familien lader en angriber, der kender H(hemmelighed || msg), beregne H(hemmelighed || msg || padding || alt-muligt) uden hemmeligheden. HMACs indre/ydre opdeling udelukker den klasse af angreb. Det er den hyppigste hjemmelavede fejl i API-signaturkode — og grunden til, at HMAC findes.

Hvad PBKDF2 er (RFC 8018)

Langsom med vilje. En adgangskode har måske 40 bits reel entropi; en angribers GPU prøver milliarder af rå SHA-256 pr. sekund. PBKDF2 kører HMAC(adgangskode, salt) igen og igen — iter gange — så hvert gæt koster lige mange iter HMAC'er, både for systemet og for angriberen. Standarden her er 600.000 iterationer med HMAC-SHA-256, OWASP Password Storage Cheat Sheets basislinje; skyderen går op til ti millioner, fordi sikkerhedsvejledning skrues op, efterhånden som hardwaren bliver hurtigere.

Salt. Et tilfældigt salt pr. adgangskode betyder, at ens brugere ikke længere giver ens hashes, og forudberegnede tabeller (regnbuetabeller) bliver værdiløse. Det er ikke hemmeligt — det gemmes ved siden af hashen — det skal blot være unikt. 16 tilfældige bytes er normen.

Kendt svaghed. PBKDF2 er CPU-tung, men ikke hukommelsestung: GPU'er og ASIC'er parallelliserer det overordentlig godt. Derfor er det moderne råd scrypt eller Argon2id, når en adgangskode-hash-lagring designes (Adgangskode-hash-generatoren i denne familie dækker dem), mens PBKDF2 stadig er det rigtige valg for kompatibilitet og FIPS-140-indstillinger.

Hvad HKDF er (RFC 5869)

Udtræk, derefter udvid. HKDF har to opgaver. Udtræk: presse muligvis ujævnt inputnøglemateriale (fx en Diffie–Hellman-delt hemmelighed) sammen med et salt til én kort pseudotilfældig nøgle PRK = HMAC(salt, IKM). Udvid: strække PRK til en vilkårlig længde op til 255 hash-blokke, hvor hver outputblok kædes til den forrige og mærkes af feltet info. Resultatet er, at én hemmelighed sikkert kan give én krypteringsnøgle, en MAC-nøgle og en IV, alle adskilt.

Ikke til adgangskoder. HKDF forudsætter, at dets input allerede har fuld entropi — den laver én HMAC pr. 32 outputbytes, så en menneskelig adgangskode går igennem den praktisk talt øjeblikkeligt, præcis hvad en angriber ønsker. At føre adgangskoder gennem HKDF i stedet for PBKDF2 er en klassisk designfejl; info-feltet er til formålsmærkater ("client traffic key", "server iv"), ikke til ekstra entropi.

Hvor man støder på den. TLS 1.3 afleder alle nøgler, den bruger, fra håndtryksmemoriet via HKDF; WireGuard, Signal, EAP-TLS 1.3 og JSON Web Encryption (som direkte nøgleaftale-KDF) optræder alle på samme slægtstræ.

Ankerværdier — gengiv dem på denne side

De to første tabeller er testvektorerne, som denne sides Eksempel-knap og selvtest bygger på (nøgle "key", meddelelse “The quick brown fox jumps over the lazy dog”; derefter RFC-stilen med en 16-byte 0x0b-nøgle og meddelelsen “Hi There”). Alle blev genereret af en uafhængig, native implementering og gen-verificeret på denne side.

HMAC af “fox”, nøgle = keyDigest (hex)
HMAC-MD580070713463e7749b90c2dc24911e275
HMAC-SHA-1de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC-SHA-256f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA-384d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237
HMAC-SHA-512b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a
KDF-ankreParametreOutput (hex, første bytes)
PBKDF2-HMAC-SHA-1adgangskode / salt, c=4096, 32 bytes4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db
PBKDF2-HMAC-SHA-256adgangskode / salt, c=4096, 32 bytesc5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a
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
Almindelige fejl
  • At forveksle HMAC med kryptering. HMAC beviser integritet og afsender (givet en delt hemmelighed); den skjuler intet. Enhver uden nøglen ser stadig hele meddelelsen.
  • At forveksle HMAC med en signatur. Digitale signaturer er offentlig-nøgle-baserede: én signerer, enhver kan verificere. HMAC er symmetrisk: enhver verifikator kunne også forfalske. Til ikke-benægtelse behøves RSA/ECDSA (se RSA-værktøjet i denne familie, når det er udgivet), ikke HMAC.
  • Uoverensstemmelse i aflæsning af nøgler. En 64-tegns hex-streng indsat i en tekst-nøgleboks bliver til 64 bytes, ikke 32 — og HMAC'en ændrer sig fuldstændigt. Denne side skriver aflæsningen i outputlinjen; når to værktøjer er uenige, er det det første, man skal sammenligne.
  • PBKDF2-iterationer for lave. 1.000 iterationer var rimeligt i 2000; i dag æder GPU-rigge dem. Hvis systemet stadig gemmer 1.000-iterations-hashes, bør der planlægges en migrering med omhashning ved login.
  • HKDF på en adgangskode. Én HMAC pr. outputblok betyder, at en adgangskode går igennem øjeblikkeligt — brug PBKDF2 (eller Argon2id) til adgangskoder og HKDF til hemmeligheder med høj entropi.
  • At genbruge én afledt nøgle til alt. Løsningen er gratis: afled separate nøgler med forskellige info-mærkater. To nøgler fra ét IKM med forskellige mærkater er uafhængige pr. konstruktion.
Ofte stillede spørgsmål

Er HMAC-MD5 brudt? Som kollisionsmodstandsdygtig hash er MD5 død, men HMAC-MD5's sikkerhed afhænger af MD5 som pseudotilfældig funktion, og der kendes intet praktisk brud. Alligevel er den udfaset — der er ingen grund til at vælge den frem for HMAC-SHA-256, bortset fra kompatibilitet med en gammel protokol.

Hvor lang bør HMAC-nøglen være? Mindst hashens outputstørrelse (32 bytes for SHA-256) og genereret af en CSPRNG. En nøgle kortere end digestet er tilladt, men hver bit under den reducerer direkte sikkerheden.

Bliver PBKDF2 med flere iterationer ubegrænset “mere sikker”? Den hæver angriberens omkostning lineært, men også login-omkostningen lineært. Spillet er at vælge det største antal, brugerne vil tolerere — det er netop det, OWASPs tal kalibrerer.

Hvorfor er HKDF begrænset til 255 × hash-størrelse? Udvidelsesløkken er T(i) = HMAC(PRK, T(i-1) || info || i) med en tæller i på én byte — 255 er den største tællerværdi, en hård strukturel grænse i RFC 5869, ikke et politisk valg.

Hvad er forskellen på PBKDF2 på denne side og Adgangskode-hash-generatoren? Samme algoritme, forskellig opgave. Denne side afleder rå nøglebytes, som bruges andetsteds; adgangskode-hash-siden producerer lagrede legitimationsstrenge (med indlejret salt og parametre) og verificerer indsatte kandidater mod dem.