0

ユーザーからパスフレーズを取得し、暗号化されたデータをファイルに書き込むプログラムを作成しています。これまでに私が思いついた方法は次のとおりです。

  • ファイル名とシステム時刻をハッシュして 128 ビット IV を生成し、これをファイルの先頭に書き込みます。
  • SHA256 を使用してパスフレーズから 256 ビット キーを生成します。
  • CBC モードの AES を使用して、このキーでデータ (32 ビットの静的署名で始まる) を暗号化し、ファイルに書き込みます。

復号化するときは、IV が読み取られ、パスフレーズを使用して同じ方法でキーが生成されます。最初の 32 ビットが署名と比較され、キーが有効かどうかが判断されます。

ただし、 PolarSSL (ハッシュと暗号化を行うために使用しているライブラリ)で提供されているAES の例を見ていましたが、はるかに複雑な方法を使用しています。

  • ファイル名とファイル サイズをハッシュして 128 ビット IV を生成し、これをファイルの先頭に書き込みます。
  • パスフレーズと IV を 8192 回ハッシュ (SHA256) して 256 ビット キーを生成します。
  • このキーで HMAC を初期化します。
  • CBC モードで AES を使用してこのキーでデータを暗号化し、暗号化された各ブロックで HMAC を更新しながらファイルに書き込みます。
  • HMAC をファイルの末尾に書き込みます。

2 番目の方法の方が安全であるという印象を受けますが、複雑に見えることを除けば、それを裏付ける十分な知識がありません。

  • より安全である場合、その理由は何ですか?
  • ファイルの末尾に HMAC を追加することは、暗号化されたデータの先頭に署名を付けるよりも安全ですか?
  • 8192回ハッシュするとセキュリティが向上しますか?

注:これはオープン ソース プロジェクトであるため、どのような方法を使用しても、誰でも自由に利用できます。

4

1 に答える 1

3

2 番目のオプションはより安全です。

あなたの方法は、メッセージの完全性を提供しません。これは、攻撃者が暗号文の一部を変更し、平文が復号化したものを変更できることを意味します。32 ビットの静的署名を変更するような変更を加えない限り、信頼できます。2 番目の方法の HMAC は、メッセージの整合性を提供します。

キーを 8192 回ハッシュすることで、誰かがキーをブルートフォースしようとするための追加の計算手順が追加されます。ユーザーが辞書ベースのパスワードを選択するとします。あなたの方法では、攻撃者は実行SHA256(someguess)してから復号化を試みなければなりません。ただし、PolarSSL バージョンでは、SHA256(SHA256(SHA256...(SHA256(someguess)))8192 回計算する必要があります。これは攻撃者を遅くするだけですが、(今のところ) 十分かもしれません。

それだけの価値がある場合は、既存のライブラリを使用してください。暗号化は難しく、微妙な間違いを犯しがちです。

于 2013-11-07T20:51:34.673 に答える