Калькулятор HMAC, PBKDF2 і HKDF

Обчисліть код автентифікації повідомлення з ключем HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 або HMAC-SHA-512 (RFC 2104) над текстом, hex-байтами або цілими файлами — ключі як текст, hex або Base64. Або вивести ключі через PBKDF2 (RFC 8018) і HKDF (RFC 5869). Кожен результат можна показати як hex, hex у верхньому регістрі, Base64 або Base64url. Для простих дайджестів див. Генератор хешів; для контрольних сум — Калькулятор CRC; для HMAC у складі JWT — Декодер JWT.
Повністю працює локально — ключі й повідомлення ніколи не покидають вашу вкладку. Файли до 200 МБ.
Конструкція: Вихід:
Алгоритм HMAC: RFC 2104 — варіант MD5 потребує md5.js (завантажується цією сторінкою).
Секретний ключ (спільний секрет; будь-якої довжини, текст нижче кодується в UTF-8)
Читання hex толерує пробіли, двокрапки і префікси 0x; Base64 має бути у стандартній формі з доповненням або без.
Порожній ключ легальний за RFC 2104, але майже завжди є помилкою — HMAC без ключа є просто повільним хешем.
Текст повідомлення (дані для автентифікації, кодуються в UTF-8)
Вихід HMAC (один рядок: конструкція, параметри, значення)
Перший рядок фіксує точні використані параметри (алгоритм, прочитання, розміри введення), тож скопійований результат завжди відтворюваний.
Яка конструкція вам потрібна?
HMAC перетворює спільний секрет плюс повідомлення на автентифікатор: одержувач, який знає ключ, може його перерахувати і виявити підробку. Це «HS256» всередині кожного підписаного JWT (див. Декодер JWT) і половина схем підписування API-запитів у світі. PBKDF2 призначений для розтягування людського пароля в ключ: він повторює HMAC тисячі разів, щоб кожна здогадка про пароль коштувала атакувальнику тієї самої затримки. HKDF — для протокольних ключів: він бере вже випадкові секретні байти (напр., спільний секрет DH) і безпечно розгортає їх у кілька ключів, прив'язаних до призначення — TLS 1.3 виводить усі свої ключі трафіку саме так. Правило великого пальця: автентифікація → HMAC; пароль → PBKDF2 (або scrypt/Argon2, див. Генератор хешів паролів, коли його опублікують); рівномірний секрет → HKDF.
Самоперевірка
Запускає рушії сторінки проти опублікованих векторів: 10 еталонних HMAC (у стилі RFC 2202/4231, п'ять алгоритмів × два введення), 6 еталонних PBKDF2 (SHA-1 і SHA-256 при трьох кількостях ітерацій) і чотири тестові випадки RFC 5869 HKDF A.1–A.4. Нічого нікуди не надсилається.
HMAC, PBKDF2 і HKDF — ключове хешування, пояснене з нуля
Одним реченням: голий хеш на кшталт SHA-256 може обчислити будь-хто, тож він нічого не доводить про те, хто надіслав повідомлення; HMAC домішує таємний ключ, щоб лише власники ключа могли створити (або перевірити) дайджест; PBKDF2 і HKDF потім повторно використовують ту саму машинерію HMAC, щоб перетворити секрети на ключі — повільно для паролів і швидко для вже випадкового матеріалу.
Що таке HMAC (RFC 2104)

Конструкція. HMAC — це два запуски хешу, а не один. Ваш ключ доповнюється до розміру блоку хешу (64 байти для MD5/SHA-1/SHA-256, 128 для SHA-384/512); повідомлення хешується один раз з ключем XOR з фіксованим внутрішнім доповненням, а цей дайджест хешується знову з ключем XOR із фіксованим зовнішнім доповненням. Цей подвійний «сендвіч» доведено безпечний, доки базовий хеш є пристойною псевдовипадковою функцією — тому HMAC-MD5 досі протистоїть практичним атакам колізіями, що зламали звичайний MD5 (хоча його все одно відставлено, див. нижче).

Ключі. Підходить будь-яка довжина ключа: коротший за розмір блоку використовується як є (але менше 32 байтів не схвалюється), довший спершу хешується. Та сама сторінка дозволяє вводити ключ як текст, hex або Base64, щоб 64-hex-символьний виробничий ключ можна було вставити, не сплутавши його з 64-символьним текстовим паролем — прочитання записується в рядку виводу саме з цієї причини.

Де ви з ним зустрічаєтесь. Поле HS256 в заголовку JWT — буквально HMAC-SHA-256 над закодованими в base64url частинами токена (Декодер JWT на цьому сайті обчислює саме це, коли ви вставляєте секрет HS256). Підписи вебхуків (Stripe, GitHub), AWS SigV4, захист записів TLS (старіші версії) і двоюрідний брат OpenSSH umac-64@openssh.com належать до тієї самої родини.

Чому не просто hash(message || key)? Розширення довжини: кожен хеш родин MD5/SHA-1/SHA-2 дозволяє зловмиснику, який знає H(secret || msg), обчислити H(secret || msg || padding || anything) без секрету. Розділення HMAC на внутрішній/зовнішній прибирає цей клас атак. Це найпоширеніша самодіяльна помилка в коді підписів API — і причина, чому існує HMAC.

Що таке PBKDF2 (RFC 8018)

Повільний за задумом. У пароля, можливо, 40 біт реальної ентропії; GPU атакувальника перебирає мільярди сирих SHA-256 за секунду. PBKDF2 виконує HMAC(password, salt) знову і знову — iter разів — тож кожна здогадка коштує однакових iter HMAC і вам, і атакувальнику. Типове значення тут — 600 000 ітерацій з HMAC-SHA-256, базовий рівень Шпаргалки OWASP зі зберігання паролів; повзунок доходить до десяти мільйонів, бо рекомендації безпеки підвищуються разом із швидкістю обладнання.

Сіль. Випадкова сіль для кожного пароля означає, що однакові користувачі вже не хешуються однаково, а попередньо обчислені таблиці (райдужні таблиці) стають марними. Вона не таємна — зберігається поруч із хешем — вона лише має бути унікальною. 16 випадкових байтів — норма.

Відома слабкість. PBKDF2 важкий для ЦП, але не важкий для пам'яті: GPU і ASIC паралелізують його напрочуд добре. Тому сучасна порада — scrypt або Argon2id там, де проєктують зберігання хешів паролів (сторінка Генератора хешів паролів у цій родині їх описує), а PBKDF2 лишається правильною відповіддю для сумісності та налаштувань FIPS-140.

Що таке HKDF (RFC 5869)

Extract, потім expand. HKDF виконує дві роботи. Extract: стискає, можливо нерівномірний, вхідний матеріал ключа (наприклад, спільний секрет Діффі–Геллмана) разом із сіллю в один короткий псевдовипадковий ключ PRK = HMAC(salt, IKM). Expand: розтягує PRK до будь-якої довжини до 255 блоків хешу, причому кожен вихідний блок зчеплений із попереднім і позначений полем info. Результат: один секрет безпечно дає ключ шифрування, ключ MAC і IV, усі розділені.

Не для паролів. HKDF припускає, що його вхід уже має повну ентропію — він виконує один HMAC на 32 байти виходу, тож людський пароль проходить через нього практично миттєво, саме чого хоче атакувальник. Пропускати паролі через HKDF замість PBKDF2 — класична помилка дизайну; поле info призначене для міток призначення ("client traffic key", "server iv"), а не для додаткової ентропії.

Де ви з ним зустрічаєтесь. TLS 1.3 виводить кожен використовуваний ключ із секрету рукостискання через HKDF; WireGuard, Signal, EAP-TLS 1.3 і JSON Web Encryption (як KDF прямої домовленості про ключ) — усі з'являються на тому самому генеалогічному дереві.

Опорні значення — відтворіть їх на цій сторінці

Перші дві таблиці — це еталонні вектори, на яких побудовані кнопка «Зразок» і самотест цієї сторінки (ключ "key", повідомлення «The quick brown fox jumps over the lazy dog»; потім випадок у стилі RFC з 16-байтовим ключем 0x0b і повідомленням «Hi There»). Усі були згенеровані незалежною нативною реалізацією і повторно перевірені на цій сторінці.

HMAC від «fox», ключ = keyДайджест (hex)
HMAC-MD580070713463e7749b90c2dc24911e275
HMAC-SHA-1de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC-SHA-256f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA-384d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237
HMAC-SHA-512b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a
Опорні значення KDFПараметриВихід (hex, перші байти)
PBKDF2-HMAC-SHA-1password / salt, c=4096, 32 байти4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db
PBKDF2-HMAC-SHA-256password / salt, c=4096, 32 байти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, порожні salt і info, L=428da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8
Типові помилки
  • Плутання HMAC із шифруванням. HMAC доводить цілісність і походження (за наявності спільного секрету); він нічого не приховує. Будь-хто без ключа все одно бачить повне повідомлення.
  • Плутання HMAC із підписом. Цифрові підписи — з відкритим ключем: один підписує, будь-хто перевіряє. HMAC симетричний: кожен, хто перевіряє, також може підробити. Для незаперечності потрібні RSA/ECDSA (див. інструмент RSA цієї родини, коли його опублікують), а не HMAC.
  • Розбіжності прочитання ключа. 64-символьний hex-рядок, вставлений у поле текстового ключа, стає 64 байтами, а не 32 — і HMAC повністю змінюється. Ця сторінка друкує прочитання в рядку виводу; коли два інструменти не погоджуються, це перше, що варто порівняти.
  • Замала кількість ітерацій PBKDF2. 1000 ітерацій були розумними у 2000 році; сьогодні їх з'їдають GPU-ферми. Якщо ваша система досі зберігає хеші з 1000 ітерацій, сплануйте міграцію з переобчисленням при вході.
  • HKDF для пароля. Один HMAC на блок виводу означає, що пароль проходить миттєво — для паролів використовуйте PBKDF2 (або Argon2id), а для секретів з високою ентропією — HKDF.
  • Повторне використання одного виведеного ключа для всього. Виправлення безкоштовне: виводьте окремі ключі з різними мітками info. Два ключі з одного IKM із різними мітками незалежні за задумом.
Часті запитання (FAQ)

Чи зламаний HMAC-MD5? Як хеш стійкий до колізій MD5 мертвий, але безпека HMAC-MD5 залежить від MD5 як псевдовипадкової функції, і практичного зламу не відомо. Все одно відставлений — немає причин обирати його замість HMAC-SHA-256, окрім сумісності зі старим протоколом.

Якої довжини має бути ключ HMAC? Щонайменше розміру виходу хешу (32 байти для SHA-256) і згенерований CSPRNG. Ключ коротший за дайджест дозволений, але кожен біт нижче цього прямо зменшує безпеку.

Чи стає PBKDF2 з більшою кількістю ітерацій «безпечнішим» нескінченно? Він лінійно піднімає вартість для атакувальника, але так само лінійно і вашу вартість входу. Гра — обрати найбільшу кількість, яку витримають ваші користувачі; саме на це калібрують числа OWASP.

Чому HKDF обмежено 255 × розмір хешу? Цикл розгортання — T(i) = HMAC(PRK, T(i-1) || info || i) з однобайтовим лічильником i — 255 є найбільшим значенням лічильника, жорстким структурним обмеженням RFC 5869, а не вибором політики.

Яка різниця між PBKDF2 на цій сторінці і Генератором хешів паролів? Той самий алгоритм, інше завдання. Ця сторінка виводить сирі байти ключа, щоб ви використали їх деінде; сторінка хешів паролів створює рядки збережених облікових даних (із вбудованою сіллю і параметрами) і перевіряє вставлених кандидатів проти них.