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回のハッシュ反復を実行する必要があります。そのため、ユーザーの速度はわずかに低下しますが、攻撃者には不釣り合いな影響を及ぼします。 (実際、はるかに高い反復回数を使用することは非常に一般的です; 10000が一般的に推奨されます)。
また、最終出力キーが均一に配布されることを意味します。たとえば、パスワードを使用した場合、通常、キーの128ビットのうち16ビットは0になります(高ASCIIビット)。そのすぐすぐに、キー検索が必要以上に65536倍簡単になります。 、パスワードの推測も無視します。
最後に、AESには、関連するキー攻撃に関する特定の脆弱性があります。攻撃者がいくつかのキーで暗号化されたデータを知っていて、それらの間に既知の(または推測された)関係がある場合、関連するキー攻撃が可能です。たとえば、パスワードキー「My AES key sucks」(AES-128の場合は16バイト)と「MY AES KEY SUCKS」の両方でデータを暗号化した場合、関連するキー攻撃が可能です。現在最もよく知られている攻撃では、実際にこの方法でAESを完全に破壊することはできませんが、時間の経過とともに徐々に改善されています-先週、AES-256の13ラウンド(合計14回)関連するキー攻撃。そのような攻撃が時間の経過とともに改善しないことに依存することは、非常に賢明ではありません。