HMAC-, PBKDF2- och HKDF-kalkylator

Beräkna en nyckelad meddelandeautentiseringskod med HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 eller HMAC-SHA-512 (RFC 2104) över text, hex-byte eller hela filer — nycklar som text, hex eller Base64. Eller härleda nycklar med PBKDF2 (RFC 8018) och HKDF (RFC 5869). Varje resultat kan visas som hex, versal hex, Base64 eller Base64url. För rena digester se Hash-generatorn; för kontrollsummor se CRC-kalkylatorn; för HMAC som används i JWT:er se JWT-avkodaren.
Körs helt lokalt — nycklar och meddelanden lämnar aldrig fliken. Filer upp till 200 MB.
Konstruktion: Utdata:
HMAC-algoritm: RFC 2104 — MD5-varianten kräver md5.js (som laddas av den här sidan).
Hemlig nyckel (delad hemlighet; valfri längd, texten nedan är UTF-8-kodad)
Hex-tolkningen tål mellanslag, kolon och 0x-prefix; Base64 måste vara i standardform, med eller utan utfyllnad.
En tom nyckel är tillåten enligt RFC 2104 men nästan alltid ett misstag — HMAC utan nyckel är bara en långsam hash.
Meddelandetext (data att autentisera, UTF-8-kodad)
HMAC-utdata (en rad: konstruktion, parametrar, värde)
Första raden anger de exakta parametrarna som användes (algoritm, tolkning, indatastorlekar), så ett kopierat resultat alltid kan återskapas.
Vilken konstruktion behöver man?
HMAC gör en delad hemlighet plus ett meddelande till en autentiserare: mottagaren som känner nyckeln kan räkna om den och upptäcka manipulation. Det är “HS256” i varje signerad JWT (se JWT-avkodaren) och halva världens API-signeringsscheman för förfrågningar. PBKDF2 används för att sträcka ut ett mänskligt lösenord till en nyckel: den upprepar HMAC tusentals gånger så att varje lösenordsgissning kostar angriparen samma fördröjning. HKDF är för protokollnycklar: den tar redan slumpmässiga hemliga byte (till exempel en DH-delad hemlighet) och expanderar dem säkert till flera ändamålsbundna nycklar — TLS 1.3 härleder alla sina trafiknycklar på det sättet. Tumregel: autentisera → HMAC; lösenord → PBKDF2 (eller scrypt/Argon2, se Lösenordshashgeneratorn när den publicerats); ensartad hemlighet → HKDF.
Självtest
Kör sidans motorer mot publicerade vektorer: 10 HMAC-ankare (i stil med RFC 2202/4231, fem algoritmer × två indata), 6 PBKDF2-ankare (SHA-1 och SHA-256 vid tre iterationsantal) och de fyra RFC 5869-testfallen för HKDF, A.1–A.4. Inget skickas någonstans.
HMAC, PBKDF2 och HKDF — nyckelad hashning förklarad från grunden
På en mening: en bar hash som SHA-256 kan vem som helst beräkna, så den bevisar ingenting om vem som skickade ett meddelande; HMAC blandar in en hemlig nyckel så att endast nyckelhavare kan producera (eller verifiera) digesten. PBKDF2 och HKDF återanvänder sedan samma HMAC-maskineri för att göra hemligheter till nycklar — långsamt för lösenord och snabbt för redan slumpmässigt material.
Vad HMAC är (RFC 2104)

Konstruktionen. HMAC är två hash-körningar, inte en. Nyckeln fylls ut till hashens blockstorlek (64 byte för MD5/SHA-1/SHA-256, 128 för SHA-384/512); meddelandet hashas en gång med nyckeln XOR:ad med en fast inre fyllnad, och den digesten hashas igen med nyckeln XOR:ad med en fast yttre fyllnad. Denna dubbla inramning är bevisligen säker så länge den underliggande hashen är en god pseudoslumpfunktion — därför motstår HMAC-MD5 fortfarande de praktiska kollisionsattacker som bröt vanlig MD5 (även om den ändå är utfasad, se nedan).

Nycklar. Vilken nyckellängd som helst fungerar: kortare än blockstorleken används som den är (men under 32 byte ogillas), längre hashas först. Samma sida låter nyckeln skrivas som text, hex eller Base64, så att en produktionsnyckel med 64 hex-tecken kan klistras in utan att någon förväxlar den med ett 64-teckens textlösenord — tolkningen anges på utdataraden just av den anledningen.

Var man stöter på den. Fältet HS256 i en JWT-header är bokstavligen HMAC-SHA-256 över de base64url-kodade delarna av token (JWT-avkodaren på den här webbplatsen beräknar exakt det när man klistrar in en HS256-hemlighet). Webhook-signaturer (Stripe, GitHub), AWS SigV4, TLS-postskydd (äldre versioner) och OpenSSH:s umac-64@openssh.com-kusin tillhör alla samma familj.

Varför inte bara hash(meddelande || nyckel)? Längdförlängning: varje hash i familjerna MD5/SHA-1/SHA-2 låter en angripare som känner till H(hemlighet || meddelande) beräkna H(hemlighet || meddelande || utfyllnad || vad som helst) utan hemligheten. HMAC:s inre/yttre uppdelning dödar den klassen av attacker. Det är det vanligaste hemmasnickrade misstaget i API-signaturkod — och anledningen till att HMAC finns.

Vad PBKDF2 är (RFC 8018)

Långsam med avsikt. Ett lösenord har kanske 40 bitar verklig entropi; en angripares GPU prövar miljarder råa SHA-256 per sekund. PBKDF2 kör HMAC(lösenord, salt) om och om igen — iter gånger — så varje gissning kostar lika många iter HMAC för både den legitima parten och angriparen. Standarden här är 600 000 iterationer med HMAC-SHA-256, OWASP:s baslinje i Password Storage Cheat Sheet; skjutreglaget går upp till tio miljoner eftersom säkerhetsvägledningen skärps i takt med att hårdvaran blir snabbare.

Salt. Ett slumpmässigt salt per lösenord gör att identiska användare inte längre får identiska hashar, och förberäknade tabeller (regnbågstabeller) blir värdelösa. Det är inte hemligt — det lagras bredvid hashen — det måste bara vara unikt. 16 slumpmässiga byte är normen.

Känd svaghet. PBKDF2 är CPU-hård men inte minneshård: GPU:er och ASIC:ar parallelliserar den utmärkt. Därför är den moderna rekommendationen scrypt eller Argon2id när man designar lagring av lösenordshashar (Lösenordshashgeneratorn i den här familjen behandlar dem), medan PBKDF2 fortfarande är rätt svar för kompatibilitet och FIPS-140-inställningar.

Vad HKDF är (RFC 5869)

Extrahera, sedan expandera. HKDF gör två jobb. Extrahera: pressa ihop möjligen ojämnt nyckelmaterial (en Diffie–Hellman-delad hemlighet, till exempel) tillsammans med ett salt till en kort pseudoslumpmässig nyckel PRK = HMAC(salt, IKM). Expandera: sträck ut PRK till valfri längd upp till 255 hash-block, där varje utdatablock kedjas till föregående och märks av fältet info. Resultatet är att en enda hemlighet säkert kan ge en krypteringsnyckel, en MAC-nyckel och ett IV, alla åtskilda.

Inte för lösenord. HKDF förutsätter att indata redan har full entropi — den gör en HMAC per 32 utdatabyte, så ett mänskligt lösenord passerar den nästan omedelbart, precis vad en angripare vill ha. Att mata lösenord genom HKDF i stället för PBKDF2 är ett klassiskt designfel; fältet info är till för ändamålsetiketter ("client traffic key", "server iv"), inte för extra entropi.

Var man stöter på den. TLS 1.3 härleder varje nyckel det använder från handskakningshemligheten via HKDF; WireGuard, Signal, EAP-TLS 1.3 och JSON Web Encryption (som direkt nyckelöverenskommelse-KDF) finns alla på samma släktträd.

Ankarvärden — återskapa dem på den här sidan

De två första tabellerna är testvektorerna som sidans exempelknapp och självtest bygger på (nyckel "key", meddelande “The quick brown fox jumps over the lazy dog”; sedan det RFC-liknande fallet med en 16-bytes 0x0b-nyckel och meddelandet “Hi There”). Alla togs fram av en oberoende inhemsk implementering och verifierades om på den här sidan.

HMAC av “fox”, nyckel = keyDigest (hex)
HMAC-MD580070713463e7749b90c2dc24911e275
HMAC-SHA-1de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC-SHA-256f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA-384d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237
HMAC-SHA-512b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a
KDF-ankareParametrarUtdata (hex, första byten)
PBKDF2-HMAC-SHA-1lösenord / salt, c=4096, 32 byte4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db
PBKDF2-HMAC-SHA-256lösenord / 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 och tom info, L=428da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8
Vanliga misstag
  • Att förväxla HMAC med kryptering. HMAC bevisar integritet och ursprung (givet en delad hemlighet); den döljer ingenting. Den som saknar nyckeln ser fortfarande hela meddelandet.
  • Att förväxla HMAC med en signatur. Digitala signaturer är publik nyckel: en part signerar, vem som helst verifierar. HMAC är symmetrisk: varje verifierare kan också förfalska. För icke-förnekbarhet behövs RSA/ECDSA (se RSA-verktyget i den här familjen när det publicerats), inte HMAC.
  • Felaktig tolkning av nycklar. En 64-teckens hex-sträng inklistrad i en textnyckelruta blir 64 byte, inte 32 — och HMAC:en ändras helt. Den här sidan skriver ut tolkningen på utdataraden; när två verktyg inte är överens är det första man jämför.
  • PBKDF2 med för få iterationer. 1 000 iterationer var rimligt år 2000; idag äter GPU-rigg upp det. Om ett system fortfarande lagrar hashar med 1 000 iterationer bör man planera en migrering med omhashning vid inloggning.
  • HKDF på ett lösenord. En HMAC per utdatablock innebär att ett lösenord passerar direkt — använd PBKDF2 (eller Argon2id) för lösenord och HKDF för hemligheter med hög entropi.
  • Återanvända en härledd nyckel till allt. Lösningen är gratis: härled separata nycklar med olika info-etiketter. Två nycklar från samma IKM med olika etiketter är oberoende per konstruktion.
Vanliga frågor

Är HMAC-MD5 bruten? Som kollisionsresistent hash är MD5 död, men HMAC-MD5:s säkerhet beror på MD5 som pseudoslumpfunktion, och inget praktiskt brott är känt. Ändå utfasad — det finns ingen anledning att välja den framför HMAC-SHA-256 utom kompatibilitet med ett gammalt protokoll.

Hur lång bör HMAC-nyckeln vara? Minst hashens utdatastorlek (32 byte för SHA-256) och genererad av en CSPRNG. En nyckel kortare än digesten är tillåten, men varje bit under den minskar säkerheten direkt.

Blir PBKDF2 med fler iterationer “säkrare” i all oändlighet? Den höjer angriparens kostnad linjärt, men också inloggningskostnaden linjärt. Konsten är att välja det största antalet som användarna tål — det är vad OWASP:s siffror kalibrerar.

Varför är HKDF begränsad till 255 × hashstorlek? Expansionsslingan är T(i) = HMAC(PRK, T(i-1) || info || i) med en ettbytes räknare i — 255 är det största räknarvärdet, en hård strukturell gräns i RFC 5869, inte ett policyval.

Vad är skillnaden mellan PBKDF2 på den här sidan och Lösenordshashgeneratorn? Samma algoritm, olika uppgift. Den här sidan härleder råa nyckelbyte för att användas någon annanstans; lösenordshashsidan producerar lagrade inloggningssträngar (med inbäddat salt och parametrar) och verifierar inklistrade kandidater mot dem.