4

暗号化にAESを使用し、データの整合性をチェックするためにCRCを使用していますが、私の場合、CRCチェックは冗長であるという印象があります。私は次のことをしています：

暗号化：

  1. ペイロードデータを取得し、そこからCRCを計算します
  2. ペイロードデータとCRCを暗号化する

復号化：

  1. データを復号化する
  2. ペイロードデータの新しいCRCを計算し、古いCRCと比較します

単体テストでCRCチェックの失敗を引き起こしたかったのですが、ペイロードデータを操作すると、復号化によって常にBadPaddingExceptionがスローされます。

私の質問は、データが破損または操作されたときに復号化が常にこの例外をスローする場合（そうなるでしょうか？）、CRCチェックは私が使用している方法で冗長ではありませんか？

4

1 に答える 1

3

誤って復号化されたデータが均一に分散されていると仮定すると、255個の誤ったパスワードごとに約1回正しくPKCS5/PKCS7が埋め込まれているように見えます。これは、正しい変更が発生し、アイテムがゴミ箱に復号化される可能性がまだ1/255であることを意味します。したがって、チェックは無駄ではありません。

実際に期待する動作が必要な場合は、「AES / CTR / NoPadding」を使用できます。これは、正確なブロックサイズを必要とせず、キーが一致するかどうかに関係なく、常に復号化されたbyte[]を返します。

ただし、攻撃者が暗号文を繰り返し変更して復号化できる場合（たとえば、Cookieに保存されている暗号化されたデータなど）、復号化されたデータが不正なパディングの例外をスローした場合と、単にゴミを捨てれば、「パディングオラクル攻撃」を介して平文を判別できます。

また、メッセージの整合性を確保するために、SHA-256のようにCRCよりも堅牢なフィンガープリントが適切かどうかを検討することもできます。

これの多くはから繰り返されます：AES BadPaddingException

于 2013-01-11T11:35:16.860 に答える