「ストリーム」で動作する XXTEA 暗号化アルゴリズムの実装を書いています。つまり、crypt mykey < myfile > 出力のように使用できます。
必要条件の 1 つは、ファイルにまったくアクセスできないことです (EOF が見つかるまで、固定サイズのブロックのみを読み取ります)。アルゴリズムでは、データ バイトが 4 の倍数である必要があるため、パディングを追加する必要があります。
プレーン テキストの場合、適切な解決策は NULL をパディングし、復号化では NULL を無視することですが、バイナリ ストリーム (埋め込まれた NULL を含む可能性がある) には同じ戦略を使用できません。
欠落している文字の数をパディングする（3文字が欠落している場合は、最後に3、3、3を追加する）などの一般的な解決策を読みましたが、もっとエレガントな解決策はありますか？
読む: http://msdn.microsoft.com/en-us/library/system.security.cryptography.paddingmode.aspx
次のような一般的なパディング方法のリストがあります。
PKCS7 - PKCS #7 パディング文字列は一連のバイトで構成され、各バイトは追加されたパディング バイトの総数に等しくなります。
ANSIX923 パディング文字列は、長さの前にゼロで埋められた一連のバイトで構成されます。
ISO10126 パディング文字列は、長さの前にランダム データで構成されます。
例:
生データ: 01 01 01 01 01
PKCS #7: 01 01 01 01 01 03 03 03
ANSIX923 01 01 01 01 01 00 00 03
ISO10126: 01 01 01 01 01 CD A9 03
質問を読むと、これのセキュリティ面は議論の余地があるようです。簡単に言えば、入力として 4 バイトの倍数を期待する API がありますが、これは常にあるとは限りません。
バイナリ ストリームが気にしないことを保証できない場合、任意のバイナリ ストリームに最大 3 バイトを追加することは危険です。exeファイルには残りのすべてのビットの関連サイズを指定するヘッダーがあるため、exeファイルの末尾に0を追加しても問題ありません。pcx ファイルには、ファイルの末尾から特定のバイト数を開始するヘッダーがあるため、pcx ファイルの末尾に 0 を追加するとファイルが破損します。
したがって、本当に選択の余地はありません - バイナリ ストリームの最後に自然に発生しないことが保証されている、使用できる魔法のパディング バイトの選択肢はありません。
実際、優れたストリーム暗号にはパディングがまったく必要ないと思います。たとえば、RC4 はパディングを必要とせず、非常に強力なストリーム暗号です。ただし、攻撃者が選択した異なるデータを暗号化ルーチンに供給でき、常に同じキーを使用し、暗号化されたデータにもアクセスできる場合、攻撃を受ける可能性があります。適切な入力データを選択し、出力データを分析することで、ブルート フォース攻撃なしで暗号化キーを復元できます。それ以外は、RC4 は非常に安全です。
パディングが必要な場合は、ストリーム暗号の IMHO ではありません。4 バイトの倍数または 16 バイトの倍数になるようにパディングする場合、大きな違いは何ですか? また、16 バイトの倍数になるようにパディングされている場合は、ほぼすべてのブロック暗号を使用できます。実際、あなたの暗号はブロック暗号であり、4 バイト ブロックで動作します。これは、すべての「シンボル」が 4 バイトであるシステム上のストリーム暗号でした (たとえば、暗号化 UTF-32 テキストの場合、データは常に確実に 4 の倍数になるため、パディングはありません)。