UDP を介して時間に敏感な通信を行うアプリケーションがあります (ビデオ ストリーミングやゲームなど)。パケットは失われる可能性があり、再送信する必要はありません。
データグラムの暗号化にはどの暗号を使用すればよいですか?
ECBモードでフグに傾いています。ECB モードに問題があることはわかっていますが、失われたパケットをサポートする必要があるため、暗号化は以前のブロックに依存できません。ECB モードの問題を軽減し、パケットの欠落を許容するために使用できる、より優れた暗号またはモードはありますか?
(すべて純粋な Java のままにしたいので、DTLS は使用できません。)
カウンター モード (CTR) の AES は実行可能なオプションです。接続を確立するとき、送信プログラムと受信プログラムの両方が認識しているランダムに選択された値でカウンターを開始します。ビデオ データの各パケットに 1 つの接続内で繰り返されないほど長いシーケンス番号 ( n ) が含まれている場合、受信プログラムはそれを初期カウンター値に追加して、そのパケットの暗号化に使用されるカウンターの値を取得できます。
もちろん、1 ブロックより長いメッセージの場合は、パケット内でカウンタを複数回インクリメントする必要があります。最長の送信パケットが何ブロックの長さになるか (たとえば 16 ブロック) を判断16*nし、パケットの最初のブロック16*n+1、2 番目のブロックなどにカウンター値を使用します。
CBC モードを使用できます。必要なのは、各パケットを個別の CBC ストリームとして暗号化することだけです。つまり、パケットごとに CBC を再起動し、新しい IV を使用します。
ところで、Blowfish は 64 ビット (ブロック サイズ) のブロック暗号であり、最近では本質的にセキュリティ マージンがかなり低くなります。
ECB は、暗号化された各ブロックが他のすべてのブロックから完全に独立しているため、攻撃に対してオープンです。これにより、2 つ (またはそれ以上) の暗号ブロックが同一であることを認識して暗号文の内容を推測し、再配置することでメッセージを検出できないように変更することが可能になります。暗号ブロックを使用するか、同じ鍵を使用して暗号化された他のメッセージの暗号ブロックを置き換える (これ自体は良い考えではありません)。
UDP パケットに何らかのシーケンス情報が含まれている場合は、それを CTR モードのカウンターとして使用するか、XEX (または XTS) モードを使用できます。XEX は、ハード ドライブなどの暗号化されたランダム アクセス デバイスの場合のように、ブロックのランダムな順序でデータの暗号化を実行する必要がある暗号化の状況向けに開発されたもので、お客様のような状況に最適です。