[解決済み] なぜ、パスワードを鍵やIVとして直接使用するのではなく、Rfc2898DeriveBytesクラス（.NET）を使用する必要があるのでしょうか？

質問

Rfc2898DeriveBytes を使う場合と、単に Encoding.ASCII.GetBytes(string object); ?

私はどちらの方法でも比較的成功しています。前者はより長ったらしいアプローチで、後者はシンプルで要領が良いです。どちらも最終的には同じことをすることができるようですが、前者を後者より使用することの意味を理解するのに苦労しています。

私が把握できた基本的なコンセプトは、文字列のパスワードをバイト配列に変換して バイト配列に変換して、たとえば対称型暗号化クラスで使用できることです。 AesManaged . RFCクラスを介してですが、rfcオブジェクトを作成する際にソルト値とパスワードを使用するようになります。私はその方がより安全だと思いますが、それでもせいぜい無学な推測に過ぎません。また、特定のサイズのバイト配列を返すことができること、まあそのようなものです。

私がどこから来たかを示すために、いくつかの例を挙げます。

byte[] myPassinBytes = Encoding.ASCII.GetBytes("some password");

または

string password = "P@%5w0r]>";
byte[] saltArray = Encoding.ASCII.GetBytes("this is my salt");
Rfc2898DeriveBytes rfcKey = new Rfc2898DeriveBytes(password, saltArray);

rfcKey' オブジェクトは、対称型暗号アルゴリズムクラスの .Key または .IV プロパティを設定するために使用することができます。 を設定するために使用することができます。

すなわち

RijndaelManaged rj = new RijndaelManaged ();
rj.Key = rfcKey.Getbytes(rj.KeySize / 8); 
rj.IV = rfcKey.Getbytes(rj.Blocksize / 8);

'rj'は準備完了です !

紛らわしいのは......つまり、'rfcKey' オブジェクトを使うのではなく、私の 'myPassInBytes'配列を使用して、'rj'オブジェクトをセットアップすることはできないのでしょうか？

VS2008 でこれを試してみましたが、即座の答えは「NO」でした。しかし、なぜ RFC クラスが、私が上記で述べた他の選択肢よりも使用されるのか、より教育された答えを持っていますか?

どのように解決するのですか。

ユーザーパスワードを直接暗号鍵として使用することは、本当に、本当に避けたいことです。 特に AES では特にそうです。

Rfc2898DeriveBytes は PBKDF2 の実装です。これは、ユーザーパスワードとソルトを繰り返しハッシュ化するものです。これには複数の利点があります。

まず、任意のサイズのパスワードを使用できます。AESは特定のキーサイズしかサポートしていません。

第二に、ソルトの追加は、複数の異なる鍵を生成するために同じパスフレーズを使用できることを意味します (あなたの例のように、ソルトが一定でないと仮定しています)。これは、鍵の分離にとって重要です。異なるコンテキストで鍵を再利用することは、暗号化システムが破壊される最も一般的な方法の 1 つです。

複数の反復処理 (デフォルトでは 1000) は、パスワード推測攻撃の速度を低下させます。誰かがあなたの AES 鍵を推測しようとしている場合を考えてみてください。パスワードを使用するだけなら、これは簡単なことです。一方、PBKDF2の場合、攻撃者はまず1000回のハッシュ反復を行い、その結果 それぞれの のハッシュ化を1000回行う必要があります。したがって、ユーザーの速度はわずかに低下しますが、攻撃者にとっては不釣り合いな効果があります。(実際には、より高い反復回数を使用することは非常に一般的であり、10000 が一般的に推奨されています)。

また、最終的な出力キーが一様に分布していることを意味します。たとえば、パスワードを使用した場合、通常、鍵の128ビットのうち16ビットは0（高ASCIIビット）になります。このことは、パスワードの推測を無視したとしても、キーサーチを直ちに 65536 倍も簡単にしてしまいます。

最後に、AES には関連する鍵の攻撃に関する特定の脆弱性があります。関連キー攻撃は、攻撃者がいくつかのキーで暗号化されたデータを知っていて、それらの間に何らかの既知の（または推測された）関係がある場合に可能です。例えば、パスワードキーとして "My AES key sucks" (16 bytes, for AES-128) と "MY AES KEY SUCKS" の両方でデータを暗号化した場合、関連キー攻撃が可能かもしれません。現在最もよく知られている攻撃は、実際にはこの方法でAES全体を破ることはできませんが、時間とともに徐々に良くなってきています。ちょうど先週、関連キー攻撃を使ってAES-256の13ラウンド（合計14ラウンドのうち）を破る新しい攻撃が発表されました。先週、関連する鍵攻撃を使ってAES-256の13ラウンド（全14ラウンド中）を破る新しい攻撃が発表されました。このような攻撃が時間とともに改善されないことに依存するのは、非常に賢明ではありません。