HMAC-, PBKDF2- & HKDF-calculator

Bereken een gesleuteld berichtauthenticatiecode met HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 of HMAC-SHA-512 (RFC 2104) over tekst, hexbytes of hele bestanden — sleutels als tekst, hex of Base64. Of leid sleutels af met PBKDF2 (RFC 8018) en HKDF (RFC 5869). Elk resultaat kan worden weergegeven als hex, hoofdletterhex, Base64 of Base64url. Voor gewone digests zie de Hashgenerator; voor checksums zie de CRC-calculator; voor HMAC zoals gebruikt in JWT's zie de JWT-decoder.
Draait volledig lokaal — sleutels en berichten verlaten uw tabblad nooit. Bestanden tot 200 MB.
Constructie: Uitvoer:
HMAC-algoritme: RFC 2104 — de MD5-variant vereist md5.js (wordt door deze pagina geladen).
Geheime sleutel (gedeeld geheim; elke lengte, de tekst hieronder wordt in UTF-8 gecodeerd)
De hex-lezing verdraagt spaties, dubbele punten en 0x-prefixen; Base64 moet in de standaardvorm met of zonder opvulling zijn.
Een lege sleutel is legaal volgens RFC 2104 maar bijna altijd een fout — HMAC zonder sleutel is gewoon een trage hash.
Berichttekst (de gegevens om te authenticeren, UTF-8-gecodeerd)
HMAC-uitvoer (één regel: constructie, parameters, waarde)
De eerste regel legt de exacte gebruikte parameters vast (algoritme, lezing, invoergroottes), zodat een gekopieerd resultaat altijd reproduceerbaar is.
Welke constructie hebt u nodig?
HMAC maakt van een gedeeld geheim plus een bericht een authenticator: de ontvanger die de sleutel kent kan hem opnieuw berekenen en knoeien detecteren. Het is de “HS256” in elke ondertekende JWT (zie de JWT-decoder) en de helft van de API-verzoekondertekeningsschema's van de wereld. PBKDF2 is voor het uitrekken van een menselijk wachtwoord tot een sleutel: het herhaalt HMAC duizenden keren zodat elke wachtwoordgok de aanvaller dezelfde vertraging kost. HKDF is voor protocolsleutels: het neemt al willekeurige geheime bytes (bijv. een DH-gedeeld geheim) en rekt ze veilig uit tot meerdere, aan een doel gebonden sleutels — TLS 1.3 leidt al zijn verkeersleutels zo af. Vuistregel: authenticeren → HMAC; wachtwoord → PBKDF2 (of scrypt/Argon2, zie de Wachtwoordhashgenerator zodra die is gepubliceerd); uniform geheim → HKDF.
Zelftest
Draait de paginamotoren tegen gepubliceerde vectoren: 10 HMAC-ankerpunten (RFC 2202/4231-achtig, vijf algoritmen × twee invoeren), 6 PBKDF2-ankerpunten (SHA-1 en SHA-256 bij drie iteratietellingen) en de vier RFC 5869 HKDF-testgevallen A.1–A.4. Er wordt niets ergens naartoe gestuurd.
HMAC, PBKDF2 en HKDF — gesleutelde hashing vanaf nul uitgelegd
In één zin: een kale hash zoals SHA-256 kan iedereen berekenen, dus die bewijst niets over wie een bericht heeft gestuurd — HMAC mengt een geheime sleutel erin zodat alleen sleutelhouders de digest kunnen maken (of verifiëren); PBKDF2 en HKDF hergebruiken diezelfde HMAC-machinerie om geheimen in sleutels om te zetten, traag voor wachtwoorden en snel voor al willekeurig materiaal.
Wat HMAC is (RFC 2104)

De constructie. HMAC is twee hashrondes, niet één. Uw sleutel wordt opgevuld tot de blokgrootte van de hash (64 bytes voor MD5/SHA-1/SHA-256, 128 voor SHA-384/512); het bericht wordt eenmaal gehasht met de sleutel XOR een vaste binnenpad, en die digest wordt opnieuw gehasht met de sleutel XOR een vaste buitenpad. Deze dubbele sandwich is bewezen veilig zolang de onderliggende hash een degelijke pseudo-willekeurige functie is — daarom weerstaat HMAC-MD5 nog steeds de praktische botsingsaanvallen die gewone MD5 braken (hoewel het toch is uitgefaseerd, zie hieronder).

Sleutels. Elke sleutellengte werkt: een sleutel die korter is dan de blokgrootte wordt als zodanig gebruikt (maar onder 32 bytes wordt afgekeurd), een langere wordt eerst gehasht. Dezelfde pagina laat u de sleutel als tekst, hex of Base64 typen, zodat een productiesleutel van 64 hex-tekens kan worden geplakt zonder dat iemand hem voor een tekstwachtwoord van 64 tekens aanziet — de lezing wordt in de uitvoerregel vastgelegd, precies om die reden.

Waar u het tegenkomt. Het veld HS256 van een JWT-header is letterlijk HMAC-SHA-256 over de base64url-gecodeerde tokendelen (de JWT-decoder op deze site berekent precies dat wanneer u een HS256-geheim plakt). Webhook-handtekeningen (Stripe, GitHub), AWS SigV4, TLS-recordbescherming (oudere versies) en het verwante umac-64@openssh.com van OpenSSH horen allemaal bij dezelfde familie.

Waarom niet gewoon hash(bericht || sleutel)? Lengte-extensie: elke hash in de MD5/SHA-1/SHA-2-familie laat een aanvaller die H(geheim || bericht) kent H(geheim || bericht || opvulling || iets) berekenen zonder het geheim. De binnen-/buitensplitsing van HMAC doodt die klasse aanvallen. Het is de meest voorkomende zelfgemaakte fout in API-handtekeningcode — en de reden dat HMAC bestaat.

Wat PBKDF2 is (RFC 8018)

Langzaam by design. Een wachtwoord heeft misschien 40 bits echte entropie; de GPU van een aanvaller probeert miljarden ruwe SHA-256 per seconde. PBKDF2 voert HMAC(wachtwoord, salt) steeds opnieuw uit — iter keer — zodat elke gok dezelfde iter HMAC's kost, voor u en voor de aanvaller. De standaard hier is 600.000 iteraties met HMAC-SHA-256, de basislijn van het OWASP Password Storage Cheat Sheet; de schuifregelaar gaat tot tien miljoen omdat beveiligingsadvies omhoog wordt bijgesteld naarmate hardware sneller wordt.

Salt. Een willekeurige salt per wachtwoord betekent dat identieke gebruikers niet meer identiek worden gehasht, en vooraf berekende tabellen (regenboogtabellen) waardeloos worden. Hij is niet geheim — hij wordt naast de hash opgeslagen — hij moet alleen uniek zijn. 16 willekeurige bytes is de norm.

Bekende zwakte. PBKDF2 is CPU-zwaar maar niet geheugenzwaar: GPU's en ASIC's paralleliseren het uitstekend. Daarom is het moderne advies scrypt of Argon2id waar opslag van wachtwoordhashes wordt ontworpen (de Wachtwoordhashgenerator in deze familie behandelt ze), en blijft PBKDF2 het juiste antwoord voor compatibiliteit en FIPS-140-instellingen.

Wat HKDF is (RFC 5869)

Extract, dan expand. HKDF doet twee dingen. Extract: perst mogelijk ongelijkmatig invoersleutelmateriaal (bijv. een gedeeld geheim van Diffie–Hellman) samen met een salt tot één korte pseudo-willekeurige sleutel PRK = HMAC(salt, IKM). Expand: rekt die PRK uit tot elke lengte tot 255 hash-blokken, waarbij elk uitvoerblok aan het vorige wordt gekoppeld en gemarkeerd door het veld info. Het resultaat is dat één geheim veilig een versleutelingssleutel, een MAC-sleutel en een IV kan geven, allemaal gescheiden.

Niet voor wachtwoorden. HKDF gaat ervan uit dat zijn invoer al volledige entropie heeft — het doet één HMAC per 32 uitvoerbytes, dus een menselijk wachtwoord gaat er vrijwel meteen doorheen, precies wat een aanvaller wil. Wachtwoorden door HKDF halen in plaats van PBKDF2 is een klassieke ontwerpfout; het veld info is voor doellabels ("client traffic key", "server iv"), niet voor extra entropie.

Waar u het tegenkomt. TLS 1.3 leidt elke sleutel die het gebruikt af van het handshake-geheim via HKDF; WireGuard, Signal, EAP-TLS 1.3 en JSON Web Encryption (als directe sleuteloverdracht-KDF) komen allemaal voor in dezelfde familieboom.

Ankerwaarden — reproduceer ze op deze pagina

De eerste twee tabellen zijn de testvectoren waarop de knop Voorbeeld van deze pagina en de zelftest zijn gebaseerd (sleutel "key", bericht “The quick brown fox jumps over the lazy dog”; daarna het RFC-achtige geval van een sleutel van 16 bytes 0x0b en het bericht “Hi There”). Alle zijn gegenereerd door een onafhankelijke native implementatie en op deze pagina opnieuw geverifieerd.

HMAC van “fox”, sleutel = keyDigest (hex)
HMAC-MD580070713463e7749b90c2dc24911e275
HMAC-SHA-1de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC-SHA-256f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA-384d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237
HMAC-SHA-512b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a
KDF-ankerpuntenParametersUitvoer (hex, eerste bytes)
PBKDF2-HMAC-SHA-1wachtwoord / salt, c=4096, 32 bytes4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db
PBKDF2-HMAC-SHA-256wachtwoord / 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, lege salt en info, L=428da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8
Veelgemaakte fouten
  • HMAC verwarren met versleuteling. HMAC bewijst integriteit en herkomst (gegeven een gedeeld geheim); het verbergt niets. Iedereen zonder de sleutel ziet nog steeds het volledige bericht.
  • HMAC verwarren met een handtekening. Digitale handtekeningen zijn met publieke sleutels: één ondertekent, iedereen verifieert. HMAC is symmetrisch: elke verifieerder kan ook vervalsen. Voor non-repudiatie heeft u RSA/ECDSA nodig (zie de RSA-tool in deze familie zodra die is gepubliceerd), niet HMAC.
  • Verkeerde lezingen van sleutels. Een hex-tekenreeks van 64 tekens die in een tekstsleutelvak wordt geplakt wordt 64 bytes, niet 32 — en de HMAC verandert volledig. Deze pagina drukt de lezing af in de uitvoerregel; als twee tools het oneens zijn, is dat het eerste wat u moet vergelijken.
  • PBKDF2 met te weinig iteraties. 1.000 iteraties was in 2000 redelijk; tegenwoordig vreten GPU-rigs dat op. Als uw systeem nog hashes met 1.000 iteraties opslaat, plan dan een migratie waarbij bij het inloggen opnieuw wordt gehasht.
  • HKDF op een wachtwoord. Eén HMAC per uitvoerblok betekent dat een wachtwoord er direct doorheen gaat — gebruik PBKDF2 (of Argon2id) voor wachtwoorden en HKDF voor geheimen met hoge entropie.
  • Eén afgeleide sleutel voor alles hergebruiken. De oplossing is gratis: leid aparte sleutels af met verschillende labels in info. Twee sleutels uit één IKM met verschillende labels zijn per ontwerp onafhankelijk.
Veelgestelde vragen

Is HMAC-MD5 gebroken? Als botsingsbestendige hash is MD5 dood, maar de beveiliging van HMAC-MD5 hangt af van MD5 als pseudo-willekeurige functie, en er is geen praktische doorbreking bekend. Toch uitgefaseerd — er is geen reden om het boven HMAC-SHA-256 te kiezen, behalve compatibiliteit met een oud protocol.

Hoe lang moet mijn HMAC-sleutel zijn? Ten minste de uitvoergrootte van de hash (32 bytes voor SHA-256) en gegenereerd door een CSPRNG. Een sleutel die korter is dan de digest is toegestaan, maar elke bit eronder verlaagt de beveiliging direct.

Wordt PBKDF2 met meer iteraties onbeperkt “veiliger”? Het verhoogt de kosten voor de aanvaller lineair, maar ook uw inlogkosten lineair. Het spel is het grootste aantal kiezen dat uw gebruikers verdragen — daarop kalibreren de cijfers van OWASP.

Waarom is HKDF beperkt tot 255 × hashgrootte? De expand-lus is T(i) = HMAC(PRK, T(i-1) || info || i) met een teller i van één byte — 255 is de grootste tellerwaarde, een harde structurele limiet van RFC 5869, geen beleidskeuze.

Wat is het verschil tussen PBKDF2 op deze pagina en de Wachtwoordhashgenerator? Hetzelfde algoritme, andere taak. Deze pagina leidt ruwe sleutelbytes af om elders te gebruiken; de wachtwoordhashpagina maakt opgeslagen geloofsbrieven (met ingebedde salt en parameters) en verifieert geplakte kandidaten daartegen.