職場の私の部門は、別の部門によって作成された暗号化ライブラリを使用する権限によって要求されています。問題は、暗号化ライブラリが AES カウンター モードの初期化ベクトル (すべてゼロ) をハードコーディングしていることです。(基本的に、他の部門は Bouncycastle ライブラリを取得し、独自の壊れたコードをラップしました。) 私たちはこのコードの問題を文書化しました。 .
一意の IV を平文の先頭に追加し、復号化後に平文の最初の 16 バイトを切り捨てることで、適切な初期化ベクトルを偽造できるかどうか疑問に思っています。
ciphertext = encrypt(++sixteenByteCounter + plaintext)
plaintext = decrypt(ciphertext).subArray(16, ciphertext.length)
これは私には問題ないように思えますが、私は暗号化の専門家ではありません
いやぁぁぁぁぁ....
CTR モードでは、一連の数字 (1、2、3...) を暗号化し、それに対してメッセージを XOR します。
再利用されたシーケンスに対して XOR 値を使用する暗号化は、非常に簡単にクラックできます。したがって、CTR モードでこれを回避するには、毎回ランダムなオフセットから開始します (たとえば、1 から開始するのではなく、75437454896785 から開始します)。それがCTRモードの「IV」です。チェーンの IV とは異なります。これは、カウントを開始する位置への数値オフセットです。
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_.28CTR.29を参照してください- IV は「ノンス」(カウンターの上位ビット) です。
あなたが提案するのは、IVが次のブロックをマングルするために使用され、次に次のブロックをマングルするために使用されるCBCモードなどに基づいているようです。しかし、それは CTR モードでの IV の使用方法とはまったく関係ありません。
あなたの修正は使用される番号の開始点を変更せず、メッセージは絶望的に安全ではありません. これをしないでください。
また、この種のことを本当に尋ねるべきであるstackoverflowに相当する暗号があります。 https://crypto.stackexchange.com/
ちょっと待って。今、私はこれについて考えています...私は問題のAPIを知りません。IV が単に使用されていない可能性があります (API の IV は、CBC で行われる連鎖の種類にのみ使用される可能性があります)。カウンターの広さは？API は、ランダムなオフセットでカウンターを開始することを期待している可能性がありますか? そうではないと思いますが、確かにドキュメント/コードを読む必要があります（PyCryptoでこの問題に噛まれたことは知っています）。
しかし、とにかく、いずれにせよ、あなたの修正は確かに修正ではありません (残念ながら)。