Kalkulator HMAC, PBKDF2 & HKDF

Hitung kode autentikasi pesan berkunci dengan HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, atau HMAC-SHA-512 (RFC 2104) atas teks, byte hex, atau seluruh berkas — kunci sebagai teks, hex, atau Base64. Atau turunkan kunci dengan PBKDF2 (RFC 8018) dan HKDF (RFC 5869). Setiap hasil dapat ditampilkan sebagai hex, hex huruf besar, Base64, atau Base64url. Untuk digest biasa lihat Generator Hash; untuk checksum lihat Kalkulator CRC; untuk HMAC yang digunakan di dalam JWT lihat Dekoder JWT.
Berjalan sepenuhnya secara lokal — kunci dan pesan tidak pernah meninggalkan tab ini. Berkas hingga 200 MB.
Konstruksi: Output:
Algoritma HMAC: RFC 2104 — varian MD5 memerlukan md5.js (dimuat oleh halaman ini).
Kunci rahasia (rahasia bersama; panjang apa pun, teks di bawah dienkode UTF-8)
Pembacaan hex menerima spasi, titik dua, dan awalan 0x; Base64 harus dalam bentuk standar dengan atau tanpa padding.
Kunci kosong sah menurut RFC 2104 tetapi hampir selalu merupakan kesalahan — HMAC tanpa kunci hanyalah hash yang lambat.
Teks pesan (data yang diautentikasi, dienkode UTF-8)
Keluaran HMAC (satu baris: konstruksi, parameter, nilai)
Baris pertama mencatat parameter persis yang digunakan (algoritma, pembacaan, ukuran masukan), sehingga hasil yang disalin-tempel selalu dapat direproduksi.
Konstruksi mana yang Anda butuhkan?
HMAC mengubah rahasia bersama plus pesan menjadi autentikator: penerima yang mengetahui kunci dapat menghitungnya ulang dan mendeteksi perubahan. Itulah “HS256” di dalam setiap JWT yang ditandatangani (lihat Dekoder JWT) dan separuh skema penandatanganan permintaan API di dunia. PBKDF2 dipakai untuk meregangkan kata sandi manusia menjadi kunci: ia mengulang HMAC ribuan kali sehingga setiap tebakan kata sandi memakan waktu yang sama bagi penyerang. HKDF dipakai untuk kunci protokol: ia mengambil byte rahasia yang sudah acak (misalnya rahasia bersama DH) dan dengan aman merentangkannya menjadi beberapa kunci yang terikat tujuan — TLS 1.3 menurunkan semua kunci lalu lintasnya dengan cara ini. Aturan praktis: autentikasi → HMAC; kata sandi → PBKDF2 (atau scrypt/Argon2, lihat Generator Hash Kata Sandi setelah dipublikasikan); rahasia seragam → HKDF.
Uji mandiri
Menjalankan mesin halaman terhadap vektor yang dipublikasikan: 10 titik acuan HMAC (gaya RFC 2202/4231, lima algoritma × dua masukan), 6 titik acuan PBKDF2 (SHA-1 dan SHA-256 pada tiga jumlah iterasi), dan empat kasus uji RFC 5869 HKDF A.1–A.4. Tidak ada yang dikirim ke mana pun.
HMAC, PBKDF2 dan HKDF — hashing berkunci dijelaskan dari nol
Dalam satu kalimat: hash polos seperti SHA-256 dapat dihitung siapa pun, sehingga tidak membuktikan apa pun tentang siapa yang mengirim pesan — HMAC mencampurkan kunci rahasia sehingga hanya pemegang kunci yang dapat menghasilkan (atau memverifikasi) digest; PBKDF2 dan HKDF kemudian menggunakan kembali mesin HMAC yang sama untuk mengubah rahasia menjadi kunci, lambat untuk kata sandi dan cepat untuk materi yang sudah acak.
Apa itu HMAC (RFC 2104)

Konstruksinya. HMAC adalah dua kali eksekusi hash, bukan satu. Kunci Anda di-padding hingga ukuran blok hash (64 byte untuk MD5/SHA-1/SHA-256, 128 untuk SHA-384/512); pesan di-hash sekali dengan kunci XOR pad dalam yang tetap, dan digest itu di-hash lagi dengan kunci XOR pad luar yang tetap. Sandwich ganda ini terbukti aman selama hash dasarnya adalah fungsi pseudorandom yang layak — itulah sebabnya HMAC-MD5 tetap tahan terhadap serangan tabrakan praktis yang memecahkan MD5 biasa (meski tetap dipensiunkan, lihat di bawah).

Kunci. Panjang kunci apa pun dapat dipakai: yang lebih pendek dari ukuran blok dipakai apa adanya (tetapi di bawah 32 byte tidak dianjurkan), yang lebih panjang lebih dulu di-hash. Halaman yang sama memungkinkan Anda mengetik kunci sebagai teks, hex, atau Base64 sehingga kunci produksi 64 karakter hex dapat ditempelkan tanpa salah dibaca sebagai kata sandi teks 64 karakter — pembacaannya dicatat di baris keluaran karena alasan itu.

Di mana Anda menemukannya. Field HS256 dalam header JWT secara harfiah adalah HMAC-SHA-256 atas bagian token yang dienkode base64url (Dekoder JWT di situs ini menghitung persis itu ketika Anda menempelkan rahasia HS256). Tanda tangan webhook (Stripe, GitHub), AWS SigV4, perlindungan record TLS (versi lama), dan kerabat OpenSSH umac-64@openssh.com semuanya termasuk keluarga yang sama.

Mengapa tidak langsung hash(pesan || kunci)? Length extension: setiap hash keluarga MD5/SHA-1/SHA-2 memungkinkan penyerang yang mengetahui H(secret || msg) menghitung H(secret || msg || padding || apa pun) tanpa rahasianya. Pemisahan inner/outer HMAC mematikan kelas serangan itu. Ini adalah kesalahan DIY paling umum dalam kode tanda tangan API — dan alasan HMAC ada.

Apa itu PBKDF2 (RFC 8018)

Lambat secara desain. Sebuah kata sandi mungkin hanya memiliki sekitar 40 bit entropi nyata; GPU penyerang mencoba miliaran SHA-256 mentah per detik. PBKDF2 menjalankan HMAC(password, salt) berulang kali — iter kali — sehingga setiap tebakan menghabiskan iter HMAC yang sama bagi Anda dan penyerang. Default di sini adalah 600.000 iterasi dengan HMAC-SHA-256, baseline OWASP Password Storage Cheat Sheet; penggeser sampai sepuluh juta karena panduan keamanan terus naik seiring hardware makin cepat.

Salt. Salt acak per kata sandi berarti pengguna yang identik tidak lagi menghasilkan hash yang identik, dan tabel prakomputasi (rainbow table) menjadi tidak berguna. Salt tidak rahasia — ia disimpan di samping hash — ia hanya harus unik. 16 byte acak adalah standarnya.

Kelemahan yang diketahui. PBKDF2 berat secara CPU tetapi tidak berat secara memori: GPU dan ASIC memparalelkannya dengan sangat baik. Itulah sebabnya saran modernnya adalah scrypt atau Argon2id ketika penyimpanan hash kata sandi sedang dirancang (halaman Generator Hash Kata Sandi dalam keluarga ini membahasnya), dan PBKDF2 tetap jawaban yang tepat untuk kompatibilitas dan pengaturan FIPS-140.

Apa itu HKDF (RFC 5869)

Extract, lalu expand. HKDF melakukan dua tugas. Extract: memadatkan materi kunci masukan yang mungkin tidak merata (misalnya rahasia bersama Diffie–Hellman) bersama salt menjadi satu kunci pseudorandom pendek PRK = HMAC(salt, IKM). Expand: merentangkan PRK itu ke panjang apa pun hingga 255 blok hash, dengan setiap blok keluaran dirantai ke blok sebelumnya dan diberi tag oleh field info. Hasilnya, satu rahasia dapat dengan aman menghasilkan kunci enkripsi, kunci MAC, dan IV, semuanya terpisah.

Bukan untuk kata sandi. HKDF mengasumsikan masukannya sudah memiliki entropi penuh — ia melakukan satu HMAC per 32 byte keluaran, sehingga kata sandi manusia melewatinya hampir seketika, persis yang diinginkan penyerang. Memasukkan kata sandi lewat HKDF alih-alih PBKDF2 adalah kesalahan desain klasik; field info untuk label tujuan ("client traffic key", "server iv"), bukan untuk menambah entropi.

Di mana Anda menemukannya. TLS 1.3 menurunkan setiap kunci yang digunakannya dari rahasia handshake melalui HKDF; WireGuard, Signal, EAP-TLS 1.3, dan JSON Web Encryption (sebagai KDF kesepakatan kunci langsung) semuanya berada di pohon keluarga yang sama.

Nilai acuan — reproduksi di halaman ini

Dua tabel pertama adalah vektor uji yang menjadi dasar tombol Contoh dan uji mandiri halaman ini (kunci "key", pesan “The quick brown fox jumps over the lazy dog”; kemudian kasus bergaya RFC dengan kunci 0x0b sepanjang 16 byte dan pesan “Hi There”). Semuanya dihasilkan oleh implementasi native independen dan diverifikasi ulang di halaman ini.

HMAC dari “fox”, kunci = keyDigest (hex)
HMAC-MD580070713463e7749b90c2dc24911e275
HMAC-SHA-1de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC-SHA-256f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA-384d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237
HMAC-SHA-512b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a
Titik acuan KDFParameterKeluaran (hex, byte pertama)
PBKDF2-HMAC-SHA-1password / salt, c=4096, 32 byte4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db
PBKDF2-HMAC-SHA-256password / salt, c=4096, 32 bytec5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a
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 dan info kosong, L=428da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8
Kesalahan umum
  • Mencampuradukkan HMAC dengan enkripsi. HMAC membuktikan integritas dan asal (dengan rahasia bersama); ia tidak menyembunyikan apa pun. Siapa pun tanpa kunci tetap melihat pesan utuh.
  • Mencampuradukkan HMAC dengan tanda tangan. Tanda tangan digital bersifat kunci-publik: satu pihak menandatangani, siapa pun dapat memverifikasi. HMAC bersifat simetris: setiap verifier juga dapat memalsukan. Untuk non-repudiasi Anda memerlukan RSA/ECDSA (lihat alat RSA di keluarga ini setelah dipublikasikan), bukan HMAC.
  • Ketidakcocokan pembacaan kunci. String hex 64 karakter yang ditempel ke kotak kunci Teks menjadi 64 byte, bukan 32 — dan HMAC-nya berubah sepenuhnya. Halaman ini mencetak pembacaan di baris keluaran; ketika dua alat tidak sepakat, itulah hal pertama yang dibandingkan.
  • Iterasi PBKDF2 terlalu rendah. 1.000 iterasi wajar di tahun 2000; hari ini rig GPU memakannya dengan mudah. Jika sistem Anda masih menyimpan hash 1.000 iterasi, rencanakan migrasi hash-ulang saat login.
  • HKDF untuk kata sandi. Satu HMAC per blok keluaran berarti kata sandi melewatinya seketika — gunakan PBKDF2 (atau Argon2id) untuk kata sandi dan HKDF untuk rahasia berentropi tinggi.
  • Menggunakan ulang satu kunci turunan untuk semuanya. Solusinya gratis: turunkan kunci terpisah dengan label info yang berbeda. Dua kunci dari satu IKM dengan label berbeda independen menurut desainnya.
FAQ

Apakah HMAC-MD5 rusak? Sebagai hash tahan-tabrakan, MD5 sudah tidak berlaku, tetapi keamanan HMAC-MD5 bergantung pada MD5 sebagai fungsi pseudorandom, dan tidak ada pematahan praktis yang diketahui. Tetap saja sudah dipensiunkan — tidak ada alasan memilihnya dibanding HMAC-SHA-256 kecuali demi kompatibilitas dengan protokol lama.

Seberapa panjang kunci HMAC seharusnya? Setidaknya sebesar ukuran keluaran hash (32 byte untuk SHA-256) dan dihasilkan oleh CSPRNG. Kunci yang lebih pendek dari digest diizinkan, tetapi setiap bit di bawahnya langsung mengurangi keamanan.

Apakah PBKDF2 dengan lebih banyak iterasi menjadi “lebih aman” tanpa batas? Ia menaikkan biaya penyerang secara linear, tetapi juga biaya login Anda secara linear. Permainannya adalah memilih jumlah terbesar yang masih dapat ditoleransi pengguna — itulah yang dikalibrasi oleh angka-angka OWASP.

Mengapa HKDF dibatasi 255 × ukuran hash? Loop expand adalah T(i) = HMAC(PRK, T(i-1) || info || i) dengan penghitung satu byte i — 255 adalah nilai penghitung terbesar, batas struktural keras dari RFC 5869, bukan pilihan kebijakan.

Apa perbedaan PBKDF2 di halaman ini dengan Generator Hash Kata Sandi? Algoritma yang sama, tugas berbeda. Halaman ini menurunkan byte kunci mentah untuk digunakan di tempat lain; halaman hash kata sandi menghasilkan string kredensial tersimpan (dengan salt dan parameter yang tertanam) dan memverifikasi kandidat yang ditempel terhadapnya.