web-dev-qa-db-ja.com

AESおよびSHA2でのPBKDF2の使用

AESを使用して暗号化するには、次の入力を使用します。

  • UserPassword(プレーンテキスト)
  • SecretKey
  • RandomIV


SHA512を使用して暗号化するには、次の入力を使用します。

  • UserPassword(プレーンテキスト)
  • ランダム塩


鍵導出機能を使用して、上記の両方の暗号化方法を強化したいと思います。以下を必要とする.NET Rfc2898DeriveBytesクラスを使用します。

  • マスターパスワード
  • 反復


AESの場合:

PBKDF MasterPasswordパラメータにAES SecretKeyを使用する必要がありますか?現在、AES RandomIVを生成し、IV + CIPHERをDBに保存しています。PBKDFを使用するようにアップグレードする場合、次のことを行うのが適切です。

  • AES RandomIVを生成しない
  • PBKDFの新しいランダムソルトを生成します
  • DerivedKeyの最初のxビットをAES SecretKeyとして使用する
  • DerivedKeyの2番目のxビットをAES RandomIVとして使用します
  • 「新しいランダムソルト」+ CipherTextをDBに保存します
  • AES EncryptメソッドとDecryptメソッドの両方に、AES IVパラメータではなくPBKDF Saltパラメータが含まれます(どちらも単なるバイト[]であるという事実を無視してください)


SHA512の場合:

  • (AESのような秘密のMasterPasswordを安全に保存する代わりに)PBKDF MasterPasswordパラメータにUserPassword(プレーンテキスト)を使用することは正しいですか?

  • SHA512 RandomSaltをPBKDFソルトとして使用する必要がありますか?

  • SHA.computehashメソッドを呼び出す場合、hasedによるDerivedKeyのみにする必要がありますか、それともソルトをDKに追加する必要がありますか?

  • 暗号化する必要があるDerivedKeyのバイト数は64ですか?

4
ShocK

いくつかの基本ルールを邪魔にならないようにしましょう。 SHA512は暗号化関数ではなく、ハッシュ関数です。 PBKDF2(新しい2番目のバリアントを使用していると想定しています...)はハッシュ関数でも暗号化関数でもありません。ハッシュ関数を使用する方法であり、ブロック暗号またはストリーム暗号のキーを生成するために一般的に使用されます。

ほとんどの場合、PBKDF2はあまり役に立たないと思います。問題は、PBKDF2でSHA512のようなハッシュ関数を使用する場合、攻撃者は引き続きFPGAまたはGPUクラスタを使用できることです。 Bcryptは、これらのテクノロジーを使用して攻撃するのがより困難です PBKDF2での使用を選択したラウンドの数に関係なく、PBKDF2 + SHA512よりも攻撃しやすくなっています。 PBKDF2 + Bcryptを使用することもできますが、これは悪い選択ではありませんが、CPU使用量とメモリ使用量の両方が可変であるため、 scrypt の方が適していると思います。使用されるハッシュ関数は可変です。

次のIVデザイン:

Use the first x bits of the DerivedKey as the AES SecretKey
Use the second x bits of the DerivedKey as the AES RandomIV

わかりましたので、この設計に基づいて、IVが何であるか、またはIVがなぜ使用されているのかを理解していないと思います。つまり、IVのポイントは、同じメッセージを同じキー+ ivで暗号化しないことです。提案された設計は、明らかに CWE-329 に違反しています。攻撃者はIVを知ることができますが、それは重要ではありませんが、常にランダムである必要がありますいくつかの理由 があり、 Practical Cryptography のコピーを入手することをお勧めします。これは、このトピックに関する章全体が含まれているためです。

また、CBCモードは認証されていません。私は OMAC1モード のファンです。

7
rook