アルゴリズムがプレーン テキストを文字のバイト値として状態マトリックスにどのように管理するかは明らかです。
しかし、バイナリ ファイルの AES 暗号化についてはどうでしょうか。
状態が4x4 バイトに標準化されている限り、アルゴリズムは 16 バイトを超えるファイルをどのように管理しますか?
アルゴリズムがプレーン テキストを文字のバイト値として状態マトリックスにどのように管理するかは明らかです。
しかし、バイナリ ファイルの AES 暗号化についてはどうでしょうか。
状態が4x4 バイトに標準化されている限り、アルゴリズムは 16 バイトを超えるファイルをどのように管理しますか?
AES プリミティブは、任意のバイナリ ストリームの暗号化/復号化を可能にする構造の基礎です。
AES-128 は、128 ビットの鍵と 128 ビットのデータ ブロックを取り、このブロックを「暗号化」または「復号化」します。128 ビットは 16 バイトです。これらの 16 バイトは、テキスト (ASCII、1 バイトあたり 1 文字など) またはバイナリ データにすることができます。
単純な実装では、16 バイトを超えるファイルを 16 バイトのグループに分割し、それぞれを同じキーで暗号化します。ファイルを 16 バイトの倍数にするために、ファイルを「パディング」する必要がある場合もあります。問題は、同じブロックを同じ鍵で暗号化するたびに同じ暗号文が得られるため、ファイルに関する情報が公開されることです。
16 バイトを超えるデータを安全に暗号化/復号化するために AES 機能を構築するには、さまざまな方法があります。たとえば、CBCを使用したり、カウンター モードを使用したりできます。
カウンターモードの方が説明しやすいので見てみましょう。ブロック b を鍵 k で暗号化した場合AES_e(k, b)
、同じ鍵を再利用して同じブロックを複数回暗号化することは望ましくありません。したがって、使用する構造は次のようなものAES_e(k, 0)
ですAES_e(k, 1)
。AES_e(k, n)
これで、任意の入力を取り、それを 16 バイトのブロックに分割し、このシーケンスで XOR することができます。攻撃者はキーを認識していないため、このシーケンスを再生成して (長い) メッセージをデコードすることはできません。XOR は、上記で生成されたブロックと平文の間にビットごとに適用されます。受信側は同じシーケンスを生成し、暗号文と XOR して平文を取得できるようになりました。
アプリケーションでは、これをある種の認証メカニズムと組み合わせて、AES-GCM や AES-CCM のようなものにすることもできます。
17 バイトのプレーン テキストがあるとします。状態マトリックスは最初の 16 バイトで埋められ、1 つのブロックが暗号化されます。次のブロックは残った 1 バイトになり、AES が必要とする 16 バイトを満たすために状態マトリックスにデータが埋め込まれます。
AESは常にバイト単位を考慮するため、バイト/バイナリファイルでうまく機能します.それがASCIIチャンクであるか、他の考えであるかは関係ありません. コンピューター内のすべてがバイナリ/バイト/ビットであることを覚えておいてください。データがストリーム データ (バイト単位の情報のチャンク) になると、正常に動作します。