AES-GCM-SIV
IETF CFRG RFC 8452 AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption table:比較?
POLYVAL は GHASH をbyte逆順にして少々足したもの
並び順がリトルエンディアンCPU向きっぽい
RFC 8452 適当訳
AES-GCM-SIV: ノンス不正使用耐性認証暗号化
概要
このメモは、ノンスの誤用に対する耐性を備えた、つまりノンスが重複しても致命的な失敗を起こさない2つの認証付き暗号化アルゴリズムを規定しています。
この文書は、Crypto Forum Research Group の成果物です。
このメモのステータス
この文書はインターネット標準化過程の仕様ではなく、情報提供を目的として公開されています。
この文書は、インターネット研究タスクフォース (IRTF) の成果物です。IRTF は、インターネット関連の研究開発活動の成果を公開しています。これらの成果は、必ずしも実用化に適さない可能性があります。この RFC は、インターネット研究タスクフォース (IRTF) の Crypto Forum Research Group の合意に基づくものです。IRSG によって公開が承認された文書は、いかなるレベルのインターネット標準の候補にもなりません。RFC 7841 のセクション 2 を参照してください。
著作権表示
Copyright (c) 2019 IETF Trustおよび本文書の著者。All rights reserved.
(略)
1. はじめに
追加データ付き認証暗号化（AEAD）RFC5116の概念は、機密性と整合性を単一の操作で実現し、ブロック暗号とハッシュプリミティブのアドホックな構築という従来の一般的な手法に伴うリスクを回避します。最も人気のあるAEADであるAES-GCM GCMは、その優れた性能により広く利用されています。 しかしながら、一部のAEAD（AES-GCMを含む）では、2つの異なるメッセージを同じ鍵とノンスで暗号化すると、機密性または整合性、あるいはその両方が壊滅的に損なわれます。AEADの要件では、鍵とnonceの組み合わせは1度しか使用できないと規定されているため、このような使用は禁止されていますが、実際には懸念事項となります。
nonceの誤用耐性を備えたAEADは、この問題の影響を受けません。この種のAEADでは、2つのメッセージを同じnonceで暗号化しても、メッセージが同一かどうかしか明らかになりません。これは、この状況において決定論的アルゴリズムが漏洩する可能性のある最小限の情報量です。
このメモでは、nonceの誤用に対する耐性を持つ2つのAEAD（AEAD_AES_128_GCM_SIVとAEAD_AES_256_GCM_SIV）を指定します。これらのAEADは、AES-GCMの既存のハードウェアサポートを活用できるように設計されており、AES-GCMの速度の5%以内で復号できます（マルチキロバイトのメッセージの場合）。暗号化は、nonceの誤用に対する耐性を実現するために2回のパスが必要となるため、必然的にAES-GCMよりも遅くなります。しかし、測定結果によると、それでもAES-GCMの3分の2の速度で実行できることが示されています。
nonceの一意性が保証できない状況では、これらのAEADを検討することをお勧めします。これには、状態を持つカウンタがない場合や、複数の暗号化者が同じ鍵を使用する場合など、状態が保証されない場合が含まれます。セクション9で説明したように、この方式はランダムに選択されたnonceと組み合わせて使用することが推奨されます。
この文書は、Crypto Forum Research Group (CFRG) のコンセンサスを反映したものです。
2. 要件言語
本文書におけるキーワード「MUST（しなければならない）」「MUST NOT（してはならない）」「REQUIRED（必須）」「SHALL（するべき）」「SHALL NOT（すべきでない）」「SHOULD（すべきでない）」「SHOULD NOT（すべきでない）」「RECOMMENDED（推奨される）」「NOT RECOMMENDED（推奨されない）」「MAY（してもよい）」「OPTIONAL（任意）」は、ここで示すようにすべて大文字で表記されている場合に限り、BCP 14 RFC2119 RFC8174 の規定に従って解釈されます。 3.
既約多項式 x^128 + x^127 + x^126 + x^121 + 1 は GMACと同じものかな
dot( a, b ) = a * b * x^-128
x^-128 は x^127 + x^124 + x^121 + x^114 + 1 と等しい
最初のバイトの最下位ビットを x^0の係数
|76543210|FEDCBA98|.... の順
3. POLYVAL
GCM-SIVの構成はGCMに似ています。ブロック暗号はカウンタモードで平文を暗号化し、多項式認証子は整合性の確保に使用されます。GCM-SIVの認証子はPOLYVALと呼ばれます。 POLYVALは、GHASH（AES-GCMの認証子。GCM、セクション6.4を参照）と同様に、サイズ2^128の2進体で動作します。この体は、既約多項式x^128 + x^127 + x^126 + x^121 + 1で定義されます。体中の任意の2つの要素の和は、それらの排他的論理和です。任意の2つの要素の積は、標準的な（2進）多項式の乗算と、その既約多項式を法とする縮約によって計算されます。 体の元に対する別の二項演算 dot(a, b) を定義します。ここで dot(a, b) = a * b * x^-128 です。体の元 x^-128 の値は、x^127 + x^124 + x^121 + x^114 + 1 に等しくなります。この乗算の結果 dot(a, b) は、別の体の元です。
この体の多項式は、最初のバイトの最下位ビットを x^0 の係数、最初のバイトの最上位ビットを x^7 の係数とし、最後のバイトの最上位ビットが x^127 の係数になるまで、128 ビット文字列との間で変換されます。
POLYVAL は、体の元 H と、体の元の系列 X_1, ..., X_s を受け取ります。結果は S_s です。ここで S は、反復 S_0 = 0 によって定義されます。 S_j = dot(S_{j-1} + X_j, H)、j = 1..s の場合。
POLYVAL(H, X_1, X_2, ...) は ByteReverse(GHASH(ByteReverse(H) * x, ByteReverse(X_1), ByteReverse(X_2), ...)) と等しいことに注意してください。ここで、ByteReverse は16バイトの順序を反転する関数です。詳細な説明は付録 A を参照してください。
4. 暗号化
AES-GCM-SIV暗号化は、16バイトまたは32バイトの鍵生成鍵、96ビットのノンス、そして平文と可変長の追加データバイト列を使用します。出力は、平文より16バイト長い認証済み暗号文となります。暗号化と復号は、入力が整数バイトの場合のみ定義されます。
鍵生成鍵が16バイトの場合、AES-128が全体に使用されます。それ以外の場合は、AES-256が全体に使用されます。
暗号化の最初のステップは、ノンスごとの鍵、メッセージ認証鍵、およびメッセージ暗号化鍵を生成することです。メッセージ認証鍵は128ビット、メッセージ暗号化鍵は128ビット（AES-128の場合）または256ビット（AES-256の場合）です。
これらの鍵は、32ビットのリトルエンディアンカウンタとノンスを含む一連の平文ブロックを暗号化し、得られた暗号文の後半部分を破棄することで生成されます。AES-128の場合、128 + 128 = 256ビットの鍵素材を生成する必要があり、各ブロックを暗号化すると、半分を破棄した後に64ビットになるため、4つのブロックを暗号化する必要があります。これらのブロックのカウンタ値は0、1、2、3です。AES-256の場合は、カウンタ値が0から5（両端を含む）までのブロックが合計6つ必要です。
擬似コード形式では、「++」は連結、「x[:8]」はxの最初の8バイトのみを取得することを示します。
code:func
func derive_keys(key_generating_key, nonce) {
message_authentication_key =
AES(key = key_generating_key,
block = little_endian_uint32(0) ++ nonce):8 ++ AES(key = key_generating_key,
block = little_endian_uint32(1) ++ nonce):8 message_encryption_key =
AES(key = key_generating_key,
block = little_endian_uint32(2) ++ nonce):8 ++ AES(key = key_generating_key,
block = little_endian_uint32(3) ++ nonce):8 if bytelen(key_generating_key) == 32 {
message_encryption_key ++=
AES(key = key_generating_key,
block = little_endian_uint32(4) ++ nonce):8 ++ AES(key = key_generating_key,
block = little_endian_uint32(5) ++ nonce):8 }
return message_authentication_key, message_encryption_key
}
「長さブロック」を、64ビットのリトルエンディアンエンコードである bytelen(additional_data) * 8 と bytelen(plaintext) * 8 を連結した16バイトの値として定義します。平文と追加データは、それぞれがAESブロックサイズである16バイトの倍数になるまでゼロで埋めます。そして、X_1、X_2、…（POLYVALへの入力となるフィールド要素の列）は、パディングされた追加データ、パディングされた平文、および長さブロックの連結となります。
S_s = POLYVAL(メッセージ認証鍵、X_1、X_2、…) を計算します。S_s の最初の12バイトとノンスをXORし、最後のバイトの最上位ビットをクリアします。結果をメッセージ暗号化鍵を用いてAESで暗号化し、タグを生成します。
（ここでAES-GCMとの違いを強調しておきます。AES-GCMはエンコードされた追加データと暗号文を認証しますが、AES-GCM-SIVはエンコードされた追加データと平文を認証します。）
暗号化された平文は、パディングされていない平文に対して、メッセージ暗号化鍵を用いてカウンターモード（SP800-38A、セクション6.5を参照）でAESを用いて生成されます。最初のカウンタブロックは、最後のバイトの最上位ビットが1に設定されたタグです。カウンタは、最初の32ビットを符号なしリトルエンディアン整数として解釈し、2^32で折り返しながらインクリメントすることで進みます。暗号化の結果は、暗号化された平文（平文の長さに切り捨てられたもの）と、それに続くタグです。 擬似コード形式では、暗号化プロセスは次のように表現できます。
code:func
func right_pad_to_multiple_of_16_bytes(input) {
while (bytelen(input) % 16 != 0) {
input = input ++ "\x00"
}
return input
}
func AES_CTR(key, initial_counter_block, in) {
block = initial_counter_block
output = ""
while bytelen(in) > 0 {
keystream_block = AES(key = key, block = block)
block0:4 = little_endian_uint32( read_little_endian_uint32(block0:4) + 1) todo = min(bytelen(in), bytelen(keystream_block)
for j = 0; j < todo; j++ {
output = output ++ (keystream_blockj ^ inj) }
}
return output
}
func encrypt(key_generating_key,
nonce,
plaintext,
additional_data) {
if bytelen(plaintext) > 2^36 {
fail()
}
if bytelen(additional_data) > 2^36 {
fail()
}
message_encryption_key, message_authentication_key =
derive_keys(key_generating_key, nonce)
length_block =
little_endian_uint64(bytelen(additional_data) * 8) ++
little_endian_uint64(bytelen(plaintext) * 8)
padded_plaintext = right_pad_to_multiple_of_16_bytes(plaintext)
padded_ad = right_pad_to_multiple_of_16_bytes(additional_data)
S_s = POLYVAL(key = message_authentication_key,
input = padded_ad ++ padded_plaintext ++
length_block)
for i = 0; i < 12; i++ {
}
tag = AES(key = message_encryption_key, block = S_s)
counter_block = tag
return AES_CTR(key = message_encryption_key,
initial_counter_block = counter_block,
in = plaintext) ++
tag
}
5. 復号
復号には、16バイトまたは32バイトの鍵生成鍵、96ビットのノンス、暗号文、および可変長の追加データバイト文字列が必要です。復号は失敗するか、暗号文より16バイト短い平文を出力します。
AES-GCM-SIV暗号文を復号するには、まず暗号化時と同じ方法でメッセージ暗号化鍵とメッセージ認証鍵を導出します。
暗号文が16バイト未満または2^36 + 16バイトを超える場合は、復号は失敗します。それ以外の場合は、入力を暗号化された平文と16バイトのタグに分割します。メッセージ暗号化鍵を用いて、暗号化された平文をカウンタモードで復号します。最初のカウンタブロックは、最後のバイトの最上位ビットが1に設定されたタグです。暗号化時と同じ方法で、ブロックごとにカウンタを進めます。この時点では、平文は認証されていないため、以下のタグ確認が完了するまで出力してはいけません。
追加データと平文に、それぞれがAESブロックサイズである16バイトの倍数になるまでゼロを埋め込みます。ブロック長とX_1、X_2、…を上記と同様に計算し、S_s = POLYVAL(メッセージ認証キー、X_1、X_2、…)を計算します。
S_sとノンスの排他的論理和を取り、最後のバイトの最上位ビットをクリアし、メッセージ暗号化キーで暗号化することで、期待されるタグを計算します。提供されたタグ値と期待されるタグ値を定数時間で比較します。一致しない場合は復号を失敗させ（平文は返しません）、一致しない場合は平文を返します。
疑似コード形式では、復号プロセスは次のように表すことができます。
code:func
func decrypt(key_generating_key,
nonce,
ciphertext,
additional_data) {
if bytelen(ciphertext) < 16 || bytelen(ciphertext) > 2^36 + 16 {
fail()
}
if bytelen(additional_data) > 2^36 {
fail()
}
message_encryption_key, message_authentication_key =
derive_keys(key_generating_key, nonce)
counter_block = tag
plaintext = AES_CTR(key = message_encryption_key,
initial_counter_block = counter_block,
length_block =
little_endian_uint64(bytelen(additional_data) * 8) ++
little_endian_uint64(bytelen(plaintext) * 8)
padded_plaintext = right_pad_to_multiple_of_16_bytes(plaintext)
padded_ad = right_pad_to_multiple_of_16_bytes(additional_data)
S_s = POLYVAL(key = message_authentication_key,
input = padded_ad ++ padded_plaintext ++
length_block)
for i = 0; i < 12; i++ {
}
expected_tag = AES(key = message_encryption_key, block = S_s)
xor_sum = 0
for i := 0; i < bytelen(expected_tag); i++ {
xor_sum |= expected_tagi ^ tagi }
if xor_sum != 0 {
fail()
}
return plaintext
}
6. AEAD
RFC 5116 の形式で、AES-GCM-SIV を使用する 2 つの AEAD を定義します。
AEAD_AES_128_GCM_SIV と AEAD_AES_256_GCM_SIV です。これらは、使用する AES 鍵のサイズのみが異なります。
これらの AEAD に入力される鍵が鍵生成鍵となります。したがって、AEAD_AES_128_GCM_SIV は 16 バイトの鍵を使用し、AEAD_AES_256_GCM_SIV は 32 バイトの鍵を使用します。
AEAD_AES_128_GCM_SIV のパラメータは以下のとおりです。
K_LEN は 16、P_MAX は 2^36、A_MAX は 2^36、N_MIN と N_MAX は 12、C_MAX は 2^36 + 16 です。
AEAD_AES_256_GCM_SIV のパラメータは鍵サイズのみが異なります。
K_LEN は 32、P_MAX は 2^36、A_MAX は 2^36、N_MIN と N_MAX は 12、C_MAX は 2^36 + 16 です。
7. フィールド演算の例
このドキュメントでは、多項式は 16 バイトの値として記述します。たとえば、16 バイト 0100000000000000000000000000000492 は、多項式 x^127 + x^124 + x^121 + x^114 + 1 を表します。これは、このフィールドの x^-128 の値でもあります。
code:func
If a = 66e94bd4ef8a2c3b884cfa59ca342b2e and
b = ff000000000000000000000000000000,
then a + b = 99e94bd4ef8a2c3b884cfa59ca342b2e,
a * b = 37856175e9dc9df26ebc6d6171aa0ae9, and
dot(a, b) = ebe563401e7e91ea3ad6426b8140c394.
8. 実例
AEAD_AES_128_GCM_SIVを用いて、平文「Hello world」と、keyee8e1ed9ff2540ae8f2ba9f50bc2f27c で指定された追加データ「example」を暗号化する例を考えてみましょう。この例で使用するランダムノンスは 752abad3e0afb5f434dc4310 です。
メッセージ認証鍵とメッセージ暗号化鍵を生成するために、カウンターとノンスを組み合わせて4つのブロックを形成します。これらのブロックは、上記の鍵で暗号化されます。
code:func
Counter | Nonce Ciphertext
00000000752abad3e0afb5f434dc4310 -> 310728d9911f1f38c40e952ca83d093e
01000000752abad3e0afb5f434dc4310 -> 37b24316c3fab9a046ae90952daa0450
02000000752abad3e0afb5f434dc4310 -> a4c5ae624996327947920b2d2412474b
03000000752abad3e0afb5f434dc4310 -> c100be4d7e2c6edd1efef004305ab1e7
暗号文ブロックの後半部分は破棄され、残りのバイトが連結されてメッセージごとのキーが生成されます。したがって、メッセージ認証キーは310728d9911f1f3837b24316c3fab9a0、メッセージ暗号化キーはa4c5ae6249963279c100be4d7e2c6eddとなります。
長さブロックには、追加データと平文のビット長がそれぞれエンコードされています。文字列「example」は7文字で、56ビット（16進数で0x38）です。文字列「Hello world」は11文字で、88 = 0x58ビットです。したがって、長さブロックは38000000000000000580000000000000000です。
POLYVALへの入力は、パディングされた追加データ、パディングされた平文、そして長さブロックです。これは、「example」（6578616d706c65）と「Hello world」（48656c6c6f20776f726c64）のASCIIエンコードに基づいて、6578616d706c6500000000000000004
8656c6c6f20776f726c6400000000003800000000000000058000000000000000000となります。
メッセージ認証キーと上記の入力値を用いてPOLYVALを呼び出すと、S_s = ad7fcf0b5169851662672f3c5f95138f となります。
暗号化前に、ノンスがXOR演算され、最終バイトの最上位ビットがクリアされます。その結果は d85575d8b1c630e256bb6c2c5f95130f となります。これは、そのビットが以前は 1 だったためです。メッセージ暗号化キー（AES-128 を使用）で暗号化すると、タグが生成され、4fbcdeb7e4793f4a1d7e4faa70100af1 となります。
最初のカウンターブロックを形成するために、タグの最終バイトの最上位ビットが 1 に設定されます。この例では、これによって変化は発生しません。これをメッセージキー（AES-128）で暗号化すると、キーストリームの最初のブロックは次のようになります：
1551f2c1787e81deac9a99f139540ab5
最終的な暗号文は、平文とキーストリームのXOR演算を行い、タグを追加したものです。つまり、5d349ead175ef6b1def6fd4fbcdeb7e4793f4a1d7e4faa70100af1となります。
9. セキュリティに関する考慮事項
AES-GCM-SIVの復号では、まず認証されていない平文が生成されます。この平文は攻撃者による改ざんに対して脆弱です。そのため、実装が平文を認証する前に平文の一部または全部を公開した場合、システムの他の部分が悪意のあるデータを真正なデータとして処理する可能性があります。AES-GCMでは、暗号文は通常、平文計算の前、または平文計算と並行して認証されるため、実装がこのような操作を行う可能性は低いと考えられます。したがって、この規定では、実装は認証されていない平文を公開してはならないと規定しています。したがって、システム設計者はAES-GCM-SIVの平文のサイズを選択する際に、メモリの制限を考慮する必要があります。大きな平文は一部のマシンの利用可能なメモリに収まらない場合があり、実装は検証されていない平文を公開してしまう可能性があります。
AES-GCM-SIVの詳細な暗号解析はAES-GCM-SIVに掲載されており、このセクションの残りの部分はその論文の要約です。 本文書で定義されるAEADは、各ノンスに対して新しいAES鍵を算出します。これにより、与えられた鍵でより多くの平文を暗号化できます。このステップがなければ、AES-GCM-SIV暗号化は、他の標準モード（AES-GCM、AES-CCM RFC3610、AES-SIV RFC5297など）と同様に、誕生日の制限を受けます。つまり、全体で2^64ブロックが暗号化された場合、この方式の機密性を破ろうとする識別可能な攻撃者は1/2のアドバンテージを持つことになります。したがって、攻撃者のアドバンテージを2^-32に制限するためには、全体で最大2^48ブロックしか暗号化できません。一方、各ノンスから新しい鍵を導出することで、AES-GCM-SIVでははるかに多くのメッセージとブロックを暗号化できます。 ノンス誤用耐性スキームは、ノンスが重複した場合でも、同一の平文から同一の暗号文が生成されるというセキュリティ損失のみを保証することを強調します。これは（同一の平文が2回暗号化されたという事実が明らかになる）懸念事項となる可能性があるため、固定ノンスをポリシーとして使用することは推奨しません。さらに、以下に示すように、ノンスの重複率が低い場合、AES-GCM-SIVは誕生日よりも優れた境界を実現します。最後に、BHT18に示されているように、マルチユーザー/マルチキー設定において、特定のノンスが少数のユーザーによってのみ再利用される場合、セキュリティ上の大きな利点があります。ノンス誤用耐性特性は、意図的なノンス再利用と組み合わせることを意図したものではなく、むしろ、そのようなスキームはノンス再利用の際に可能な限り最高のセキュリティを提供するものであることを強調します。上記のすべてを踏まえ、AES-GCM-SIVのノンスはランダムに生成することが推奨されます。 AES-GCM-SIVの使用限界の例を以下に示します。攻撃者の優位性はkey-deriveの「AdvEnc」であり、口語的には攻撃者が暗号文とランダムビット列を区別する能力を指します。以下の限界は、この優位性を2^-32に制限します。同じノンスと鍵を最大256回使用する（つまり、ノンスの悪用がこの限界を超えないと想定できる）場合、以下のメッセージ制限を遵守する必要があります（これは、追加認証データ（AAD）が短い、つまり64バイト未満であることを前提としています）。 2^29 メッセージ（各平文は最大 1 GiB）
2^35 メッセージ（各平文は最大 128 MiB）
2^49 メッセージ（各平文は最大 1 MiB）
2^61 メッセージ（各平文は最大 16 KiB）
鈴木ら multi-birthday は、たとえノンスが均一にランダムに選択されたとしても、1つ以上の値が256回以上繰り返される確率は、ノンスの数が2^102に達するまでは無視できることを示しています。（具体的には、確率は1/((2^96)^(255)) * Binomial(q, 256) であり、qはノンスの個数です。）2^102は、上記で示した鍵あたりの平文数の制限よりもはるかに大きいため、ノンスの繰り返し回数に関するこの制限は問題にならないと考えています。これはまた、ノンスをランダムに選択することがAES-GCM-SIVにおいて安全な方法であることを意味します。ランダムノンスに対して得られた境界は以下の通りです（前述の通り、これらの境界では、攻撃者の優位性は最大で2^-32です）。 2^32 メッセージ（各平文は最大 8 GiB）
2^48 メッセージ（各平文は最大 32 MiB）
2^64 メッセージ（各平文は最大 128 KiB）
何らかの理由でノンスの繰り返し回数がさらに多くなることが考えられる状況（例えば、ランダム性が非常に低いデバイスなど）では、メッセージの制限を再検討する必要があります。AES-GCM-SIV の定理 7 にはより詳細な情報が記載されていますが、各ノンスの繰り返し回数が最大 1,024 回の場合、制限は以下のようになります（ここでも AAD が短い、つまり 64 バイト未満であると仮定）。 2^25 メッセージ（各平文が最大 1 GiB）
2^31 メッセージ（各平文が最大 128 MiB）
2^45 メッセージ（各平文が最大 1 MiB）
2^57 メッセージ（各平文が最大 16 KiB）
これらの AEAD は、各ノンスに対して新しい AES 鍵を計算するだけでなく、新しい POLYVAL 鍵も計算します。 GCM-SIVの以前のバージョンでは、これが行われず、代わりにAEAD鍵の一部をPOLYVAL鍵として使用していました。BleichenbacherはBleichenbacher16、これによりAEAD鍵を制御する攻撃者がPOLYVAL鍵を強制的にゼロに設定できることを指摘しました。このAEADのユーザーが秘密の追加データ値を使用してメッセージを認証した場合、攻撃者は入力を知らなくても有効な認証子を計算できるため、安全ではありません。追加データは機密であるとは想定されていないため、これはAEADの標準的な特性に違反しません。しかし、私たちはこれらのAEADが起こりうる悪用に対して堅牢であり、AES-GCMの代替として、この問題を回避するためにノンス固有のPOLYVAL鍵を導出することを望んでいます。 また、攻撃者に許可される試行回数に応じて、偽造が成功する可能性が高くなることにも留意してください。 key-derive で定義され、上記で用いた利点は、攻撃者が暗号文とランダムビット列を区別できる能力によって規定されています。したがって、これは機密性と完全性の両方を網羅しており、key-derive の定理 6.2 は、利点は復号試行回数に応じて増大しますが、暗号化回数による増大よりもはるかに緩やかであることを示しています。偽造に対する復号クエリ回数への依存性は、実際には二次関数ではなく線形です。二次関数は、論文で規定された上限が厳密ではないことによるものです。攻撃者に極めて多くの試行回数が許される場合、任意の試行が成功する確率はごくわずかであっても、合計すると無視できないほどの確率になる可能性があります。 AES-GCM-SIVのマルチユーザー／マルチキーセキュリティはBHT18によって研究されており、ノンスが複数のユーザー間で重複しない限り、セキュリティはシングルユーザー設定とほぼ同じであることが示されています。これは、ノンスがランダムに選択される場合に当てはまります。 10. IANA に関する考慮事項
IANA は「AEAD アルゴリズム」レジストリに 2 つのエントリを追加しました。
AEAD_AES_128_GCM_SIV (数値 ID 30) と AEAD_AES_256_GCM_SIV (数値 ID 31) です。どちらもこのドキュメントを仕様として参照しています。
11.1. 規範的参考文献
RFC2119 Bradner, S., 「RFC における要件レベルを示すキーワード」、BCP 14、RFC 2119、 DOI 10.17487/RFC2119、1997年3月、
RFC8174 Leiba, B., 「RFC 2119 キーワードにおける大文字と小文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、 Dworkin, M.、「ブロック暗号の動作モードに関する推奨事項：方法と技術」、NIST SP 800-38A、
DOI 10.6028/NIST.SP.800-38A、2001年12月、
11.2. 参考文献
Gueron, S., Langley, A., Y. Lindell, "AES-GCM-SIV:
仕様と分析", 2017年7月,
Gueron, S., Langley, A., Y. Lindell, "AES-GCM-SIV動作モードのウェブページ",
BHT18 Bose, P.、Hoang, V.、S. Tessaro、「AES-GCM-SIVの再考：マルチユーザーセキュリティ、鍵導出の高速化、そしてより良い境界値」、Advances in Cryptology - EUROCRYPT 2018、 DOI 10.1007/978-3-319-78381-9_18、2018年5月、
GCM Dworkin, M.、「ブロック暗号の動作モードに関する推奨事項：ガロア/カウンタモード（GCM）およびGMAC」、NIST SP 800-38D、DOI 10.6028/NIST.SP.800-38D、2007年11月、
GCM-SIV Gueron, S.、Y. Lindell、「GCM-SIV: 1バイトあたり1サイクル未満でノンス誤用耐性を備えた認証付き暗号化」、第22回ACM SIGSACコンピュータおよび通信セキュリティ会議議事録、DOI 10.1145/2810103.2813613、2015年10月、 Gueron, S.、Y. Lindell、「ノンスベースの鍵導出によるブロック暗号の動作モードのより良い境界」、
2017 ACM SIGSAC コンピュータと通信セキュリティ会議議事録、DOI 10.1145/3133956.3133992、
鈴木 健、トニエン 大輔、黒澤 健、豊田 健、
「多重衝突における誕生日パラドックス」、情報セキュリティと暗号学 - ICISC 2006、コンピュータサイエンス講義ノート、第4296巻、DOI 10.1007/11927587_5、
RFC5116 McGrew, D., 「認証付き暗号化のためのインターフェースとアルゴリズム」、RFC 5116、DOI 10.17487/RFC5116、2008年1月、 付録A. POLYVALとGHASHの関係
GHASHとPOLYVALはどちらもGF(2^128)上で動作しますが、使用する既約多項式は異なります。POLYVALはx^128 + x^127 + x^126 + x^121 + 1を法として動作し、GHASHはx^128 + x^7 + x^2 + x + 1を法として動作します。これらの既約多項式は互いに「逆」の関係にあることに注意してください。
GHASHは、128ビット文字列と体要素間のマッピングも異なります。POLYVALは最初のバイトの最下位ビットから最上位ビットまでをx^0からx^7の係数としますが、GHASHはそれらをx^7からx^0の係数とします。この処理は、最後のバイトにおいて、POLYVAL は最下位ビットから最上位ビットまでを x^120 から x^127 の係数とみなし、GHASH はそれらを x^127 から x^120 の係数とみなすまで続きます。
これらの事実を組み合わせると、16バイト文字列内のバイト順序を反転することで、両者の間で値を「変換」することが可能になります。ビット順序の解釈の違いによって各バイト内のビットが反転され、その後バイト順序の反転によって残りの処理が行われます。これは、GHASH と POLYVAL の両方を実装したい実装にとって実用的な利点となる可能性があります。
特定の演算がどのフィールドで実行されるかを明確にするために、mulX_GHASH を、16バイト文字列を受け取り、GHASH の規則に従って GHASH のフィールドの要素に変換し、それを x で乗算して、再び文字列に変換する関数とします。同様に、mulX_POLYVAL は、POLYVAL の規則を使用して 16 バイトの文字列を POLYVAL のフィールドの要素に変換し、それを x で乗算して元に戻す関数とします。
16バイトの文字列0100000000000000000000000000000000000の場合、その文字列のmulX_GHASHは00800000000000000000000000000000000であり、その文字列のmulX_POLYVALは020000000000000000000000000000000000000である。より一般的な例として、9c98c04df9387ded828175a92ba652d8の場合、その文字列のmulX_GHASHは4e4c6026fc9c3ef6c140bad495d3296cであり、そのmulX_POLYVALは3931819bf271fada0503eb52574ca5f2
最後に、16バイトの文字列を受け取り、バイト順序を逆にしたコピーを返す関数をByteReverseとします。