AES暗号化でランダムなデータをパディングする利点はありますか？

Question

AES暗号化を使用する場合は、平文を暗号ブロックサイズに埋め込む必要があります。ほとんどのライブラリと標準では、パディングバイトはパディングされていない平文の長さから判断できます。可能であれば、ランダムパディングバイトを使用する利点はありますか？

私は、機密ユーザーごとおよびセッションごとのデータを保存するための体系を実装しています。データは通常、JSONでエンコードされたキーと値のペアであり、潜在的に短くて繰り返し可能です。私は指導のためにPKCS#5を探していますが、DES3ではなく暗号化アルゴリズムにAESを使用する予定です。私はデータ項目ごとにランダムなIVと、ユーザーIDとパスワードまたはセッションIDで決まるキーを適切に計画していました。

私が驚いたことの1つは、平文のPKCS＃5パディングスキームです。暗号文を8バイトブロックにパディングするには、最後に1~8バイトが追加され、パディングバイトの内容はパディングバイト数（すなわち、01、0202、030303、最大で0808080808080808）に反映されます。私自身のパディングスキームは、平文の前にランダムなバイトを使用し、平文の最後の文字は追加されたパディングバイトの数になります。

私の推論は、AES-CBCモードでは、各ブロックが前のブロックの暗号文の関数であるということでした。このように、各平文にはランダム性の要素があり、既知の平文攻撃やIVや重要な問題から別の保護層を得ることができます。私の平文は短いと予想されるので、解読された文字列全体をメモリに保持し、前後のパッドをスライスすることは気にしない。

1つの欠点は、同じ暗号化されていない平文、IV、およびキーが異なる暗号文を生成し、単体テストを困難にすることです（不可能ではありません - テスト用に疑似ランダムパディングジェネレータを使用できます。製造）。

ランダムパディングを強制するには、最小2バイト、つまり1つのカウントと1つのランダムバイトを追加する必要があります。確定的なパディングの場合、最小値は1バイトで、平文または暗号文ラッパーに格納されます。

PKCS＃5のようなよく知られている標準では、確定的なパディングを使用することに決めたので、私が見逃したことがあるのか​​、それともあまりにも高いと判断しています。

Answer 1

どちらも、私は疑いがあります。利益はかなり小さいです。

暗号品質の乱数を取得または生成するランタイムコストを忘れてしまった。ある極端な場合には、無限の無限の供給が利用可能な場合（例えば、いくつかのシステムでは/ dev/random）、コードはより多くのランダムなバイトを待つ必要があります。

ランダムなバイトをPRNGから取得しているときに、同じランダムソースを使用してキーを生成していると、問題が発生する可能性があります。暗号化されたデータを次々に複数の受信者に送信する場合は、次の通信セッションのキーを選択するために使用されるPRNGの状態に関する情報を、前の受信者に与えました。あなたのPRNGアルゴリズムが完全にAESでの平文攻撃よりもIMOの方が壊れている場合は、故意に確定的なパディングを使用した場合よりもずっと悪くなります。

どちらの場合でも、パディングが発生しますが、PKCS＃5のパディングより計算量が多くなります。

脇に、潜在的に反復するデータを圧縮することは、例えば、それを暗号化する前に収縮させる。これによりデータの冗長性が減少し、特定の攻撃を実行するのがより困難になります。

最後に1つの推奨事項：ユーザー名とパスワードのみが異なるメカニズムでキーを導出することは非常に危険です。それを使用する場合は、既知の欠陥（MDA-5ではなくSHA-1ではない）を持たないハッシュアルゴリズムを使用することを確認してください。 cf this slashdot story

希望すると便利です。