HKDF 鍵導出計算 | RFC 5869 を Extract と Expand に分けて検証

HKDF (HMAC-based Key Derivation Function) の中間値を 2 段に分けて確認するツール。IKM・salt・info を入れて SHA-256/384/512 を選ぶと、Extract 段の PRK (擬似ランダム鍵) と Expand 段の OKM (出力鍵素材) を hex で表示する。鍵スケジュールの照合やテストベクトルの再現に使う。

💡 このツールについて

TLS 1.3 や Signal Protocol、Noise Framework の鍵スケジュールを実装すると、ライブラリが返す鍵が仕様どおりか確認したい場面が出る。HKDF は内部的に「Extract → Expand」の 2 段だが、多くのライブラリは一発の HKDF(ikm, salt, info, length) しか公開せず、中間の PRK が見えない。値が合わないとき、Extract で詰まっているのか Expand で詰まっているのかを切り分けられない。

このツールは PRK = HMAC(salt, IKM) を独立して表示し、その PRK から導いた OKM も並べて出す。salt を空にした場合は RFC 5869 の規定どおり HashLen バイトのゼロが salt として使われる。OKM の最大長は 255×HashLen バイト (SHA-256 なら 8160 バイト) で、これを超える要求はエラーになる。計算は標準の Web Crypto API (crypto.subtle) の HKDF と HMAC をそのまま呼んでいるため、ブラウザ実装と同じ結果が返る。

入力した IKM・salt・info は鍵素材そのもので、外部に送信されずブラウザ内だけで処理される。テスト用の鍵を安心して貼り付けられる。

🧐 よくある質問

Q. PRK と OKM の違いは? PRK (Pseudorandom Key) は Extract 段の出力で、salt を鍵とした IKM の HMAC。ハッシュ長と同じ固定長になる。OKM (Output Keying Material) は Expand 段の出力で、PRK と info から任意長 (要求バイト長) を伸ばした最終鍵。実際にアプリで使うのは OKM 側。

Q. salt を空にするとどうなる? RFC 5869 では salt 省略時に HashLen バイトのゼロ列を salt とすると定めている。本ツールも同じ挙動で、Salt 欄を空にすれば自動でゼロ salt が使われる。

Q. 入力は hex で入れる? 文字列で入れる? このツールは IKM・salt・info を UTF-8 のバイト列として扱う。abc と入れれば 3 バイト (0x61 0x62 0x63)。生のバイト列をそのまま指定したい場合は、対応する文字列を入力欄に置く形になる点に注意。

Q. OKM の最大長は? 255×HashLen バイト。SHA-256 は 8160、SHA-384 は 12240、SHA-512 は 16320 バイトまで。これは Expand の counter が 1 バイト (1〜255) である規格上の制限。

Q. PBKDF2 や Argon2 と何が違う? PBKDF2 や Argon2 はパスワードを意図的に遅く伸ばす「鍵ストレッチング」。HKDF は既に高エントロピーな鍵素材を複数の用途別鍵に「分配」するためのもので、遅くする仕組みは持たない。用途が違う。

Q. 出力が他ツールと合わない salt のゼロ埋め扱い、info の有無、UTF-8 とバイト直指定の差で値が変わる。3 入力のバイト列が完全一致しているか確認する。

📚 豆知識

HKDF は 2010 年に Hugo Krawczyk と Pasi Eronen が RFC 5869 として標準化した。設計思想の「Extract-then-Expand」は、まず雑多なエントロピーを一様な PRK に「絞り出し (extract)」、それを必要な数の鍵に「展開 (expand)」するという 2 段構成。この分離のおかげで、Diffie-Hellman の共有秘密のように偏りのある入力からでも安全に鍵を作れる。TLS 1.3 の鍵スケジュールはこの HKDF を中核に組まれており、HKDF-Expand-Label という独自ラベル付き Expand を多用する。info フィールドに用途文字列を入れて鍵を分けるのは、同じ IKM から「暗号化用」「認証用」を独立に導くための定石になっている。