AES-256 GCMに渡すkeyに、パスワードそのものではなく、鍵導出関数（PBKDF2など）で生成したハッシュ値を指定する理由は？

Question

以前書いた、「あるデータをパスフレーズで暗号化し、公開ストレージ（URLが判明すれば誰でも読み取り可能）に暗号化ファイルの形式で保存し（期間は無期限）、あとからパスフレーズで復号して読み取るためのコード」を改修するため、「AES-256 GCM、または、ChaCha20-Poly1305を用いて、データを1つのパスフレーズを用いて暗号化するライブラリ」をTypeScriptで書こうと考えています。

この場合の要件は：

• 暗号化したデータは、第三者が自由に読み取り可能であり、その場合でも安全性を保つ必要がある
• 暗号化したデータは、無期限で利用される場合がある。したがって、短期間のみ用いるものではない
• 暗号化したデータには、パスフレーズを除く、復号に必要な情報がすべて含まれる。暗号化と複合に必要な秘密情報はパスフレーズのみ

になります。例えるなら、Gitリポジトリ内で特定のファイルを暗号化するような場合や、「パスワード管理ツールが生成する暗号化データベース」のようなファイルを生成したい場合に用いるものです。

先行事例を探していたところ、以下のものを発見しました。

jeanlescure/string-crypto

このパッケージは、AES-256 GCM方式で平文とパスワードを元に暗号化を行っています。しかし、パスワードを直接AES-256 GCMのkeyには指定せず、鍵導出関数のPBKDF2を使用してハッシュ化していました。この理由がわかりません。

私の理解では、AES-256 GCMの暗号化と復号には、平文以外に「256bitのkey」と「96bitのIV（Initialization Vector；初期化ベクトル）」が必要です。このうち、IVは秘密である必要はありません。したがって、keyのみが秘密情報であり、暗号文からはkeyが絶対に解析できないはずです。（でなければ暗号の意味がない）

一方、鍵導出関数はパスワード/パスフレーズのハッシュ化に用いるためのもので、私の理解では「データベースに『パスワード/パスフレーズの平文』の代わりにハッシュ値を保存し、データの漏洩時にパスワード/パスフレーズの平文を知られないようにするためのもの」です。

よって、AES-256 GCMのkeyに鍵導出関数のハッシュ値を用いる理由として考えられるのは、「keyが暗号文から読み取られた場合」のための備えであると思われます。しかし前述したように、暗号の意味が無くなる「keyが暗号文から読み取られた場合」という想定自体がありえないはずです。

そうなると、パスワード/パスフレーズを鍵導出関数でハッシュ化する理由として考えられるのは、「任意長のパスワード/パスフレーズを256bitの長さのkeyに変換」するためというものです。しかしこれなら、鍵導出関数を用いなくとも、SHA-256などで代用できるはずです。

SHA-256などを使用せず、代わりに鍵導出関数を使う理由として考えられるのは、「不適切に複数のハッシュ関数を利用すると、脆弱になる場合がある」というどこかで聞きかじった情報ですが、確証が得られていません。

まとめると、

• 鍵導出関数を使う理由は、パスフレーズ（として使われる値）が漏洩した場合の備え
• しかし、AES-256 GCMのkeyが暗号文から漏洩する可能性は考えられない
• AES-256 GCMのkeyに鍵導出関数のハッシュ値を用いる理由が不明

という疑問が生じます。

なぜ、暗号文から内容が判明しないはずのkeyに、鍵導出関数を用いたハッシュ値を指定するのでしょうか？

Answer 1

パスワードをそのまま鍵として用いるよりも、パスワードを鍵導出関数に通して得られた値を鍵として使用した方が、より安全性が高まるからです。

攻撃者は、初期化Vectorとユーザーが使いそうなパスワード（pass、12345、hogehoge等）を手あたり次第使うことによって復号を試みることができます。（辞書攻撃）

ここで、パスワードがそのまま鍵として使われている場合と、パスワードを鍵導出関数に反復して通して得た値が鍵として使用されている場合とを比較すると、後者の方が計算負荷が高いため、単位時間あたりの攻撃試行回数を少なくすることができます。

SHA-256などを使用せず、代わりに鍵導出関数を使う理由

PBKDF2は、iteration（反復回数）の設定によって計算負荷を柔軟に変更し、安全性を高めることができるからです。
（iteration＝パスワードに関数を通して出てきた値をもういちど関数に通す、ということを繰り返す回数（「ストレッチング」））

SHA-256そのものは単純にハッシュを作るだけであり、パスワードにSHA-256を通して得られた値をそのまま使う場合は計算負荷が低いため、鍵導出関数の中で反復して得た値を使用する場合と比較して辞書攻撃に弱いといえます。

もちろん独自実装すればSHA-256だけを利用して、PBKDF2と同じようなものはできるでしょう。

しかしPBKDF2の方が長い歴史の中で破られておらず、また既に多様なプラットフォームで動くライブラリが存在するという強みがあると考えられます。

RFC8018がPBKDF2を推奨していることからも、暗号化関係のソリューションにおいて、鍵導出関数としてPBKDF2を使用することはデファクトスタンダードであり、一種の御作法みたいなイメージなのでしょう。
（計算機の能力が飛躍的に向上した現状、PKDF2は既に弱いともいわれているらしいですが（wikipedia中段「PKDF2の代替」参照））

なお、PBKDF2も反復回数やsaltの設定次第で攻撃耐性が変わります。

質問文に記載のstring-cryptoのデフォルト実装 を見ると、
・saltに「s41t」という固定値が使用されている。
・iterationが1回
ということから、デフォルトの状態ではあまり意味がありません。
実際には option でカスタマイズして使用すべきです。

ユーザビリティ（パスワードを知っている正規ユーザーがパスワードを使って鍵を開くまでの待ち時間）とのトレードオフになりますが、
安全性を高めるならば、iterationをもっと多くするべきでしょう。（例：iOS4は1万回のストレッチングを行っているとの情報）
さらにsaltをパスワードごとに異なる長いランダム値にすれば、より安全です。

（そもそもPBKDF2では使用するハッシュアルゴリズムを指定するようになっていて、そこにSHA-256を指定することも可能です。
PBKDF2は指定したハッシュアルゴリズムを利用しつつ、saltやiteration等のパラメータに基づいてパスワードを加工し最終的な鍵を作ります。

したがってPBKDF2はSHA-256と競合する関係というよりは、料理(鍵）を作るためのシェフとレシピのような関係ともいえるでしょう。

パスワードとsaltを材料にして、シェフ（PKDF2）が、レシピ（指定されたハッシュアルゴリズムとiteration）に基ついて料理（鍵）を作る。
レシピ（SHA-256）だけでも鍵は作れますが、saltとiterationで手間暇をかけるともっとおいしい料理（安全性の高い鍵）が作れます）

Comments

[sounisi5011]

「AES-256 GCMの暗号文に対する辞書攻撃」の発想は完全に抜けていました。ありがとうございます！

Answer 2

qnoir氏の回答がありますので、それでほぼ十分かと思うのですが、蛇足ながら。

そうなると、パスワード/パスフレーズを鍵導出関数でハッシュ化する理由として考えられるのは、「任意長のパスワード/パスフレーズを256bitの長さのkeyに変換」するためというものです。しかしこれなら、鍵導出関数を用いなくとも、SHA-256などで代用できるはずです。

そもそもの大前提として、「パスワード/パスフレーズはランダムに鍵を作る場合に比べて一般に情報量が少ない」というのがあります。
※256bit鍵をbase64で印字可能な文字列に変換したとして40文字超になることを考えてみてください。

そのため、額面として256bitの暗号強度だったとしても、パスワードの総当たり、場合によっては辞書も使った攻撃に対して、額面よりもはるかに低い強度になってしまいます。

そこをある程度でも補うための対策としてのsaltとストレッチングを盛り込んだKDFと見れば良いかと思います。

もし、素のパスワードで十分な情報量が得られるのであれば、単なるSHA-256でも十分でしょう。
※それだったらランダムな鍵情報をそのままエンコードしてパスワードにした方が早い気もしますが。