現在、データの暗号化にCBCモードのAES（256）を使用しています。初期化ベクトルを暗号化されたデータとともに保存します。今、私は暗号化されたデータの最初にIVを追加し、次に復号化して、ハードコードされたバイト長として読み込みています。
将来、初期化ベクトルの長さが変更された場合、このメソッドは機能しなくなります。
だから私の質問は：
将来、AESキーサイズが長くなる= IVが長くなるでしょうか？つまり、AESのブロックサイズは将来変更されますか？
もしそうなら、これに対処するための最良の方法は何でしょうか？IVの長さの指標として最初のバイトを使用し、次にそのバイト数を読み取りますか？
Rijndaelはより大きなブロックサイズをサポートしますが、AESは現在128ビットブロックに固定されています。より大きなRijndaelブロックサイズがNISTによって標準化される可能性は比較的低いようです。これは、事実上、誰も実装していない完全に新しいアルゴリズムになるためです。NISTがより大きなサイズのブロック暗号の必要性を感じた場合、それは単に新しいコンテストを実行するでしょう。
ただし、IVの長さではなく、メッセージの先頭近くに何らかのアルゴリズム識別子を含めることをお勧めします（必要なのは1バイトだけです）。これにより、より大きな処理を柔軟に処理できるだけでなく、 IVだけでなく、将来的には他の方法、たとえば新しいアルゴリズムでフォーマットを拡張することもできます。例：0 == AES-256 / CBC、1 == AES-256 / GCM、2 = AES-2.0 / CBC、3 = AES-256 / CBC、どこかに特別な追加ヘッダーがあるなど。
PS-メッセージ認証コードも使用することを忘れないでください。そうしないと、さまざまな簡単なメッセージ変更攻撃にさらされることになります。
初期化ベクトルの目的は、最初のブロックをランダム化して、同じキーで 2 回暗号化された同じデータが同じ出力を生成しないようにすることです。
情報理論の観点からは、AES には 2^128 個の個別の IV しかありません。これは、実際のデータの最初のブロックと XOR する可能性のあるすべてのランダムな値であるためです。したがって、IV を暗号のブロック サイズよりも大きくする理由はありません。
より大きなブロック サイズは、より大きな IV を正当化する可能性があります。より大きな鍵サイズはそうではありません。
より大きなブロックサイズは、定義上、異なるアルゴリズムを意味します。したがって、使用しているアルゴリズムを示すためにデータにタグを付けると、使用するブロック サイズ (したがって IV サイズ) がわかります。
別の解決策として、AES-CTR モードに切り替えることができます。カウンター モードにはナンスが必要ですが、ナンスは AES ブロック サイズに関連付ける必要はありません。AES ブロック サイズが増加した場合 (ジャックが言うように、ありそうもないことですが)、同じサイズのノンスを保持できます。