La prima riga registra i parametri esatti usati (algoritmo, lettura, dimensioni dell'input), così un risultato copiato e incollato è sempre riproducibile.
HMAC, PBKDF2 e HKDF — hashing con chiave spiegato da zero
In una frase: un hash semplice come SHA-256 può essere calcolato da chiunque, quindi non prova chi abbia inviato un messaggio — HMAC mescola una chiave segreta in modo che solo chi possiede la chiave possa produrre (o verificare) il digest; PBKDF2 e HKDF riusano poi lo stesso meccanismo HMAC per trasformare segreti in chiavi, lentamente per le password e rapidamente per il materiale già casuale.
Che cos'è HMAC (RFC 2104)
La costruzione. HMAC sono due esecuzioni di hash, non una. La sua chiave viene riempita fino alla dimensione del blocco dell'hash (64 byte per MD5/SHA-1/SHA-256, 128 per SHA-384/512); il messaggio viene sottoposto ad hash una volta con la chiave XOR un riempimento interno fisso, e quel digest viene sottoposto ad hash di nuovo con la chiave XOR un riempimento esterno fisso. Questa doppia struttura è dimostrabilmente sicura finché l'hash sottostante è una buona funzione pseudocasuale — ed è per questo che HMAC-MD5 resiste ancora agli attacchi di collisione pratici che hanno rotto l'MD5 semplice (anche se è ritirato comunque, veda sotto).
Chiavi. Funziona qualsiasi lunghezza di chiave: quelle più corte della dimensione del blocco vengono usate così come sono (ma sotto i 32 byte non è consigliato), quelle più lunghe vengono prima sottoposte ad hash. La stessa pagina le permette di scrivere la chiave come testo, esadecimale o Base64, così una chiave di produzione di 64 caratteri esadecimali può essere incollata senza che qualcuno la scambi per una password di testo di 64 caratteri — la lettura è registrata nella riga di output proprio per questo motivo.
Dove lo si incontra. Il campo HS256 dell'intestazione di un JWT è letteralmente HMAC-SHA-256 sui componenti del token codificati in base64url (il Decodificatore JWT di questo sito calcola esattamente questo quando incolla un segreto HS256). Le firme dei webhook (Stripe, GitHub), AWS SigV4, la protezione dei record TLS (versioni più vecchie) e il cugino umac-64@openssh.com di OpenSSH appartengono tutti alla stessa famiglia.
Perché non usare semplicemente hash(messaggio || chiave)? Estensione di lunghezza: ogni hash della famiglia MD5/SHA-1/SHA-2 permette a un attaccante che conosce H(segreto || msg) di calcolare H(segreto || msg || padding || qualsiasi cosa) senza il segreto. La divisione interna/esterna di HMAC elimina questa classe di attacchi. È l'errore fai-da-te più comune nel codice di firma delle API — ed è il motivo per cui esiste HMAC.
Che cos'è PBKDF2 (RFC 8018)
Lento per progetto. Una password ha forse 40 bit di entropia reale; la GPU di un attaccante prova miliardi di SHA-256 grezzi al secondo. PBKDF2 esegue HMAC(password, sale) più e più volte — iter volte — così ogni tentativo costa a lei e all'attaccante lo stesso numero iter di HMAC. Il valore predefinito qui è 600.000 iterazioni con HMAC-SHA-256, la base della OWASP Password Storage Cheat Sheet; il cursore arriva a dieci milioni perché le indicazioni di sicurezza si alzano man mano che l'hardware diventa più veloce.
Sale. Un sale casuale per ogni password fa sì che utenti identici non producano più lo stesso hash, e le tabelle precalcolate (rainbow table) diventano inutili. Non è segreto — viene memorizzato accanto all'hash — deve solo essere unico. 16 byte casuali sono la norma.
Debolezza nota. PBKDF2 è difficile per la CPU ma non per la memoria: GPU e ASIC lo parallelizzano molto bene. Per questo il consiglio moderno, quando si progetta la memorizzazione dell'hash di una password, è scrypt o Argon2id (il Generatore di hash per password di questa famiglia li tratta), mentre PBKDF2 resta la risposta giusta per la compatibilità e le impostazioni FIPS-140.
Che cos'è HKDF (RFC 5869)
Estrarre, poi espandere. HKDF svolge due compiti. Extract: comprime il materiale di chiave in input, eventualmente non uniforme (un segreto condiviso Diffie–Hellman, per esempio), insieme a un sale in un'unica chiave pseudocasuale corta PRK = HMAC(sale, IKM). Expand: allunga quel PRK a qualsiasi lunghezza fino a 255 blocchi di hash, con ogni blocco di output concatenato al precedente e marcato dal campo info. Il risultato è che un solo segreto può darle in sicurezza una chiave di cifratura, una chiave MAC e un IV, tutti separati.
Non per le password. HKDF presume che il suo input abbia già piena entropia — esegue un HMAC ogni 32 byte di output, quindi una password umana lo attraversa praticamente all'istante, esattamente ciò che vuole un attaccante. Far passare le password attraverso HKDF invece che PBKDF2 è un classico errore di progettazione; il campo info serve per etichette di scopo ("chiave di traffico del client", "iv del server"), non per entropia extra.
Dove lo si incontra. TLS 1.3 deriva ogni chiave che usa dal segreto dell'handshake tramite HKDF; WireGuard, Signal, EAP-TLS 1.3 e JSON Web Encryption (come KDF diretto per l'accordo di chiave) compaiono tutti nello stesso albero genealogico.
Valori di ancoraggio — li riproduca su questa pagina
Le prime due tabelle sono i vettori di test su cui si basano il pulsante Esempio e l'autotest di questa pagina (chiave "key", messaggio «The quick brown fox jumps over the lazy dog»; poi il caso in stile RFC di una chiave di 16 byte 0x0b e il messaggio «Hi There»). Sono stati generati da un'implementazione nativa indipendente e riverificati su questa pagina.
HMAC di «fox», chiave = key | Digest (esadecimale) |
|---|
| HMAC-MD5 | 80070713463e7749b90c2dc24911e275 |
| HMAC-SHA-1 | de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9 |
| HMAC-SHA-256 | f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8 |
| HMAC-SHA-384 | d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237 |
| HMAC-SHA-512 | b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a |
| Ancore KDF | Parametri | Output (esadecimale, primi byte) |
|---|
| PBKDF2-HMAC-SHA-1 | password / sale, c=4096, 32 byte | 4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db |
| PBKDF2-HMAC-SHA-256 | password / sale, c=4096, 32 byte | c5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a |
| HKDF-SHA-256 (RFC 5869 A.1) | IKM=0x0b×22, sale=00..0c, info=f0..f9, L=42 | 3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865 |
| HKDF-SHA-256 (RFC 5869 A.2) | IKM=00..4f, sale=60..af, info=b0..ff, L=82 | b11e398dc80327a1c8e7f78c596a49344f012eda2d4efad8a050cc4c19afa97c… |
| HKDF-SHA-256 (RFC 5869 A.3) | IKM=0x0b×22, sale e info vuoti, L=42 | 8da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8 |
Errori comuni
- Confondere HMAC con la cifratura. HMAC prova l'integrità e l'origine (dato un segreto condiviso); non nasconde nulla. Chiunque non abbia la chiave vede ancora l'intero messaggio.
- Confondere HMAC con una firma. Le firme digitali sono a chiave pubblica: uno firma, chiunque verifica. HMAC è simmetrico: ogni verificatore potrebbe anche falsificare. Per la non ripudiabilità servono RSA/ECDSA (veda lo strumento RSA di questa famiglia quando sarà pubblicato), non HMAC.
- Letture della chiave non corrispondenti. Una stringa esadecimale di 64 caratteri incollata in una casella di chiave di testo diventa 64 byte, non 32 — e l'HMAC cambia completamente. Questa pagina stampa la lettura nella riga di output; quando due strumenti non concordano, è la prima cosa da confrontare.
- Iterazioni PBKDF2 troppo basse. 1.000 iterazioni erano ragionevoli nel 2000; oggi le macchine con GPU le divorano. Se il suo sistema memorizza ancora hash con 1.000 iterazioni, pianifichi una migrazione con rehash al login.
- HKDF su una password. Un HMAC per ogni blocco di output significa che una password lo attraversa istantaneamente — usi PBKDF2 (o Argon2id) per le password e HKDF per i segreti ad alta entropia.
- Riutilizzare una sola chiave derivata per tutto. La correzione è gratuita: derivi chiavi separate con etichette
info diverse. Due chiavi dallo stesso IKM con etichette diverse sono indipendenti per progetto.
Domande frequenti
HMAC-MD5 è rotto? Come hash resistente alle collisioni l'MD5 è morto, ma la sicurezza di HMAC-MD5 dipende dall'MD5 come funzione pseudocasuale, e non si conosce alcuna rottura pratica. È comunque ritirato — non c'è motivo di sceglierlo rispetto a HMAC-SHA-256 se non per la compatibilità con un vecchio protocollo.
Quanto deve essere lunga la mia chiave HMAC? Almeno quanto la dimensione dell'output dell'hash (32 byte per SHA-256) e generata da un CSPRNG. Una chiave più corta del digest è ammessa, ma ogni bit al di sotto riduce direttamente la sicurezza.
PBKDF2 con più iterazioni diventa «più sicuro» all'infinito? Alza il costo per l'attaccante in modo lineare, ma anche il costo del login per voi in modo lineare. Il gioco consiste nello scegliere il conteggio più alto che i vostri utenti tollerano — è ciò che calibrano i numeri dell'OWASP.
Perché HKDF è limitato a 255 × la dimensione dell'hash? Il ciclo di expand è T(i) = HMAC(PRK, T(i-1) || info || i) con un contatore i di un byte — 255 è il valore massimo del contatore, un limite strutturale rigido della RFC 5869, non una scelta di policy.
Qual è la differenza tra PBKDF2 di questa pagina e il Generatore di hash per password? Stesso algoritmo, compito diverso. Questa pagina deriva byte di chiave grezzi da usare altrove; la pagina per hash di password produce stringhe di credenziali memorizzate (con sale e parametri incorporati) e verifica i candidati incollati rispetto a esse.
