Calculator HMAC, PBKDF2 și HKDF

Se calculează un cod de autentificare a mesajului cu cheie: HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 sau HMAC-SHA-512 (RFC 2104) peste text, octeți hex sau fișiere întregi — cheile ca text, hex sau Base64. Sau se derivează chei cu PBKDF2 (RFC 8018) și HKDF (RFC 5869). Fiecare rezultat poate fi afișat ca hex, hex cu litere mari, Base64 sau Base64url. Pentru rezumate simple a se vedea Generatorul de hash-uri; pentru sume de control a se vedea Calculatorul CRC; pentru HMAC așa cum apare în JWT a se vedea Decodorul JWT.
Rulează integral local — cheile și mesajele nu părăsesc niciodată fila. Fișiere de până la 200 MB.
Construcție: Ieșire:
Algoritm HMAC: RFC 2104 — varianta MD5 necesită md5.js (încărcat de această pagină).
Cheie secretă (secret comun; orice lungime, textul de mai jos este codificat UTF-8)
Citirea hex acceptă spații, două puncte și prefixe 0x; Base64 trebuie să fie în forma standard, cu sau fără umplutură.
O cheie goală este legală conform RFC 2104, dar aproape întotdeauna este o greșeală — un HMAC fără cheie este doar un hash lent.
Textul mesajului (datele de autentificat, codificate UTF-8)
Ieșire HMAC (o linie: construcție, parametri, valoare)
Prima linie înregistrează parametrii exacți ai calculului (algoritmul, interpretarea, dimensiunile intrărilor), astfel că un rezultat copiat este întotdeauna reproductibil.
Ce construcție este necesară?
HMAC transformă un secret comun plus un mesaj într-un autentificator: receptorul care cunoaște cheia îl poate recalcula și detecta modificările. Este „HS256”-ul din fiecare JWT semnat (a se vedea Decodorul JWT) și jumătate din schemele de semnare a cererilor API din lume. PBKDF2 servește la întinderea unei parole umane într-o cheie: repetă HMAC de mii de ori, astfel că fiecare ghicire a parolei costă atacatorul aceeași întârziere. HKDF servește la chei de protocol: ia octeți deja aleatorii, de tip secret (de exemplu un secret comun DH) și îi expandează în siguranță în mai multe chei legate de scop — TLS 1.3 își derivă toate cheile de trafic în acest fel. Regula generală: autentificare → HMAC; parolă → PBKDF2 (sau scrypt/Argon2, a se vedea Generatorul de hash-uri pentru parole, odată publicat); secret uniform → HKDF.
Autotest
Rulează motoarele paginii pe vectori publici: 10 ancore HMAC (în stilul RFC 2202/4231, cinci algoritmi × două intrări), 6 ancore PBKDF2 (SHA-1 și SHA-256 la trei numere de iterații) și cele patru cazuri de test RFC 5869 pentru HKDF, A.1–A.4. Nimic nu se trimite nicăieri.
HMAC, PBKDF2 și HKDF — hash-uri cu cheie explicate de la zero
Într-o propoziție: un hash simplu, precum SHA-256, îl poate calcula oricine, deci nu dovedește nimic despre cine a trimis un mesaj — HMAC amestecă o cheie secretă, astfel că doar deținătorii cheii pot produce (sau verifica) rezumatul; PBKDF2 și HKDF reutilizează apoi aceeași mașinărie HMAC pentru a transforma secrete în chei, lent pentru parole și rapid pentru material deja aleatoriu.
Ce este HMAC (RFC 2104)

Construcția. HMAC sunt două rulări de hash, nu una. Cheia este completată până la dimensiunea blocului hash-ului (64 de octeți pentru MD5/SHA-1/SHA-256, 128 pentru SHA-384/512); mesajul este hash-uit o dată cu cheia XOR un pad intern fix, iar acest rezumat este hash-uit din nou cu cheia XOR un pad extern fix. Acest sandviș dublu este demonstrabil sigur atâta timp cât hash-ul de dedesubt este o funcție pseudoaleatoare decentă — de aceea HMAC-MD5 rezistă încă atacurilor practice de coliziune care au spart MD5-ul simplu (deși este retras oricum, a se vedea mai jos).

Chei. Orice lungime de cheie funcționează: una mai scurtă decât dimensiunea blocului se folosește ca atare (dar sub 32 de octeți este privit cu reticență), una mai lungă este întâi hash-uită. Aceeași pagină permite introducerea cheii ca text, hex sau Base64, astfel încât o cheie de producție de 64 de caractere hexazecimale să poată fi lipită fără ca cineva să o confunde cu o parolă text de 64 de caractere — interpretarea este înregistrată în linia de ieșire tocmai din acest motiv.

Unde se întâlnește. Câmpul HS256 din antetul unui JWT este literalmente HMAC-SHA-256 peste părțile tokenului codificate base64url (Decodorul JWT de pe acest site calculează exact asta când se lipește un secret HS256). Semnăturile de webhook (Stripe, GitHub), AWS SigV4, protecția înregistrărilor TLS (versiuni mai vechi) și verișoara OpenSSH umac-64@openssh.com aparțin toate aceleiași familii.

De ce nu doar hash(mesaj || cheie)? Extinderea lungimii: fiecare hash din familia MD5/SHA-1/SHA-2 îi permite unui atacator care cunoaște H(secret || msg) să calculeze H(secret || msg || padding || orice) fără secret. Împărțirea internă/externă a HMAC elimină această clasă de atac. Este cea mai comună greșeală de tip „fă-o singur” în codul de semnare a API-urilor — și motivul pentru care există HMAC.

Ce este PBKDF2 (RFC 8018)

Lent prin proiectare. O parolă are poate 40 de biți de entropie reală; GPU-ul unui atacator încearcă miliarde de SHA-256 brut pe secundă. PBKDF2 rulează HMAC(parolă, sare) din nou și din nou — de iter ori — astfel că fiecare ghicire costă aceleași iter HMAC-uri și pentru sistem, și pentru atacator. Valoarea implicită aici este 600.000 de iterații cu HMAC-SHA-256, linia de bază a OWASP Password Storage Cheat Sheet; glisorul merge până la zece milioane, pentru că recomandările de securitate cresc pe măsură ce hardware-ul devine mai rapid.

Sarea. O sare aleatorie per parolă înseamnă că utilizatorii identici nu mai dau același hash, iar tabelele precalculate (rainbow tables) devin inutile. Ea nu este secretă — este stocată lângă hash — trebuie doar să fie unică. 16 octeți aleatorii sunt norma.

Slăbiciune cunoscută. PBKDF2 este greu pentru procesor, dar nu greu pentru memorie: GPU-urile și ASIC-urile îl paralelizează excelent. De aceea sfatul modern este scrypt sau Argon2id atunci când se proiectează stocarea hash-urilor de parolă (pagina Generatorul de hash-uri pentru parole din această familie le acoperă), iar PBKDF2 rămâne răspunsul corect pentru compatibilitate și setările FIPS-140.

Ce este HKDF (RFC 5869)

Extragere, apoi expandare. HKDF face două lucruri. Extragerea: comprimă materialul de cheie de intrare, posibil neuniform (de exemplu un secret comun Diffie–Hellman), împreună cu o sare, într-o cheie pseudoaleatoare scurtă PRK = HMAC(sare, IKM). Expandarea: întinde PRK până la orice lungime de cel mult 255 de blocuri hash, fiecare bloc de ieșire fiind înlănțuit cu cel precedent și etichetat de câmpul info. Rezultatul este că un singur secret poate da în siguranță o cheie de criptare, o cheie MAC și un IV, toate separate.

Nu pentru parole. HKDF presupune că intrarea are deja entropie completă — face un HMAC la fiecare 32 de octeți de ieșire, deci o parolă umană trece prin el practic instantaneu, exact ce își dorește un atacator. Trecerea parolelor prin HKDF în loc de PBKDF2 este o greșeală clasică de proiectare; câmpul info este pentru etichete de scop ("client traffic key", "server iv"), nu pentru entropie suplimentară.

Unde se întâlnește. TLS 1.3 derivă fiecare cheie pe care o folosește din secretul de handshake prin HKDF; WireGuard, Signal, EAP-TLS 1.3 și JSON Web Encryption (ca KDF direct de acord asupra cheii) apar toate în același arbore de familie.

Valori de referință — reproducerea lor pe această pagină

Primele două tabele sunt vectorii de test pe care se bazează butonul Mostră și autotestul acestei pagini (cheia "key", mesajul „The quick brown fox jumps over the lazy dog”; apoi cazul în stil RFC cu o cheie de 16 octeți 0x0b și mesajul „Hi There”). Toate au fost generate de o implementare nativă independentă și reverificate pe această pagină.

HMAC pentru „fox”, cheie = keyRezumat (hex)
HMAC-MD580070713463e7749b90c2dc24911e275
HMAC-SHA-1de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC-SHA-256f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA-384d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237
HMAC-SHA-512b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a
Ancorele KDFParametriIeșire (hex, primii octeți)
PBKDF2-HMAC-SHA-1parolă / sare, c=4096, 32 de octeți4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db
PBKDF2-HMAC-SHA-256parolă / sare, c=4096, 32 de octețic5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a
HKDF-SHA-256 (RFC 5869 A.1)IKM=0x0b×22, sare=00..0c, info=f0..f9, L=423cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865
HKDF-SHA-256 (RFC 5869 A.2)IKM=00..4f, sare=60..af, info=b0..ff, L=82b11e398dc80327a1c8e7f78c596a49344f012eda2d4efad8a050cc4c19afa97c…
HKDF-SHA-256 (RFC 5869 A.3)IKM=0x0b×22, sare și info goale, L=428da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8
Greșeli frecvente
  • Confundarea HMAC cu criptarea. HMAC dovedește integritatea și originea (dat fiind un secret comun); nu ascunde nimic. Oricine fără cheie vede în continuare mesajul întreg.
  • Confundarea HMAC cu o semnătură. Semnăturile digitale sunt cu cheie publică: unul semnează, oricine verifică. HMAC este simetric: orice verificator ar putea și falsifica. Pentru non-repudiere este nevoie de RSA/ECDSA (a se vedea instrumentul RSA din această familie, odată publicat), nu de HMAC.
  • Nepotriviri la citirea cheii. Un șir de 64 de caractere hexazecimale lipit într-o casetă de cheie text devine 64 de octeți, nu 32 — iar HMAC se schimbă complet. Această pagină tipărește interpretarea în linia de ieșire; când două instrumente nu se înțeleg, aceasta este primul lucru de comparat.
  • Iterații PBKDF2 prea puține. 1.000 de iterații era rezonabil în 2000; astăzi, sistemele cu GPU-uri le consumă. Dacă sistemul încă stochează hash-uri cu 1.000 de iterații, se planifică o migrare cu rehash la autentificare.
  • HKDF pe o parolă. Un HMAC pentru fiecare bloc de ieșire înseamnă că o parolă trece instantaneu — se folosește PBKDF2 (sau Argon2id) pentru parole și HKDF pentru secrete cu entropie ridicată.
  • Reutilizarea unei singure chei derivate pentru tot. Remediul este gratuit: se derivă chei separate cu etichete info diferite. Două chei din același IKM cu etichete diferite sunt independente prin proiectare.
Întrebări frecvente

Este HMAC-MD5 spart? Ca hash rezistent la coliziuni, MD5 este mort, dar securitatea HMAC-MD5 depinde de MD5 ca funcție pseudoaleatoare, iar nicio spargere practică nu este cunoscută. Oricum este retras — nu există niciun motiv să fie ales în locul HMAC-SHA-256, în afară de compatibilitatea cu un protocol vechi.

Cât de lungă ar trebui să fie cheia HMAC? Cel puțin dimensiunea ieșirii hash-ului (32 de octeți pentru SHA-256) și generată de un CSPRNG. O cheie mai scurtă decât rezumatul este permisă, dar fiecare bit sub această limită reduce direct securitatea.

PBKDF2 cu mai multe iterații devine „mai sigur” la nesfârșit? Ridică liniar costul atacatorului, dar și costul autentificării legitime, tot liniar. Miza este alegerea celui mai mare număr pe care îl tolerează utilizatorii — asta calibrează cifrele OWASP.

De ce este HKDF limitat la 255 × dimensiunea hash-ului? Bucla de expandare este T(i) = HMAC(PRK, T(i-1) || info || i) cu un contor i de un octet — 255 este cea mai mare valoare a contorului, o limită structurală strictă a RFC 5869, nu o alegere de politică.

Care este diferența dintre PBKDF2 de pe această pagină și Generatorul de hash-uri pentru parole? Același algoritm, scop diferit. Această pagină derivă octeți de cheie brute pentru a fi utilizate în altă parte; pagina de hash-uri pentru parole produce șiruri de credențiale stocate (cu sare și parametri încorporate) și verifică candidații introduși față de acestea.