私はライブラリ 1 の Aes アルゴリズムの実装を使用しています。現在、ライブラリ 2 の別の実装に変更したいと考えています。問題は、ライブラリ 1 から diff 暗号化されたデータを提供していることです。ECB モード 128 ビットでの Aes 実装は可能ですか?同じ鍵とプレーンテキストですが、2 つの異なる実装の暗号文 (暗号化されたデータ) のみが異なりますか?
もう1つ見つけたのは、16バイト未満の入力バイトを渡すと、両方のライブラリの暗号化されたデータが一致することですが、ライブラリ1では復号化は完璧ですが、ライブラリ2では暗号化と復号化が同じであることを示しています(正確に復号化していません)元のテキストに）何が問題になるでしょうか？
16バイト未満の文字列が同じ出力につながるというコメントを考えると、ECBの使用（決して使用しないでください）とともに、ライブラリの1つが実際にはECBを使用しておらず、代わりにデフォルトでCBC（これはの方がはるかに優れたデフォルトです)、NULL IV を CBC に渡していることを確認してください。私の理論が正しければ、最初の 16 バイトは常に同じであり、その時点から違いが始まると考えるべきです。
これに対する最善の解決策は、すべてのコードを ECB (いくつかの非常にまれな状況を除いて深刻に壊れている) から CBC または見つけられる他のモードに変換することです。CBC が最も一般的で、ランダムに生成された IV を渡す必要があります。
モードの切り替えが不可能な場合は、2 番目のライブラリを調査し、ECB モードに設定する方法を決定します。ECB モードはおそらく現在ではありません。暗号化に依存している人は誰でも、ECB モードを使用するとプレーンテキストに関する重要な情報が漏洩することを警告する必要があります。ほとんど暗号化されていない場合もあります。ウィキペディアのエントリを参照して、それが実際にどれほど悪いかを示す素晴らしい視覚的な例を確認してください。これは理論的な攻撃ではありません。本当に、本当に壊れています。
はい、コメントが指摘しているように、可能です。Crypto は、入力の小さな変化に対して出力の大きな変化を示すように設計されています。理想的には、入力の 1 ビットの変更により、出力のビットの 50% が変更されます。
ほとんどの問題を回避する方法は、すべてを明示的に指定することです。2 つのライブラリ間でデフォルトが異なる場合、出力が異なるため、デフォルトに依存しないでください。
文字エンコーディングを明示的に指定して、文字をバイトに変換します。UTF-8 が一般的です。
使用している暗号化モードを明示的に指定します。認証を含めたくない場合は CBC または CTR モード、含める場合は GCM。
できれば文字ではなくバイトを使用して、IV を明示的に指定します。
使用するパディングを明示的に指定します。PKCS7 (別名 PKCS5) は非常に一般的です。
それでも問題が解決しない場合は、両方のライブラリですべてがバイトごとに同じであることを確認してください。文字ではなくバイトをチェックします。つまり、バイト配列に変換した後、暗号化メソッドに渡す直前にチェックします。
補足として、ECB モードは安全ではなく、情報が漏洩します。これは、暗号メソッドの動作をテストする場合にのみ役立ちます。上で提案したように、CBC、CTR、または GCM モードを使用します。これらのモードは安全であり、GCM には認証が含まれています。
ここにはすでにたくさんの正解があります。私が言及したい唯一のことは、これまで言及されていませんでした。
ECBモード128ビットで同じキーとプレーンテキストを使用したAes実装は可能ですが、2つの異なる実装では暗号文(暗号化されたデータ)のみが異なりますか?
この場合、アルゴリズムが正しく実装されていれば、同じ入力 (プレーン テキスト、モード、IV、パディング)から同じ出力 (暗号テキスト) が生成されるはずです。
その場合、確立された 2 つのライブラリを使用している場合は、前述のいずれかの問題 (入力の 1 つ、エンコーディングの違いなど) が原因である可能性が高くなります。