Kalkulačka HMAC, PBKDF2 a HKDF

Vypočítejte kód autentizace zprávy s klíčem: HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 nebo HMAC-SHA-512 (RFC 2104) nad textem, hex bajty nebo celými soubory — klíče jako text, hex nebo Base64. Nebo odvozujte klíče pomocí PBKDF2 (RFC 8018) a HKDF (RFC 5869). Každý výsledek lze zobrazit jako hex, velký hex, Base64 nebo Base64url. Prosté otisky najdete v generátoru hashů; kontrolní součty v kalkulačce CRC; HMAC používaný uvnitř JWT najdete v dekodéru JWT.
Běží zcela lokálně — klíče a zprávy nikdy neopustí kartu. Soubory až 200 MB.
Konstrukce: Výstup:
Algoritmus HMAC: RFC 2104 — varianta MD5 vyžaduje md5.js (načítá tato stránka).
Tajný klíč (sdílené tajemství; libovolná délka, text níže se kóduje jako UTF-8)
Čtení hex toleruje mezery, dvojtečky a předpony 0x; Base64 musí být ve standardním tvaru s výplní nebo bez ní.
Prázdný klíč je podle RFC 2104 přípustný, ale téměř vždy chyba — HMAC bez klíče je jen pomalý hash.
Text zprávy (data k autentizaci, kódovaná jako UTF-8)
Výstup HMAC (jeden řádek: konstrukce, parametry, hodnota)
První řádek zaznamenává přesné použité parametry (algoritmus, čtení, velikosti vstupů), takže zkopírovaný výsledek je vždy reprodukovatelný.
Jakou konstrukci potřebujete?
HMAC z sdíleného tajemství a zprávy vytvoří autentizátor: příjemce, který zná klíč, jej může znovu spočítat a odhalit manipulaci. Je to „HS256“ uvnitř každého podepsaného JWT (viz dekodér JWT) a polovina podepisovacích schémat API požadavků na světě. PBKDF2 slouží k natažení lidského hesla na klíč: opakuje HMAC tisíckrát, takže každý pokus o heslo stojí útočníka stejné zpoždění. HKDF je pro protokolové klíče: vezme již náhodné tajné bajty (např. sdílené tajemství DH) a bezpečně je rozšíří na několik klíčů vázaných na účel — TLS 1.3 odvozuje všechny své provozní klíče tímto způsobem. Praktické pravidlo: autentizace → HMAC; heslo → PBKDF2 (nebo scrypt/Argon2, viz generátor hashů hesel, až bude zveřejněn); rovnoměrné tajemství → HKDF.
Autotest
Spustí enginy stránky proti zveřejněným vektorům: 10 kotev HMAC (ve stylu RFC 2202/4231, pět algoritmů × dva vstupy), 6 kotev PBKDF2 (SHA-1 a SHA-256 při třech počtech iterací) a čtyři testovací případy RFC 5869 HKDF A.1–A.4. Nic se nikam neodesílá.
HMAC, PBKDF2 a HKDF — klíčované hashování vysvětlené od začátku
Jednou větou: holý hash jako SHA-256 může spočítat kdokoli, takže neprokazuje, kdo zprávu odeslal — HMAC přimíchá tajný klíč, takže otisk mohou vytvořit (nebo ověřit) jen držitelé klíče; PBKDF2 a HKDF pak používají tentýž stroj HMAC k přeměně tajemství v klíče, pomalu pro hesla a rychle pro již náhodný materiál.
Co je HMAC (RFC 2104)

Konstrukce. HMAC jsou dva běhy hashe, ne jeden. Klíč se doplní na velikost bloku hashe (64 bajtů pro MD5/SHA-1/SHA-256, 128 pro SHA-384/512); zpráva se jednou zahashuje s klíčem XOR s pevnou vnitřní výplní a tento otisk se znovu zahashuje s klíčem XOR s pevnou vnější výplní. Tento dvojitý sendvič je prokazatelně bezpečný, pokud je podkladový hash slušná pseudonáhodná funkce — proto HMAC-MD5 stále odolává praktickým útokům na kolize, které lámaly prostý MD5 (i když je stejně vyřazen, viz níže).

Klíče. Funguje libovolná délka klíče: kratší než velikost bloku se použije tak, jak je (ale pod 32 bajtů se nedoporučuje), delší se nejprve zahashuje. Stejná stránka umožňuje zadat klíč jako text, hex nebo Base64, takže lze vložit produkční klíč o 64 hex znacích, aniž by si jej někdo spletl s textovým heslem o 64 znacích — čtení je proto zapsáno do výstupního řádku.

Kde se s ním setkáte. Pole HS256 v hlavičce JWT je doslova HMAC-SHA-256 nad base64url kódovanými částmi tokenu (dekodér JWT na tomto webu to přesně počítá, když vložíte tajný klíč HS256). Podpisy webhooků (Stripe, GitHub), AWS SigV4, ochrana záznamů TLS (starší verze) a příbuzný umac-64@openssh.com v OpenSSH patří do stejné rodiny.

Proč prostě ne hash(zpráva || klíč)? Rozšíření délky: každý hash z rodiny MD5/SHA-1/SHA-2 umožní útočníkovi, který zná H(secret || msg), spočítat H(secret || msg || padding || cokoli) bez tajemství. Rozdělení HMAC na vnitřní a vnější část tuto třídu útoků zastaví. Je to nejčastější chyba u kódu podpisů API typu „udělej si sám“ — a důvod, proč HMAC existuje.

Co je PBKDF2 (RFC 8018)

Záměrně pomalé. Heslo má zhruba 40 bitů skutečné entropie; GPU útočníka zkouší miliardy prostých SHA-256 za sekundu. PBKDF2 opakuje HMAC(password, salt) znovu a znovu — iterkrát — takže každý pokus stojí pro vás i pro útočníka stejných iter HMAC. Výchozí hodnota zde je 600 000 iterací s HMAC-SHA-256, základ z OWASP Password Storage Cheat Sheet; posuvník jde až na deset milionů, protože bezpečnostní doporučení rostou spolu s rychlostí hardwaru.

Sůl. Náhodná sůl pro každé heslo znamená, že stejní uživatelé se již nehashují stejně a předpočítané tabulky (duhové tabulky) ztrácejí cenu. Není tajná — ukládá se vedle hashe — jen musí být jedinečná. Běžných je 16 náhodných bajtů.

Známá slabina. PBKDF2 je náročné na CPU, ale ne na paměť: GPU a ASIC jej paralelizují výborně. Proto moderní doporučení znějí scrypt nebo Argon2id, když se navrhuje ukládání hesel (stránka generátoru hashů hesel v této rodině je pokrývá), a PBKDF2 zůstává správnou volbou pro kompatibilitu a nastavení FIPS-140.

Co je HKDF (RFC 5869)

Extrahovat, pak rozšířit. HKDF dělá dvě práce. Extrakce: stlačí možná nerovnoměrný vstupní materiál klíče (např. sdílené tajemství Diffie–Hellmana) spolu se solí do jednoho krátkého pseudonáhodného klíče PRK = HMAC(salt, IKM). Rozšíření: natáhne tento PRK na libovolnou délku až 255 bloků hashe, přičemž každý výstupní blok je řetězen s předchozím a označen polem info. Výsledkem je, že jedno tajemství vám může bezpečně dát šifrovací klíč, klíč MAC a IV, všechny oddělené.

Ne pro hesla. HKDF předpokládá, že jeho vstup už má plnou entropii — provádí jeden HMAC na 32 výstupních bajtů, takže lidské heslo jím projde prakticky okamžitě, přesně jak si útočník přeje. Posílat hesla přes HKDF místo PBKDF2 je klasická konstrukční chyba; pole info slouží k popiskám účelu ("client traffic key", "server iv"), ne k dodatečné entropii.

Kde se s ním setkáte. TLS 1.3 odvozuje každý klíč, který používá, z tajemství handshake přes HKDF; WireGuard, Signal, EAP-TLS 1.3 a JSON Web Encryption (jako přímá KDF dohody klíčů) se všechny objevují na stejném rodokmenu.

Kontrolní hodnoty — reprodukujte je na této stránce

První dvě tabulky jsou testovací vektory, na nichž jsou postavena tlačítko Ukázka a samotest této stránky (klíč "key", zpráva „The quick brown fox jumps over the lazy dog“; pak případ ve stylu RFC s 16bajtovým klíčem 0x0b a zprávou „Hi There“). Všechny byly vygenerovány nezávislou nativní implementací a na této stránce znovu ověřeny.

HMAC z „fox“, klíč = keyOtisk (hex)
HMAC-MD580070713463e7749b90c2dc24911e275
HMAC-SHA-1de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC-SHA-256f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA-384d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237
HMAC-SHA-512b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a
Kotvy KDFParametryVýstup (hex, první bajty)
PBKDF2-HMAC-SHA-1heslo / sůl, c=4096, 32 bajtů4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db
PBKDF2-HMAC-SHA-256heslo / sůl, c=4096, 32 bajtůc5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a
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, prázdná sůl a info, L=428da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8
Časté chyby
  • Záměna HMAC za šifrování. HMAC prokazuje integritu a původ (při sdíleném tajemství); nic neskrývá. Každý bez klíče stále vidí celou zprávu.
  • Záměna HMAC za podpis. Digitální podpisy jsou s veřejným klíčem: jeden podepisuje, kdokoli ověřuje. HMAC je symetrický: každý ověřovatel by mohl také padělat. Pro nepopiratelnost potřebujete RSA/ECDSA (viz nástroj RSA v této rodině, až bude zveřejněn), ne HMAC.
  • Nesoulad při čtení klíče. 64znakový hex řetězec vložený do textového pole klíče se stane 64 bajty, ne 32 — a HMAC se zcela změní. Tato stránka vypisuje způsob čtení ve výstupním řádku; když se dva nástroje neshodnou, je to první věc k porovnání.
  • Málo iterací u PBKDF2. 1 000 iterací bylo v roce 2000 rozumných; dnes je spotřebují GPU. Pokud váš systém stále ukládá hashe s 1 000 iteracemi, naplánujte migraci s přehashováním při přihlášení.
  • HKDF na heslo. Jeden HMAC na výstupní blok znamená, že heslo projde okamžitě — pro hesla používejte PBKDF2 (nebo Argon2id) a pro tajemství s vysokou entropií HKDF.
  • Opakované použití jednoho odvozeného klíče pro všechno. Náprava je zdarma: odvoďte oddělené klíče s různými popisky info. Dva klíče z jednoho IKM s různými popisky jsou podle návrhu nezávislé.
Časté dotazy

Je HMAC-MD5 prolomený? Jako hash odolný proti kolizím je MD5 mrtvý, ale bezpečnost HMAC-MD5 závisí na MD5 jako pseudonáhodné funkci a žádný praktický zlom není znám. Každopádně je vyřazen — není důvod volit jej před HMAC-SHA-256, kromě kompatibility se starým protokolem.

Jak dlouhý má být můj klíč HMAC? Alespoň tak velký jako výstup hashe (32 bajtů pro SHA-256) a vygenerovaný CSPRNG. Klíč kratší než otisk je povolen, ale každý bit pod touto hodnotou přímo snižuje bezpečnost.

Stává se PBKDF2 s větším počtem iterací „bezpečnějším“ donekonečna? Zvyšuje náklad útočníka lineárně, ale také váš náklad na přihlášení lineárně. Hra spočívá ve volbě největšího počtu, který vaši uživatelé snesou — právě na to kalibrují čísla OWASP.

Proč je HKDF omezeno na 255 × velikost hashe? Smyčka rozšíření je T(i) = HMAC(PRK, T(i-1) || info || i) s jednobajtovým čítačem i — 255 je největší hodnota čítače, tvrdý strukturální limit RFC 5869, nikoli volba politiky.

Jaký je rozdíl mezi PBKDF2 na této stránce a generátorem hashů hesel? Stejný algoritmus, jiný úkol. Tato stránka odvozuje surové bajty klíče k použití jinde; stránka hashů hesel vytváří uložené řetězce přihlašovacích údajů (s vloženou solí a parametry) a ověřuje vložené kandidáty proti nim.