私はアプリケーションサーバーを作成していますが、AES128/CTR/NoPadding を使用して接続を保護することにしました。これは、バイトをブロック境界に拡張する必要なく十分に安全であると考えられており、TCP に適していると考えたからです。論理的にシームレスなストリームです。
問題は、CTR が基本的にストリーム暗号をシミュレートしているにもかかわらず、CTR がブロック暗号に基づいているため、Cipher.update() が完全な 16 バイトのブロックになるまで暗号化されたブロックを返さないことです。tcp ソケットからデータを読み取り、メッセージが到着したらすぐに処理する必要がありますが、最新のブロックはまだ構築中であり、サイズが 16 バイト未満であるため、取得できません。そして、次のメッセージがいつ送信されるかわからないので、ただ待つことはできません。もちろん、Cipher.doFinal() を呼び出して残りを取得することもできますが、それはストリーム (接続) の終わりを意味し、Cipher オブジェクトが再初期化されます。
キャリーオーバーを覗く方法があればいいなと思いました。CTR はプレーン テキストとキーストリームを XOR するだけなので、ブロック内の残りのバイトに関係なく、暗号化されたデータを取得できるはずです。この問題に対する適切な回避策はありますか? 偽のプレーンテキストをゼロで暗号化してキーストリームを事前に取得し、XOR を手動で行うラッパーを作成することを考えていますが、他の人がこの問題をどのように解決したのだろうか。
アップデート
私は Android アプリケーションを開発していますが、これは Dalvik VM の問題であることが判明しました。Robert と monnand が以下で指摘したように、Java SE には、少なくともデフォルトのプロバイダーではこの問題はありません。この問題を回避するには、ラッパー クラスを作成するか、モードを CFB8 に変更する必要があると思います。(CTR8 は機能しませんでした) すべての応答に感謝します!