私は C でサーバーを作成しており、ファイルを aes でエンコードしたいと考えています。
エンコード ブロックのサイズは AES キーの長さと等しくなければならないことがわかっているため、最後のブロックを必要なサイズにゼロで補う必要があります。問題はデコードにあります。ファイルの内容と補完するゼロをどのように区別するのですか? まぁ、そのためにBase64エンコーディングを使おうと思ったんですけど、大容量ファイルだと遅くないですか？エンコードされたブロックを送信する前に、ファイル サイズを送信する必要がありますか?
一般的なスキームは PKCS#5 パディングです。基本的に、(平文の) パディングをパディング長と同じバイトで埋めます。次に、復号化した後、最後のバイトを見て、削除するバイト数を確認します。ドロップされたバイトが同じであることを確認すると、迅速なサニティ チェックが提供されます。16 進数でのいくつかの例:
[AABBCCDD EEFF0011 22334455 667788--] -> [AABBCCDD EEFF0011 22334455 66778801]
[AABBCCDD EEFF0011 22334455 66------] -> [AABBCCDD EEFF0011 22334455 66030303]
[AABBCCDD EEFF0011 22334455 66778899] -> [AABBCCDD EEFF0011 22334455 66778899][10101010 10101010 10101010 10101010]
//the last byte must be padding, even if that requires an extra block
補足: 自分で暗号化を実装している場合は、操作モードについても読んでください。そうでない場合は、使用しているライブラリがパディングを処理できるはずです。
ファイルを Base64 でエンコードしてから AES 暗号化することはお勧めできません。そうすることで、暗号文の各バイトの上位 2 ビットを既知の値に設定することで、可能なブロックの数を 2^64 から 2^48 に減らします。
それが「最善の」方法か「通常の」方法かはわかりませんが、通常、ファイルに関するメタデータに復号化する暗号文の最初または最後に、いくつかの余分なブロックを平手打ちしました-サイズ、ファイル名、コンテンツタイプなど。はい、これらのブロックにはエントロピーがほとんどありませんが、すべてのバイトにエントロピーを含めるよりも、1 つまたは 2 つのブロックにクリブを許可する方がはるかに優れています。
たとえば、10 バイトの長さのファイルがある場合、暗号文の 1 つの完全なブロック、つまり 2 つの有効なバイトとそれに続く 6 バイトのパディングを含むブロックができます。最後のブロックにはメタデータが含まれます。(実際には、メタデータ ブロックは最初または最後に配置できます。選択してください。)
パディングスキームについては、このページを参照してください。
http://en.wikipedia.org/wiki/Padding_(暗号化)
たとえば、CBC モードの場合:
1 つの方法は、最後のブロックを 1 ビットの後に 0 ビットで埋めることです。入力がたまたまブロック全体を埋める場合、パディングに対応するために「ダミー ブロック」が追加されます。そうしないと、入力平文の末尾がパディングとして誤って解釈される可能性があります。もう 1 つの方法は、値 (n-1) を持つ n バイトを平文の末尾に追加して、完全なブロックを埋めることです。メッセージがすでにブロックを正確に埋めている場合は、前と同じ理由で、パディング ブロックの完全なブロックが追加されます。これは、パディングが 1 バイトの 0、または 2 バイトの 1 などのいずれかであることを意味します。
CTR モードを使用する場合、暗号化テキストはプレーン テキストと同じサイズであるため、パディングは必要ありません。
@maybewecouldstealavan が指摘したように、人気のあるパディング スキームは RSA Laboratories の PKCS #5 です。これは、OpenSSL プログラムが CBC モードで使用するパディング スキームです。
すべてのブロック暗号は通常、標準ブロック パディングとも呼ばれる PKCS#5 パディングを使用します。これにより、基本的な整合性またはパスワード チェックを実行できます。