AES/GCMはブロックサイズより小さいデータをどう扱うのですか？

Question

私はbouncy castle libraryをC＃で暗号化と復号化に使用していますが、ブロックサイズよりも小さいプレーンテキストを扱う方法は不思議でした。ここ

は、私がこれまでにやっていることです：プレーンデータは、ブロック・サイズ、その後小さいとき

AesFastEngine engine = new AesFastEngine(); 
GcmBlockCipher cipher = new GcmBlockCipher(engine); 
AeadParameters param = new AeadParameters(new KeyParameters(key), 128, iv, null); 
cipher.Init(true, parameters); 

byte[] encData = new byte[plain.Length]; 
cipher.ProcessBytes(plain, 0, plain.Length, encData, 0); 

それは何もしません。

Answer 1

残念ながら、Bouncy CastleとOracle/Javaの実装は、ではありません。つまり、基礎となるCTRモードの暗号化のオンラインプロパティは保持されません。この文脈でオンラインとは、バイトが直接に暗号化/復号化されることを意味します。これは、暗号化の処理方法と認証タグの処理方法と関係があります。

AES-CTRは、複数の方法で実装できます。最初にカウンタを暗号化し、平文/暗号文が到着したらそれを直接XORすることができます。また、最初に平文をバッファリングしてから、一度完全なブロックを作成したら、カウンタを作成し、それを暗号化して、平文の完全ブロックをXORします。これは、CBCのような他の操作モードにもっと似ているという意味で利点がありました。さらに、その間ずっとキーストリームをメモリにバッファリングする必要はありません。

認証タグは、別の方法で処理することもできます。基本的に3つのオプションがあります。認証タグを暗号文とは別のエンティティと見なすことができます。これにより、CTRモードのオンラインプロパティを維持することができ、私の意見では、優先オプションにする必要があります。あなたは暗号文の一部としてそれを見ることもできますが、その場合、解読中にオンラインプロパティーが失われます;認証タグを構成する最後のバイト数を処理できるようになる前に、暗号文の終わりを知る必要があります。したがって、少なくとも認証タグのバイト数でバッファリングする必要があります。最後に、解読中に平文バイトの確認の後に、平文バイトのを返すだけで済みます。その場合は、暗号文全体をバッファリングし、平文を一度に返す必要があります。

認証タグの問題は復号化のためだけであるため、BouncyはCTRの実装方法のためにバッファリングする可能性があります。ロバートがすでにコメントの中で言及したようにdoFinalに電話をかけて、認証タグと同様に暗号文の最後のブロックを取得する必要があります。暗号化ルーチンが復号化ルーチンと幾分対称的に保たれるので、暗号化がまだ実行されていないこともあり得る。