Keepass辞書攻撃防御戦略
かなり興味がありますが、私はすべて情報セキュリティの専門家ですが、質問が愚かである場合は参考になるリソースにリダイレクトするか、想定が間違っている場合は修正してください。
Keepass Securityページ を読んだとき、ユーザーが入力したパスワードからkdbxファイルを暗号化するために実際に使用されるパスワードを生成するワークフロー（キーファイルまたはWindowsがないと仮定）ユーザーアカウントが使用されます）は次のとおりです。
- ユーザーが入力したパスワードを取得してハッシュする（SHA-256）
- ランダムなパスワードを生成/ kdbxファイルから再取得
- 2からのキーを使用して、ハッシュを1
N回暗号化します - SHA-256を再度使用して3の出力をハッシュする
次に、4の出力は、データベースの暗号化に実際に使用されるキーです。
私が不思議に思っているのは、なぜプレーンと暗号化でキーを保存するのが面倒なのですか？手順2と3を省略して、ユーザーが入力したパスワードN（またはC*N、CはAES暗号化とSHA-256ハッシュ）時間の時間関係です）？私はここで重要な何かを見落としていると確信しています。あなたが私を啓発してくれるなら、私は感謝します。
[開示：1PasswordのメーカーであるAgileBitsで働いている]
私の履歴はここでは間違っているかもしれませんが、KeePassはPasswordSafeデータベースで動作するように設計されており、PasswordSafeはPBKDF2が一般的に採用される前に設計されたと思います。したがって、ここで見ているのは、PBKDF2が実行するように設計された仕事を実行するための「自作」アプローチです。 （そしてもちろんPBKDF2は理想的ではありません。それが世界が後継者を求めている理由です）。
各ラウンドのPRFは実際には大きな違いではないため、両方がPRFであるため、HMAC（PBKDF2で通常使用される）よりもAES（KeePassで）を選択することは実際には大きな違いではありません。確かに、PBKDF2はそのようなモードで使用できます（HMACで使用されるのを見たことがありません）。
興味深いことに、どちらの方式もPRFに一定の鍵/塩を使用するという問題に悩まされています。これは現在、PBKDF2の（小さい）問題（大きい問題の1つ）として認識されています。
だから私の頭の上から、そしてあなたの上記の説明だけに基づいて、私はそのスキームがPBKDF2よりも悪いとは思いません（少しは良いですが）。派生キーのサイズの柔軟性の点ではPBKDF2ほど一般的ではありませんが、それはおそらく良いことです。それ以外は、（ここでも、一見しただけで）長所と短所がPBKDF2-HMACに非常に似ているように見えます。
長年にわたり、私はPBKDF2を「ピーナッツバターも犬をフレンドリーに保つ」と表現することから「人々の赤ちゃんもディンゴフィードを守る」にまで移行してきました。それにもかかわらず、1Passwordでは引き続き（慎重に）使用しますが、 PBKDF2、scrypt、およびbcryptの後継 を待ち望んでいます。
KeePassが行うのは、プロセスの一部としてAES暗号化を使用するカスタムパスワードハッシュのようです。ここでのAESキーはsaltの役割を果たします。 saltは、秘密でないパラメータであり、入力パスワードの処理に使用される実際の関数を選択します（つまり、oneハッシュ関数はありませんが、ファミリー全体であり、saltは、どちらを使用するか）。ソルトは事前計算されたテーブルを阻止し、より一般的には、攻撃インスタンス間のコスト共有を防ぎます。他のハッシュされたパスワードは別のソルトを使用するため、攻撃者はハッシュされたパスワードを別のハッシュされたパスワードにクラックするために費やした作業を再利用できません。
より理論的には、パスワードハッシュ関数についての実践が利用可能です there 。
KeePass関数はカスタムデザインのようですが、これは（一般的に言えば）悪いことです。さらに、これはAESに基づいているため、攻撃者は AES-NI opcodes を含むPC、つまり基本的なPCを使用して攻撃を高速化できます。