.Net対称暗号化System.Security.Cryptographyを使用して、ストレージオーバーヘッドをあまり追加せずに、テキストの多くの小さなブロックを暗号化しようとしています（処理時間は重要ではなく、サイズだけです）。明らかな方法は、それらをすべてまとめて、結果を1つの大きなブロックとして暗号化することですが、私の場合は機能しません。
背景には、誰かが.docxワード文書を送ってくれるツールを開発しているので、内容を知らなくても構造の問題をトラブルシューティングできます。これを行うには、各要素を対称的に暗号化し<w:t>ます（単語の一部から段落全体まで、何でもかまいません）。
そのようなテキスト要素を移動および/または削除できるようにしたいのですが、ユーザーはドキュメントを返送するときにドキュメントを復号化できるようにしたいので、各要素を個別に暗号化する以外に選択肢はないようですが、AESを使用しますそれぞれ数バイトのブロックが数千ある場合、ストレージのオーバーヘッドは膨大になります。
読みたくない情報を暗号化するのに最適なのは、そもそも情報が存在しないことです。
ドキュメントの構造だけが気になる場合は、転送から完全に外して、プレースホルダーと交換してみませんか？
クライアント側で、削除されたすべてのコンテンツをプレースホルダーに関連付けたデータストアを作成します（例：{1}、{2}、{3} ...など）
構造とプレースホルダー（つまり、<w:t>{1}</w:t>）を自分に送信します
構造を修正します。
固定された構造をクライアント側に戻し、クライアント側でプレースホルダーを元のコンテンツに置き換えてドキュメントを元に戻します。
そうすれば、賢明な情報を送信することはありません（クライアント側に残り、ドキュメント自体の構造を除いて情報が危険にさらされることはありません）。さらに、ほとんどのコンテンツがそこにないため、転送されるファイルサイズは小さくなります。
さらに良いことに、クライアントにファイルを送信する前にファイルを表示させて、すべての機密情報が実際に削除されたことをクライアントが確認できるようにすることができます。
ここに簡単な解決策はありません。基本的に、アプリケーション全体を設計するように依頼されています。ブロック暗号のストリーミングモードであるCTRモード暗号化を使用できます。ストリーミングモードでは、プレーンテキストバイトと同じ数の暗号化バイトのみが必要です。
とはいえ、ストリーミングモードでは、ある種のナンスを保存する必要があります。このナンスは、暗号文を保護するために存在する必要があります。ただし、ナンスはコンテキストから計算できる場合があります。たとえば、ファイル名のハッシュでうまくいくはずです。ただし、これはドキュメント内の要素にとっては難しい場合があります。
データをバイトに変換して元に戻す（アルファベットを決定し、アルファベットをエンコードする）スキームを考案する必要があることに注意してください。このスキームが効率的でない場合、大きなオーバーヘッドが発生する可能性があります。
ブロックサイズが128ビットのAESは、暗号化されたフラグメントごとに平均8バイトのオーバーヘッドを引き起こします-私の意見では悪くありません。すべてのフラグメントを連結し、それらを1つの大きなブロックとして暗号化し、最後に分割して、すべてのフラグメントを再び配置することができます。これは、何らかの対策を考え出さない限り、移動してフラグメントを削除し始めるまで機能します。
たとえば、すべての暗号化されたフラグメントに連結ブロック内の位置のプレフィックスを付け、AESの代わりにRC4のようなストリーム暗号を使用できます-これにより、暗号化されたフラグメントを元の順序に戻し、任意のパディング値で削除された要素からのギャップを埋めて復号化できます正しく。
これによりオーバーヘッドが少し低下する可能性がありますが、おそらく4バイトが必要です。XMLに生のバイナリデータが必要ないため、暗号テキストを16進文字列またはBase64文字列としてエンコードする必要もあります。ただし、このエンコーディングでは、AESを使用した場合のパディングよりもはるかに大きなオーバーヘッドが発生するため、最も単純なソリューションを使用することもできます。
最終的な考え-AESのようなブロック暗号を使用する場合、同じキーで複数のフラグメントを暗号化するときは注意する必要があります。これは、平文が等しいと暗号テキストが等しくなる可能性があるためです。詳細については、ブロック暗号動作モードを参照してください。