NIST SP 800-38D 日本語訳
英語タイトル : Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC日本語タイトル : Galois/Counter Mode（GCM）とGMAC
公開日 : 2007-11-28
原文URL : https://csrc.nist.gov/pubs/sp/800/38/d/final
翻訳編集 : 自動生成（有志による非公式の日本語訳）, 原文取得日 : 2026-10-01, 訳文 : 394 / 394 ブロック
[要約] SP 800-38D は、関連データ付き認証付き暗号化のアルゴリズムであるガロア／カウンターモード（GCM）と、暗号化されないデータに対して MAC を生成する特殊化である GMAC を規定する勧告です。GCM の構成要素と数学的構成要素、仕様、IV と鍵の一意性要件、実装を検証するための考慮事項、適合性を扱い、付録で IV 一意性の重要性や認証保証を説明します。GCM と GMAC は、ブロックサイズが128ビットの承認済み共通鍵ブロック暗号を基礎とし、ブロック暗号の運用モードに関する一連の勧告の一つです。
Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC
ブロック暗号の利用モードに関する勧告：ガロア／カウンターモード（GCM）およびGMAC
NIST Special Publication 800-38D
November, 2007
NIST特別刊行物800-38D
2007年11月
［NIST のロゴ。公的な標章のため、この非公式サイトには掲載していません。原本 PDF を参照してください。］
Morris Dworkin
Morris Dworkin
［NIST のロゴ。公的な標章のため、この非公式サイトには掲載していません。原本 PDF を参照してください。］
COMPUTER SECURITY
コンピューターセキュリティ
Recommendation for Block
ブロックに関する勧告
NIST Special Publication 800-38D
NIST特別刊行物800-38D
Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC
暗号の利用モード：ガロア／カウンターモード（GCM）およびGMAC
Morris Dworkin
Morris Dworkin
COMPUTER SECURITY
コンピューターセキュリティ
Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930
コンピューターセキュリティ部門 情報技術研究所 米国国立標準技術研究所 Gaithersburg, MD 20899-8930
November 2007
2007年11月
［米国商務省の紋章。公的な標章のため、この非公式サイトには掲載していません。原本 PDF を参照してください。］
U.S. Department of Commerce Carlos M. Gutierrez, Secretary
米国商務省 Carlos M. Gutierrez、長官
National Institute of Standards and Technology James M. Turner, Acting Director
米国国立標準技術研究所 James M. Turner、所長代行
Reports on Information Security Technology
情報セキュリティ技術に関する報告書
The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security, and its collaborative activities with industry, government, and academic organizations.
米国国立標準技術研究所（NIST）の情報技術研究所（ITL）は、国の計測・標準インフラストラクチャに技術的リーダーシップを提供することで、米国経済と公共の福祉を促進しています。ITLは、情報技術の開発と生産的利用を推進するため、試験、試験方法、参照データ、概念実証実装、および技術分析を開発します。ITLの責務には、連邦政府のコンピューターシステムにおける機微な非機密情報の費用対効果に優れたセキュリティとプライバシーのための、技術的、物理的、管理的、および運用管理上の標準とガイドラインの策定が含まれます。この特別刊行物800シリーズは、コンピューターセキュリティに関するITLの研究、ガイダンス、普及活動、および産業界、政府、学術機関との協力活動を報告するものです。
Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.
この文書では、実験手順または概念を適切に説明するため、特定の商業事業体、機器、または材料に言及する場合があります。このような特定は、米国国立標準技術研究所による推奨または保証を意味するものではなく、また、その事業体、材料、または機器が目的に対して必ずしも最良の選択肢であることを意味するものでもありません。
National Institute of Standards and Technology Special Publication 800-38D Natl. Inst. Stand. Technol. Spec. Publ. 800-38D 37 pages (November 2007)
米国国立標準技術研究所 特別刊行物800-38D Natl. Inst. Stand. Technol. Spec. Publ. 800-38D 37ページ（2007年11月）
CODEN: NSPUE2
CODEN: NSPUE2
Acknowledgements
謝辞
The author wishes to thank David McGrew, who co-invented GCM and submitted it to NIST, and also the author’s colleagues who reviewed drafts of this document and contributed to its development, especially Elaine Barker, John Kelsey, Allen Roginsky, Donna Dodson, Tim Polk, and Bill Burr. The author also gratefully acknowledges the many comments from the public and private sectors to improve the quality and usefulness of this publication.
著者は、GCMを共同発明しNISTに提出したDavid McGrew、および本書の草稿を査読し作成に貢献した同僚、とりわけElaine Barker、John Kelsey、Allen Roginsky、Donna Dodson、Tim Polk、Bill Burrに謝意を表します。また、本刊行物の品質と有用性を高めるために寄せられた官民両部門からの多くのコメントにも、著者は深く感謝します。
Abstract
要旨
This Recommendation specifies the Galois/Counter Mode (GCM), an algorithm for authenticated encryption with associated data, and its specialization, GMAC, for generating a message authentication code (MAC) on data that is not encrypted. GCM and GMAC are modes of operation for an underlying approved symmetric key block cipher.
本勧告は、関連データ付き認証付き暗号化のアルゴリズムであるガロア／カウンターモード（GCM）と、暗号化されないデータに対してメッセージ認証コード（MAC）を生成するGCMの特殊化であるGMACを規定します。GCMおよびGMACは、承認された共通鍵ブロック暗号を基礎とする利用モードです。
KEY WORDS: authenticated encryption; authentication; block cipher; confidentiality, cryptography; encryption; information security; mode of operation.
キーワード：認証付き暗号化、認証、ブロック暗号、機密性、暗号技術、暗号化、情報セキュリティ、利用モード。
Table of Contents
目次
List of Figures
図一覧
Figure 1: GHASH H (X 1 || X 2 || ... || X m ) = Y m
図1：GHASH H (X 1 || X 2 || ... || X m ) = Y m
List of Tables
表一覧
1 Purpose
1 目的
This publication is the fourth Part in a series of Recommendations regarding modes of operation of symmetric key block ciphers.
本刊行物は、共通鍵ブロック暗号の動作モードに関する勧告シリーズの第4部です。
2 Authority
2 権限
This document has been developed by the National Institute of Standards and Technology (NIST) in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.
この文書は、2002年の連邦情報セキュリティ管理法（FISMA）、公法107-347に基づく法定責任を遂行するため、米国国立標準技術研究所（NIST）が作成しました。
NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets, but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III.
NISTは、すべての政府機関の業務および資産に適切な情報セキュリティを提供するため、最低要件を含む標準およびガイドラインを策定する責任を負います。ただし、そのような標準およびガイドラインは国家安全保障システムには適用されません。本ガイドラインは、OMB Circular A-130のSection 8b(3)「政府機関情報システムの保護」の要件と整合しており、その要件はA-130 Appendix IV「主要条項の分析」で分析されています。補足情報はA-130 Appendix IIIに記載されています。
This Recommendation has been prepared for use by federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright. (Attribution would be appreciated by NIST.)
本Recommendationは連邦政府機関での使用を目的として作成されました。政府機関以外の組織も任意で使用でき、著作権の対象ではありません。（NISTの出典を明記していただければ幸いです。）
Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official.
本書のいかなる内容も、法定権限に基づき商務長官が連邦政府機関に義務付け、拘束力を持たせた標準およびガイドラインに矛盾すると解釈してはなりません。また、本ガイドラインを、商務長官、OMB長官、その他の連邦政府職員の既存の権限を変更または置換するものと解釈してはなりません。
Conformance testing for implementations of the mode of operation that is specified in this Part of the Recommendation will be conducted within the framework of the Cryptographic Module Validation Program (CMVP), a joint effort of NIST and the Communications Security Establishment of the Government of Canada. An implementation of a mode of operation must adhere to the requirements in this Recommendation in order to be validated under the CMVP. The requirements of this Recommendation are indicated by the word “shall.”
本勧告の本部で規定する利用モードの実装に対する適合性試験は、NISTとカナダ政府のCommunications Security Establishmentが共同で取り組むCryptographic Module Validation Program（CMVP）の枠組みで実施されます。CMVPの下で検証を受けるには、利用モードの実装は本勧告の要件に従わなければなりません。本勧告の要件は「shall」という語で示されます。
3 Introduction
3 はじめに
This Recommendation specifies an algorithm called Galois/Counter Mode (GCM) for authenticated encryption with associated data. GCM is constructed from an approved symmetric key block cipher with a block size of 128 bits, such as the Advanced Encryption Standard (AES) algorithm that is specified in Federal Information Processing Standard (FIPS) Pub. 197 [2]. Thus, GCM is a mode of operation of the AES algorithm.
本Recommendationは、関連データ付き認証暗号化のためのGalois/Counter Mode（GCM）と呼ばれるアルゴリズムを規定します。GCMは、ブロックサイズが128ビットの承認済み共通鍵ブロック暗号から構成されます。例えば、Federal Information Processing Standard（FIPS）Pub. 197 [2]で規定されるAdvanced Encryption Standard（AES）アルゴリズムがあります。したがって、GCMはAESアルゴリズムの動作モードです。
GCM provides assurance of the confidentiality of data using a variation of the Counter mode of operation for encryption. GCM provides assurance of the authenticity of the confidential data (up to about 64 gigabytes per invocation) using a universal hash function that is defined over a binary Galois (i.e., finite) field. GCM can also provide authentication assurance for additional data (of practically unlimited length per invocation) that is not encrypted.
GCMは、暗号化にCounter動作モードの変形を用いてデータの機密性を保証します。GCMはまた、二元ガロア（すなわち有限）体上で定義される普遍ハッシュ関数を用いて、機密データ（1回の呼び出しあたり約64ギガバイトまで）の真正性を保証します。GCMはさらに、暗号化されない追加データについても、1回の呼び出しあたり実質的に無制限の長さで真正性を保証できます。
If the GCM input is restricted to data that is not to be encrypted, the resulting specialization of GCM, called GMAC, is simply an authentication mode on the input data. In the rest of this document, statements about GCM also apply to GMAC.
GCMへの入力を暗号化しないデータに限定すると、GMACと呼ばれるGCMの特殊化は、入力データに対する単純な認証モードとなります。本書の以下の記述におけるGCMへの言及はGMACにも適用されます。
GCM provides stronger authentication assurance than a (non-cryptographic) checksum or error detecting code; in particular, GCM can detect both 1) accidental modifications of the data and 2) intentional, unauthorized modifications.
GCMは（暗号方式によらない）チェックサムまたは誤り検出符号より強い認証保証を提供します。特に、GCMは1) データの偶発的な変更と2) 意図的かつ不正な変更の両方を検出できます。
The two functions of GCM are called authenticated encryption and authenticated decryption. Each of these functions is relatively efficient and parallelizable; consequently, high-throughput implementations are possible in both hardware and software. GCM has several other useful characteristics, including the following:
GCMの2つの機能は、認証暗号化と認証復号と呼ばれます。いずれの機能も比較的効率的で並列化が可能です。そのため、ハードウェアとソフトウェアの双方で高スループットの実装が可能です。GCMには、次のようなその他の有用な特性があります。
•The GCM functions are “online” in the sense that the lengths of the confidential data and the additional, non-confidential data are not required in advance; instead, the lengths can be calculated as the data arrives and is processed.
•GCMの機能は「オンライン」です。つまり、機密データおよび追加の非機密データの長さを事前に知る必要はなく、データの到着・処理に伴って長さを計算できます。
•The GCM functions require only the forward direction of the underlying block cipher (i.e., the inverse direction is not required).
•GCMの機能では、基礎となるブロック暗号の順方向のみを使用し、逆方向は必要としません。
•The authenticity of the protected data can be verified independently from the recovery of the confidential data from its encrypted form.
•保護対象データの真正性は、機密データを暗号文から復元する処理とは独立して検証できます。
•If the unique initialization string is predictable, and the length of the confidential data is known, then the block cipher invocations within the GCM encryption mechanism can be pre-computed.
•一意な初期化文字列が予測可能であり、機密データの長さが既知である場合、GCM暗号化機構内のブロック暗号呼び出しを事前計算できます。
•If some or all of the additional, non-confidential data is fixed, then the corresponding elements of the GCM authentication mechanism can be pre-computed.
•追加の非機密データの一部または全部が固定されている場合、GCM認証機構の対応する要素を事前計算できます。
An important caution to the use of GCM is that a breach of the requirement in Sec. 8 for the uniqueness of the initialization strings may compromise the security assurance almost entirely, as detailed in Ref. [5] and summarized in Appendix A. Therefore, this mode of operation should not be deployed unless compliance with this uniqueness requirement is ensured. Some of the practical considerations are discussed further in Secs. 9.1 and 9.2.
GCMの使用に関する重要な注意点として、第8節の初期化文字列の一意性要件に違反すると、Ref. [5]で詳述されAppendix Aで要約されているとおり、セキュリティ保証がほぼ完全に損なわれるおそれがあります。したがって、この一意性要件への準拠を確保できない場合、この動作モードを導入すべきではありません。実務上の考慮事項は第9.1節および第9.2節でさらに論じます。
The designers of GCM are McGrew and Viega. They submitted GCM to NIST in Ref. [6], and they discuss in detail its security and performance in Ref. [7].
GCMの設計者はMcGrewとViegaです。両者はRef. [6]でGCMをNISTに提出し、Ref. [7]でそのセキュリティと性能を詳しく論じています。
4 Definitions, Abbreviations, and Symbols
4 定義、略語、および記号
4.1 Definitions and Abbreviations
4.1 定義および略語
| AAD | Additional Authenticated Data |
| Additional Authenticated Data | The input data to the authenticated encryption function that is authenticated but not encrypted. |
| AES | Advanced Encryption Standard. |
| Approved | FIPS approved or NIST recommended: an algorithm or technique that is either 1) specified in a FIPS or a NIST Recommendation, or 2) adopted in a FIPS or a NIST Recommendation. |
| Authenticated Decryption | The function of GCM in which the ciphertext is decrypted into the plaintext, and the authenticity of the ciphertext and the AAD is verified. |
| Authenticated Encryption | The function of GCM in which the plaintext is encrypted into the ciphertext, and an authentication tag is generated on the AAD and the ciphertext. |
| Authentication Tag (Tag) | A cryptographic checksum on data that is designed to reveal both accidental errors and the intentional modification of the data. |
| Authenticity | The property that data originated from its purported source. |
| Bit | A binary digit: 0 or 1. |
| Bit String | A finite, ordered sequence of bits. |
| Block | For a given block cipher, a bit string whose length is the block size of the block cipher. |
| Block Cipher | A parameterized family of permutations on bit strings of a fixed length; the parameter that determines the permutation is a bit string called the key. |
| Block Size | For a given block cipher and key, the fixed length of the input (or output) bit strings. |
| Byte | A sequence of 8 bits. |
| Byte String | A finite, ordered sequence of bytes. |
| Ciphertext | The encrypted form of the plaintext. |
原本PDFの抜粋画像
| AAD | 追加認証データ |
| 追加認証データ | 認証暗号化関数への入力データのうち、認証されるが暗号化されないもの。 |
| AES | Advanced Encryption Standard。 |
| 承認済み | FIPS承認またはNIST推奨。1) FIPSまたはNIST Recommendationで規定されている、あるいは2) FIPSまたはNIST Recommendationで採用されているアルゴリズムまたは技法。 |
| 認証復号 | 暗号文を平文に復号し、暗号文およびAADの真正性を検証するGCMの機能。 |
| 認証暗号化 | 平文を暗号文に暗号化し、AADおよび暗号文に対する認証タグを生成するGCMの機能。 |
| 認証タグ（Tag） | 偶発的な誤りと意図的なデータ変更の両方を明らかにするよう設計された、データに対する暗号学的チェックサム。 |
| 真正性 | データが、主張された送信元から発生したという性質。 |
| ビット | 2進数の1桁：0または1。 |
| ビット列 | 有限で順序付けられたビットの列。 |
| ブロック | 特定のブロック暗号において、長さがそのブロック暗号のブロックサイズに等しいビット列。 |
| ブロック暗号 | 固定長のビット列上の置換からなるパラメータ化された族。置換を決定するパラメータは鍵と呼ばれるビット列です。 |
| ブロックサイズ | 特定のブロック暗号および鍵に対して固定された入力（または出力）ビット列の長さ。 |
| バイト | 8ビットの列。 |
| バイト列 | 有限で順序付けられたバイトの列。 |
| 暗号文 | 平文を暗号化したもの。 |
| Direct Random String | In the RBG-based construction of IVs, an output string of an RBG that is used as the random field for an IV. |
| Exclusive-OR | The bitwise addition, modulo 2, of two bit strings of equal length. |
| FIPS | Federal Information Processing Standard. |
| Fixed Field | In the deterministic construction of IVs, the field that identifies the device or context for the instance of the authenticated encryption function. |
| Forward Cipher Function | A permutation on blocks that is determined by the choice of a key for a given block cipher. |
| Free Field | In the RBG-based construction of IVs, the field whose contents are not restricted. |
| Fresh | For a newly generated key, the property of being unequal to any previously used key. |
| GCM | Galois/Counter Mode |
| ICB | Initial Counter Block |
| Initialization Vector | A nonce that is associated with an invocation of authenticated encryption on a particular plaintext and AAD. |
| Inverse Cipher Function | The function that is the inverse of the forward cipher function for a given key. |
| Invocation Field | In the deterministic construction of IVs, the field that identifies the sets of inputs to the authenticated encryption function in a particular device or context. |
| IT | Information Technology |
| IV | Initialization Vector |
| Key | The parameter of the block cipher that determines the selection of the forward cipher function from the family of permutations. |
| Least Significant Bit(s) | The right-most bit(s) of a bit string. |
| Mode of Operation (Mode) | An algorithm for the cryptographic transformation of data that is based on a block cipher. |
原本PDFの抜粋画像
| 直接ランダム文字列 | IVのRBGベース構成において、IVのランダムフィールドとして使用するRBGの出力文字列。 |
| 排他的論理和 | 同じ長さの2つのビット列に対する、ビット単位の加算（法2）。 |
| FIPS | Federal Information Processing Standard。 |
| 固定フィールド | IVの決定論的構成において、認証暗号化関数の呼び出しに関するデバイスまたはコンテキストを識別するフィールド。 |
| 順方向暗号関数 | 特定のブロック暗号について、鍵の選択によって決定されるブロック上の置換。 |
| 自由フィールド | IVのRBGベース構成において、内容に制限がないフィールド。 |
| 新規 | 新たに生成された鍵が、過去に使用されたどの鍵とも等しくないという性質。 |
| GCM | Galois/Counter Mode |
| ICB | 初期カウンタブロック |
| 初期化ベクトル | 特定の平文およびAADに対する認証暗号化の呼び出しに関連付けられるnonce。 |
| 逆方向暗号関数 | 特定の鍵について順方向暗号関数の逆関数となる関数。 |
| 呼び出しフィールド | IVの決定論的構成において、特定のデバイスまたはコンテキストで認証暗号化関数に与える入力の組を識別するフィールド。 |
| IT | 情報技術 |
| IV | 初期化ベクトル |
| 鍵 | 置換族から順方向暗号関数を選択するブロック暗号のパラメータ。 |
| 最下位ビット | ビット列の最も右側のビット（複数の場合は最も右側のビット群）。 |
| 動作モード（Mode） | ブロック暗号に基づくデータの暗号変換アルゴリズム。 |
| Most Significant Bit(s) | The left-most bit(s) of a bit string. |
| NIST | National Institute of Standards and Technology. |
| Nonce | A value that is used only once within a specified context. |
| Permutation | An invertible function. |
| Plaintext | The input data to the authenticated encryption function that is both authenticated and encrypted. |
| Random Field | In the RBG-based construction of IVs, either a direct random string or one of its successors. |
| RBG | Random Bit Generator |
| Successor | In the RBG-based construction of IVs, the result of one or more applications of the appropriate incrementing function to a direct random string. |
| XOR | Exclusive-OR. |
原本PDFの抜粋画像
| 最上位ビット | ビット列の最も左側のビット（複数の場合は最も左側のビット群）。 |
| NIST | National Institute of Standards and Technology。 |
| ノンス | 指定されたコンテキスト内で一度だけ使用される値。 |
| 置換 | 可逆関数。 |
| 平文 | 認証暗号化関数への入力データのうち、認証と暗号化の両方が行われるもの。 |
| ランダムフィールド | IVのRBGベース構成において、直接ランダム文字列またはその後続値のいずれか。 |
| RBG | ランダムビット生成器 |
| 後続値 | IVのRBGベース構成において、直接ランダム文字列に適切なインクリメント関数を1回以上適用した結果。 |
| XOR | 排他的論理和。 |
4.2 Symbols
4.2 記号
4.2.1 Variables
4.2.1 変数
\(A\)
\(A\)
The additional authenticated data
追加認証データ
\(C\)
\(C\)
The ciphertext.
暗号文。
\(H\)
\(H\)
The hash subkey.
ハッシュ部分鍵。
\(\mathit{ICB}\)
\(\mathit{ICB}\)
The initial counter block
初期カウンタブロック
\(\mathit{IV}\)
\(\mathit{IV}\)
The initialization vector.
初期化ベクトル。
\(K\)
\(K\)
The block cipher key.
ブロック暗号鍵。
\(P\)
\(P\)
The plaintext.
平文。
\(R\)
\(R\)
The constant within the algorithm for the block multiplication operation.
ブロック乗算演算アルゴリズム内の定数。
\(T\)
\(T\)
The authentication tag.
認証タグ。
\(t\)
\(t\)
The bit length of the authentication tag.
認証タグのビット長。
4.2.2 Operations and Functions
4.2.2 演算と関数
\(0^s\)
\(0^s\)
The bit string that consists of \(s\) ‘0’ bits.
\(s\)個の「0」ビットからなるビット列。
\(\mathrm{CIPH}_K(X)\)
\(\mathrm{CIPH}_K(X)\)
\(CIPH_K(X)\) — The output of the forward cipher function of the block cipher under the key K applied to the block X.
\(CIPH_K(X)\) — 鍵 K の下でブロック暗号の順方向暗号関数をブロック X に適用した出力。
\(\mathrm{GCTR}_K(\mathit{ICB}, X)\)
\(\mathrm{GCTR}_K(\mathit{ICB}, X)\)
The output of the GCTR function for a given block cipher with key \(K\) applied to the bit string \(X\) with an initial counter block \(\mathit{ICB}\).
鍵\(K\)を持つ所与のブロック暗号について、ビット列\(X\)に初期カウンターブロック\(\mathit{ICB}\)を用いて適用したGCTR関数の出力。
\(\mathrm{GHASH}_H(X)\)
\(\mathrm{GHASH}_H(X)\)
\(GHASH_H(X)\) — The output of the GHASH function under the hash subkey H applied to the bit string X.
\(GHASH_H(X)\) — ハッシュサブキー H の下で GHASH 関数をビット列 X に適用した出力。
\(inc_s(X)\) — The output of incrementing the right-most s bits of the bit string X, regarded as the binary representation of an integer, by 1 modulo \(2^s\).
\(inc_s(X)\) — ビット列 X の右端の s ビットを整数の2進表現とみなし、これに \(2^s\) を法として1を加えた出力。
The output of incrementing the right-most \(s\) bits of the bit string \(X\), regarded as the binary representation of an integer, by 1 modulo \(2^s\).
右端の\(s\)ビットをビット列\(X\)から取り、整数の2進表現とみなして、法\(2^s\)で1だけ増加させた出力。
\(\mathrm{int}(X)\)
\(\mathrm{int}(X)\)
The integer for which the bit string \(X\) is a binary representation.
ビット列\(X\)を2進表現とする整数。
\(\mathrm{len}(X)\)
\(\mathrm{len}(X)\)
The bit length of the bit string \(X\).
ビット列\(X\)のビット長。
\(LSB_s(X)\) — The bit string consisting of the s right-most bits of the bit string X.
\(LSB_s(X)\) — ビット列 X の右端の s ビットからなるビット列。
The bit string consisting of the \(s\) right-most bits of the bit string \(X\).
右端の\(s\)ビットをビット列\(X\)から取り出したビット列。
\(MSB_s(X)\) — The bit string consisting of the s left-most bits of the bit string X.
\(MSB_s(X)\) — ビット列 X の左端の s ビットからなるビット列。
The bit string consisting of the \(s\) left-most bits of the bit string \(X\).
左端の\(s\)ビットをビット列\(X\)から取り出したビット列。
\(\lceil x \rceil\)
\(\lceil x \rceil\)
The least integer that is not less than the real number \(x\).
実数\(x\)以上である最小の整数。
\([x]_s\) — The binary representation of the non-negative integer x as a string of s bits, where \(x<2^s\).
\([x]_s\) — 非負整数 x の s ビット列としての2進表現。ただし \(x<2^s\) とします。
The binary representation of the non-negative integer \(x\) as a string of \(s\) bits, where \(x < 2^s\).
非負整数\(x\)を\(s\)ビットのビット列として表した2進表現。ただし、\(x < 2^s\)。
\(X \mathbin{>>} 1\)
\(X \mathbin{>>} 1\)
The bit string that results from discarding the rightmost bit of the bit string \(X\) and prepending a ‘0’ bit on the left.
ビット列\(X\)の右端のビットを取り除き、左端に「0」ビットを付加して得られるビット列。
\(X \parallel Y\)
\(X \parallel Y\)
The concatenation of two bit strings \(X\) and \(Y\).
2つのビット列\(X\)および\(Y\)の連結。
\(X \oplus Y\)
\(X \oplus Y\)
The bitwise exclusive-OR of two bit strings \(X\) and \(Y\) of the same length.
同じ長さの2つのビット列\(X\)および\(Y\)のビット単位の排他的論理和。
\(X \bullet Y\)
\(X \bullet Y\)
The product of two blocks, \(X\) and \(Y\), regarded as elements of a certain binary Galois field.
2つのブロック\(X\)および\(Y\)を、特定の二元ガロア体の要素とみなしたときの積。
\(X^i\)
\(X^i\)
For a positive integer \(i\), the \(i\)th power of \(X\) under the product ‘\(\bullet\)’.
正の整数\(i\)について、\(i\)乗を\(X\)に対し積「\(\bullet\)」のもとでとったもの。
\(x \cdot y\)
\(x \cdot y\)
The product of two integers, \(x\) and \(y\).
2つの整数\(x\)および\(y\)の積。
5 Elements of GCM
5 GCMの構成要素
The elements of GCM and the associated notation and requirements are introduced in the three sections below. The underlying block cipher and key are discussed in Sec. 5.1. The data elements of the authenticated encryption and authenticated decryption functions of GCM are discussed in Sec. 5.2. The cryptographic primitives for confidentiality and authentication within these two functions are discussed in Sec. 5.3.
GCMの構成要素と、それに関連する表記法および要件を以下の3節で紹介します。基礎となるブロック暗号と鍵については5.1節で説明します。GCMの認証付き暗号化関数および認証付き復号関数のデータ要素については5.2節で説明します。これら2つの関数における機密性と認証のための暗号プリミティブについては5.3節で説明します。
5.1 Block Cipher
5.1 ブロック暗号
The operations of GCM depend on the choice of an underlying symmetric key block cipher and thus can be considered a mode of operation (mode, for short) of the block cipher. The GCM key is the block cipher key (the key, for short).
GCMの演算は基礎となる共通鍵ブロック暗号の選択に依存するため、当該ブロック暗号の利用モード（以下、単に「モード」）とみなすことができます。GCM鍵とは、ブロック暗号の鍵（以下、単に「鍵」）です。
For any given key, the underlying block cipher of the mode consists of two functions that are inverses of each other. The choice of the block cipher includes the designation of one of the two functions of the block cipher as the forward cipher function, as in the specification of the AES algorithm in Ref. [2]. GCM does not employ the inverse cipher function.
任意の鍵について、このモードの基礎となるブロック暗号は、互いに逆関数となる2つの関数で構成されます。ブロック暗号の選択には、文献[2]のAESアルゴリズム仕様と同様に、ブロック暗号の2つの関数の一方を順方向暗号関数として指定することが含まれます。GCMは逆方向暗号関数を使用しません。
The forward cipher function is a permutation on bit strings of a fixed length; the strings are called blocks. The length of a block is called the block size. The key is denoted \(K\), and the resulting forward cipher function of the block cipher is denoted \(\mathrm{CIPH}_K\).
順方向暗号関数は、固定長のビット列上の置換です。これらのビット列をブロックと呼びます。ブロックの長さをブロックサイズと呼びます。鍵を\(K\)と表し、ブロック暗号における順方向暗号関数を\(\mathrm{CIPH}_K\)と表します。
The underlying block cipher shall be approved, the block size shall be 128 bits, and the key size shall be at least 128 bits. The key shall be generated uniformly at random, or close to uniformly at random, i.e., so that each possible key is (nearly) equally likely to be generated. Consequently, the key will be fresh, i.e., unequal to any previous key, with high probability. The key shall be secret and shall be used exclusively for GCM with the chosen block cipher. Additional requirements on the establishment and management of keys are discussed in Sec. 8.1.
基礎となるブロック暗号は承認済みでなければならず、ブロックサイズは128ビット、鍵サイズは128ビット以上でなければなりません。鍵は一様ランダム、または一様ランダムに近い方法で生成しなければなりません。すなわち、可能な各鍵が（ほぼ）等しい確率で生成されるようにします。その結果、高い確率で鍵は新鮮、すなわち過去のどの鍵とも異なるものとなります。鍵は秘密に保ち、選択したブロック暗号によるGCMに限って使用しなければなりません。鍵の確立および管理に関する追加要件は8.1節で説明します。
5.2 Two GCM Functions
5.2 2つのGCM関数
The two functions that comprise GCM are called authenticated encryption and authenticated decryption. The authenticated encryption function encrypts the confidential data and computes an authentication tag on both the confidential data and any additional, non-confidential data. The authenticated decryption function decrypts the confidential data, contingent on the verification of the tag.
GCMを構成する2つの関数を、認証付き暗号化および認証付き復号と呼びます。認証付き暗号化関数は、機密データを暗号化し、機密データと追加の非機密データの両方に対する認証タグを計算します。認証付き復号関数は、タグの検証が成功することを条件として、機密データを復号します。
An implementation may restrict the input to the non-confidential data, i.e., without any confidential data. The resulting variant of GCM is called GMAC. For GMAC, the authenticated encryption and decryption functions become the functions for generating and verifying an authentication tag on the non-confidential data.
実装は、入力を非機密データのみに、すなわち機密データを含まないものに制限してもよいです。この結果得られるGCMの変種をGMACと呼びます。GMACでは、認証付き暗号化関数および認証付き復号関数は、非機密データに対する認証タグを生成および検証する関数となります。
The requirements and notation for the input and output data of these functions are discussed in Secs. 5.2.1 and 5.2.2. Algorithms for computing these functions are given in Sec. 7.
これらの関数の入力データおよび出力データに関する要件と表記法は5.2.1節および5.2.2節で説明します。これらの関数を計算するアルゴリズムは第7節に示します。
5.2.1 Authenticated Encryption Function
5.2.1 認証付き暗号化関数
5.2.1.1 Input Data
5.2.1.1 入力データ
Given the selection of an approved block cipher and key, there are three input strings to the authenticated encryption function:
承認済みブロック暗号および鍵を選択した場合、認証付き暗号化関数への入力文字列は3つあります。
• a plaintext, denoted \(P\);
• 平文。\(P\)と表します。
• additional authenticated data (AAD), denoted \(A\); and
• 追加認証データ（AAD）。\(A\)と表します。および
• an initialization vector (IV), denoted \(\mathit{IV}\).
• 初期化ベクトル（IV）。\(\mathit{IV}\)と表します。
The plaintext and the AAD are the two categories of data that GCM protects. GCM protects the authenticity of the plaintext and the AAD; GCM also protects the confidentiality of the plaintext, while the AAD is left in the clear. For example, within a network protocol, the AAD might include addresses, ports, sequence numbers, protocol version numbers, and other fields that indicate how the plaintext should be treated.
平文とAADは、GCMが保護する2種類のデータです。GCMは平文とAADの真正性を保護し、さらに平文の機密性も保護する一方、AADは暗号化されずに残ります。たとえばネットワークプロトコルでは、AADにアドレス、ポート、シーケンス番号、プロトコルのバージョン番号、および平文の取扱方法を示すその他のフィールドが含まれる場合があります。
The IV is essentially a nonce, i.e, a value that is unique within the specified context, which determines an invocation of the authenticated encryption function on the input data to be protected. The uniqueness requirement on the IVs (and keys) is stated precisely in Sec. 8, and two frameworks for constructing IVs are given in Sec. 8.2. Practical considerations in assuring the requirement are discussed in Secs. 9.1 and 9.2. The critical importance of the uniqueness of the IVs is detailed in Ref. [5] and summarized in Appendix A.
IVは基本的にノンス、すなわち保護対象の入力データに対する認証付き暗号化関数の呼び出しを特定する、指定されたコンテキスト内で一意な値です。IV（および鍵）の一意性要件は第8節で厳密に述べられ、IVを構成する2つの枠組みは8.2節に示されます。この要件を実際に確実に満たすための考慮事項は9.1節および9.2節で説明します。IVの一意性が極めて重要であることは文献[5]で詳述され、付録Aで要約されています。
The bit lengths of the input strings to the authenticated encryption function shall meet the following requirements:
認証付き暗号化関数への入力文字列のビット長は、次の要件を満たさなければなりません。
• \(\mathrm{len}(P) \le 2^{39}-256\);
• \(\mathrm{len}(P) \le 2^{39}-256\);
• \(\mathrm{len}(A) \le 2^{64}-1\);
• \(\mathrm{len}(A) \le 2^{64}-1\);
• \(1 \le \mathrm{len}(\mathit{IV}) \le 2^{64}-1\).
• \(1 \le \mathrm{len}(\mathit{IV}) \le 2^{64}-1\).
Although GCM is defined on bit strings, the bit lengths of the plaintext, the AAD, and the IV shall all be multiples of 8, so that these values are byte strings.
GCMはビット文字列上で定義されますが、平文、AAD、IVのビット長はすべて8の倍数でなければならず、これらの値はバイト文字列となります。
An implementation may further restrict the bit lengths of these inputs, consistent with the above requirements; for example, an implementation may establish smaller maximum values. The bit lengths that an implementation allows are called the supported bit lengths. A single set of supported bit lengths for each of the three inputs should be established for the entire implementation, independent of the key.
実装は、上記要件と整合する範囲で、これらの入力のビット長をさらに制限してもよいです。たとえば、より小さい最大値を設定してもよいです。実装が許容するビット長をサポート対象ビット長と呼びます。鍵とは独立に、3つの入力それぞれについて単一のサポート対象ビット長の集合を実装全体で設定するべきです。
For IVs, it is recommended that implementations restrict support to the length of 96 bits, to promote interoperability, efficiency, and simplicity of design.
相互運用性、効率性、設計の単純性を促進するため、実装はIVのサポート対象長を96ビットに制限することが推奨されます。
5.2.1.2 Output Data
5.2.1.2 出力データ
The following two bit strings comprise the output data of the authenticated encryption function:
次の2つのビット文字列が、認証付き暗号化関数の出力データを構成します。
• A ciphertext, denoted \(C\), whose bit length is the same as that of the plaintext.
• 暗号文。\(C\)と表し、そのビット長は平文のビット長と同じです。
• An authentication tag, or tag, for short, denoted \(T\).
• 認証タグ（略してタグ）。\(T\)と表します。
The bit length of the tag, denoted \(t\), is a security parameter, as discussed in Appendix B. In general, \(t\) may be any one of the following five values: 128, 120, 112, 104, or 96. For certain applications, \(t\) may be 64 or 32; guidance for the use of these two tag lengths, including requirements on the length of the input data and the lifetime of the key in these cases, is given in Appendix C.
\(t\)と表すタグのビット長は、付録Bで説明するセキュリティパラメーターです。一般に、\(t\)は次の5つの値のいずれでもよい：128、120、112、104、96。特定の用途では\(t\)を64または32としてもよいです。この2つのタグ長の使用に関するガイダンス（この場合の入力データ長および鍵の有効期間に関する要件を含む）は付録Cに示します。
An implementation shall not support values for \(t\) that are different from the seven choices in the preceding paragraph. An implementation may restrict its support to as few as one of these values. A single, fixed value for \(t\) from among the supported choices shall be associated with each key.
実装は、前段落の7つの選択肢以外の\(t\)の値をサポートしてはなりません。実装は、これらの値のうち1つだけをサポートするよう制限してもよいです。サポート対象の選択肢の中から、単一の固定された\(t\)の値を各鍵に関連付けなければなりません。
5.2.2 Authenticated Decryption Function
5.2.2 認証付き復号関数
Given the selection of an approved block cipher, key, and an associated tag length, the inputs to the authenticated decryption function are values for \(\mathit{IV}\), \(A\), \(C\), and \(T\), as described in Sec. 5.2.1 above. The output is one of the following:
承認済みブロック暗号、鍵、および関連するタグ長を選択した場合、認証付き復号関数への入力は、上記5.2.1節で説明した\(\mathit{IV}\)、\(A\)、\(C\)、\(T\)の値です。出力は次のいずれかです。
• the plaintext \(P\) that corresponds to the ciphertext \(C\), or
• 平文\(P\)。暗号文\(C\)に対応するものです。または
• a special error code, denoted \(\mathit{FAIL}\) in this document.
• 本書で\(\mathit{FAIL}\)と表す特別なエラーコード。
The output \(P\) indicates that \(T\) is the correct authentication tag for \(\mathit{IV}\), \(A\), and \(C\); otherwise, the output is \(\mathit{FAIL}\). The authentication assurance that can be inferred in each case is discussed in Appendix B.
出力\(P\)は、\(T\)が\(\mathit{IV}\)、\(A\)、\(C\)に対する正しい認証タグであることを示します。それ以外の場合、出力は\(\mathit{FAIL}\)です。それぞれの場合に推論できる認証保証については付録Bで説明します。
The values for \(\mathrm{len}(C)\), \(\mathrm{len}(A)\), and \(\mathrm{len}(\mathit{IV})\) that an implementation supports for the authenticated decryption function shall be the same as the values for \(\mathrm{len}(P)\), \(\mathrm{len}(A)\), and \(\mathrm{len}(\mathit{IV})\) that the implementation supports for the authenticated encryption function.
認証付き復号関数について実装がサポートする\(\mathrm{len}(C)\)、\(\mathrm{len}(A)\)、\(\mathrm{len}(\mathit{IV})\)の値は、認証付き暗号化関数について実装がサポートする\(\mathrm{len}(P)\)、\(\mathrm{len}(A)\)、\(\mathrm{len}(\mathit{IV})\)の値と同じでなければなりません。
5.3 Primitives for Confidentiality and Authentication
5.3 機密性と認証のためのプリミティブ
The mechanism for the confidentiality of the plaintext within GCM is a variation of the Counter mode [10], with a particular incrementing function, denoted inc32, for generating the necessary sequence of counter blocks. The first counter block for the plaintext encryption is generated by incrementing a block that is generated from the IV.
GCM における平文の機密性のしくみは、カウンタモード [10] の変形であり、必要なカウンタブロックの列を生成するために、inc32 と表記する特定のインクリメント関数を用います。平文の暗号化に用いる最初のカウンタブロックは、IV から生成されるブロックをインクリメントして生成します。
The authentication mechanism within GCM is based on a hash function, called GHASH1, that features multiplication by a fixed parameter, called the hash subkey, within a binary Galois field.
GCM における認証のしくみは、GHASH1 と呼ばれるハッシュ関数に基づきます。この関数は、二元ガロア体において、ハッシュサブキーと呼ばれる固定パラメータによる乗算を特徴とします。
The hash subkey, denoted \(H\), is generated by applying the block cipher to the “zero” block. The resulting instance of this hash function, denoted \(\mathrm{GHASH}_H\), is used to compress an encoding of the AAD and the ciphertext into a single block, which is then encrypted to produce the authentication tag.
ハッシュサブキーは\(H\)と表し、ブロック暗号を「ゼロ」ブロックに適用して生成します。このハッシュ関数のインスタンスを\(\mathrm{GHASH}_H\)と表し、AADと暗号文の符号化を単一のブロックに圧縮するために用います。このブロックを暗号化して認証タグを生成します。
GHASH is a keyed hash function but not, on its own, a cryptographic hash function. This Recommendation only approves GHASH for use within the context of GCM.
GHASHは鍵付きハッシュ関数ですが、それ単独では暗号学的ハッシュ関数ではありません。本勧告は、GCMのコンテキスト内での使用に限りGHASHを承認します。
The intermediate values in the execution of the GCM functions shall be secret. In particular, this requirement precludes a system in which GCM is implemented using the hash subkey publicly for some other purpose, for example, as an unpredictable value or as an integrity check value on the key.
GCM関数の実行中に得られる中間値は秘密でなければなりません。特にこの要件により、ハッシュサブキーを他の目的（たとえば予測困難な値や鍵の完全性検査値）に公開して使用しながらGCMを実装するシステムは認められません。
6 Mathematical Components of GCM
6 GCMの数学的構成要素
This section presents the mathematical components that appear in the specifications of the authenticated encryption and authenticated decryption functions in Sec. 7 below. Examples of the basic operations and functions on bit strings are given in Sec. 6.1. The incrementing function is defined in Sec. 6.2. Algorithm 1 for “multiplying” blocks is defined in Sec. 6.3. Algorithm 2 for the GHASH function that is constructed from this multiplication is defined in Sec 6.4. Algorithm 3 for the GCTR function is defined in Sec. 6.5.
本節では、以下の第7節にある認証付き暗号化関数および認証付き復号関数の仕様に現れる数学的構成要素を示します。ビット文字列に対する基本演算と関数の例は6.1節に示します。インクリメント関数は6.2節で定義します。ブロックを「乗算」するアルゴリズム1は6.3節で定義します。この乗算から構成されるGHASH関数のアルゴリズム2は6.4節で定義します。GCTR関数のアルゴリズム3は6.5節で定義します。
The specifications of Algorithms 1-3 include the inputs, the outputs, the steps of the algorithm, diagrams, and summaries. Equivalent sets of steps that produce the correct output are permitted. The inputs that are typically fixed across many invocations of the function are called the prerequisites, although they may also be regarded as (varying) inputs.
アルゴリズム1～3の仕様には、入力、出力、アルゴリズムの手順、図、および要約が含まれます。正しい出力を生成する等価な手順の集合を使用してもよいです。関数の複数の呼び出しにわたって通常固定される入力を前提条件と呼びますが、（変化する）入力とみなしてもよいです。
6.1 Examples of Basic Operations and Functions on Strings
6.1 文字列に対する基本演算および関数の例
In this document, the ‘\(\mathtt{0}\)’ bit and the ‘\(\mathtt{1}\)’ bit are indicated in the new courier font to help distinguish them from the integers 0 and 1.
本書では、ビットの「\(\mathtt{0}\)」と「\(\mathtt{1}\)」を整数の0および1と区別しやすくするため、new courierフォントで示します。
Given a real number \(x\), the ceiling function, denoted \(\lceil x \rceil\), is the least integer that is not less than \(x\). For example, \(\lceil 2.1 \rceil = 3\), and \(\lceil 4 \rceil = 4\).
実数\(x\)に対し、\(\lceil x \rceil\)と表す天井関数は、\(x\)以上である最小の整数です。たとえば、\(\lceil 2.1 \rceil = 3\)、\(\lceil 4 \rceil = 4\)です。
Given a positive integer \(s\), \(\mathtt{0}^s\) denotes the string that consists of \(s\) ‘\(\mathtt{0}\)’ bits. For example, \(\mathtt{0}^8 = \mathtt{00000000}\).
正の整数\(s\)に対し、\(\mathtt{0}^s\)は\(s\)個の「\(\mathtt{0}\)」ビットからなる文字列を表します。たとえば、\(\mathtt{0}^8 = \mathtt{00000000}\)です。
The concatenation operation on bit strings is denoted \(\parallel\); for example, \(\mathtt{001} \parallel \mathtt{10111} = \mathtt{00110111}\).
ビット文字列の連結演算は\(\parallel\)と表します。たとえば、\(\mathtt{001} \parallel \mathtt{10111} = \mathtt{00110111}\)です。
Given bit strings of equal length, the exclusive-OR (XOR) operation, denoted \(\oplus\), specifies the addition, modulo 2, of the bits in each bit position, i.e., without carries. For example, \(\mathtt{10011} \oplus \mathtt{10101} = \mathtt{00110}\).
同じ長さのビット文字列に対し、排他的論理和（XOR）演算は\(\oplus\)と表し、各ビット位置のビットの2を法とする加算、すなわち桁上がりを伴わない加算を示します。たとえば、\(\mathtt{10011} \oplus \mathtt{10101} = \mathtt{00110}\)です。
Given a bit string \(X\), the bit length of \(X\) is denoted \(\mathrm{len}(X)\). For example, \(\mathrm{len}(\mathtt{00010}) = 5\).
ビット文字列\(X\)に対し、\(X\)のビット長を\(\mathrm{len}(X)\)と表します。たとえば、\(\mathrm{len}(\mathtt{00010}) = 5\)です。
Given a bit string \(X\) and a non-negative integer \(s\) such that \(\operatorname{len}(X) \ge s\), the functions \(\mathrm{LSB}_s(X)\) and \(\mathrm{MSB}_s(X)\) return the \(s\) least significant (i.e., right-most) bits and the \(s\) most significant (i.e., left-most) bits, respectively, of \(X\). For example, \(\mathrm{LSB}_3(\mathtt{111011010}) = \mathtt{010}\), and \(\mathrm{MSB}_4(\mathtt{111011010}) = \mathtt{1110}\).
ビット列 \(X\) と非負整数 \(s\) が \(\operatorname{len}(X) \ge s\) を満たすとき、関数 \(\mathrm{LSB}_s(X)\) および \(\mathrm{MSB}_s(X)\) は、それぞれ \(s\) 個の最下位（すなわち右端の）ビットおよび \(s\) 個の最上位（すなわち左端の）ビットを \(X\) から返します。たとえば、\(\mathrm{LSB}_3(\mathtt{111011010}) = \mathtt{010}\) であり、\(\mathrm{MSB}_4(\mathtt{111011010}) = \mathtt{1110}\) です。
Given a bit string \(X\), the (single) right-shift function, denoted \(X \mathbin{>>} 1\), is \(\mathrm{MSB}_{\operatorname{len}(X)}(\mathtt{0} \parallel X)\). For example, \(\mathtt{0110111} \mathbin{>>} 1 = \mathtt{0011011}\).
ビット列 \(X\) に対し、（1回の）右シフト関数を \(X \mathbin{>>} 1\) と表し、これは \(\mathrm{MSB}_{\operatorname{len}(X)}(\mathtt{0} \parallel X)\) です。たとえば、\(\mathtt{0110111} \mathbin{>>} 1 = \mathtt{0011011}\) です。
Given a positive integer \(s\) and a non-negative integer \(x\) that is less than \(2^s\), the integer-to-string function, denoted \([x]_s\), is the binary representation of \(x\) as a string of bit length \(s\) with the least significant bit on the right. For example, for the (base 10) integer 39, the binary representation (base 2) is \(\mathtt{100111}\), so \([39]_8=\mathtt{00100111}\).
正整数\(s\)と、\(2^s\)未満の非負整数\(x\)が与えられたとき、\([x]_s\)と表す整数からビット列への変換関数は、最下位ビットを右に置いた、ビット長\(s\)の列による\(x\)の2進表現です。例えば、整数39（10進法）の2進表現は\(\mathtt{100111}\)なので、\([39]_8=\mathtt{00100111}\)となります。
Given a (non-empty) bit string \(X\), the string-to-integer function, denoted \(\operatorname{int}(X)\), is the integer \(x\) such that \([x]_{\operatorname{len}(X)} = X\). In other words, \(\operatorname{int}(X)\) is the non-negative integer less than \(2^{\operatorname{len}(X)}\) whose binary representation is \(X\). For example, \(\operatorname{int}(\mathtt{00011010}) = 26\).
（空でない）ビット列 \(X\) に対し、文字列から整数への関数 \(\operatorname{int}(X)\) は、\(x\) を整数として \([x]_{\operatorname{len}(X)} = X\) を満たすものです。つまり、\(\operatorname{int}(X)\) は \(2^{\operatorname{len}(X)}\) 未満の非負整数で、その2進表現が \(X\) となるものです。たとえば、\(\operatorname{int}(\mathtt{00011010}) = 26\) です。
6.2 Incrementing Function
6.2 インクリメント関数
For a positive integer \(s\) and a bit string \(X\) such that \(\operatorname{len}(X) \ge s\), let the \(s\)-bit incrementing function, denoted \(\operatorname{inc}_s(X)\), be defined as follows:
正の整数 \(s\) とビット列 \(X\) が \(\operatorname{len}(X) \ge s\) を満たすとき、\(s\) ビットのインクリメント関数を \(\operatorname{inc}_s(X)\) と表し、次のように定義します。
In other words, the function increments the right-most \(s\) bits of the string, regarded as the binary representation of an integer, modulo \(2^s\); the remaining, left-most \(\mathrm{len}(X)-s\) bits remain unchanged.
つまり、この関数は文字列の右端\(s\)ビットを整数の2進表現とみなし、\(2^s\)を法としてインクリメントします。残りの左端\(\mathrm{len}(X)-s\)ビットは変更しません。
6.3 Multiplication Operation on Blocks
6.3 ブロックの乗算
Let \(R\) be the bit string \(\mathtt{11100001} \parallel \mathtt{0}^{120}\). Given two blocks \(X\) and \(Y\), Algorithm 1 below computes a “product” block, denoted \(X \bullet Y\):
\(R\)をビット文字列\(\mathtt{11100001} \parallel \mathtt{0}^{120}\)とします。2つのブロック\(X\)および\(Y\)に対し、以下のアルゴリズム1は「積」ブロック（\(X \bullet Y\)と表す）を計算します。
Algorithm 1: \(X\bullet Y\)
アルゴリズム1：\(X\bullet Y\)
Input:
blocks \(X,Y\).
入力：
ブロック\(X,Y\)。
Output:
block \(X\bullet Y\).
出力：
ブロック\(X\bullet Y\)。
Steps:
手順：
1.Let \(x_0x_1\ldots x_{127}\) denote the sequence of bits in \(X\).
1.\(x_0x_1\ldots x_{127}\)を\(X\)のビット列とします。
2.Let \(Z_0=\mathtt{0}^{128}\) and \(V_0=Y\).
2.\(Z_0=\mathtt{0}^{128}\)および\(V_0=Y\)とします。
- For \(i=0\) to 127, calculate blocks \(Z_{i+1}\) and \(V_{i+1}\) as follows:\[Z_{i+1}=\begin{cases}Z_i&\text{if }x_i=0;\\Z_i\oplus V_i&\text{if }x_i=1.\end{cases}\]\[V_{i+1}=\begin{cases}V_i\mathbin{>>}1&\text{if }\operatorname{LSB}_1(V_i)=0;\\(V_i\mathbin{>>}1)\oplus R&\text{if }\operatorname{LSB}_1(V_i)=1.\end{cases}\]
- Return \(Z_{128}\).
- \(i=0\)から127まで、ブロック\(Z_{i+1}\)と\(V_{i+1}\)を次のように計算する：\[Z_{i+1}=\begin{cases}Z_i&\text{条件：}x_i=0;\\Z_i\oplus V_i&\text{条件：}x_i=1.\end{cases}\]\[V_{i+1}=\begin{cases}V_i\mathbin{>>}1&\text{条件：}\operatorname{LSB}_1(V_i)=0;\\(V_i\mathbin{>>}1)\oplus R&\text{条件：}\operatorname{LSB}_1(V_i)=1.\end{cases}\]
- \(Z_{128}\)を返します。
The \(\bullet\) operation on (pairs of) the \(2^{128}\) possible blocks corresponds to the multiplication operation for the binary Galois (finite) field of \(2^{128}\) elements. The fixed block, \(R\), determines a representation of this field as the modular multiplication of binary polynomials of degree less than 128. The convention for interpreting strings as polynomials is “little endian”: i.e., if \(u\) is the variable of the polynomial, then the block \(x_0 x_1 \ldots x_{127}\) corresponds to the polynomial \(x_0 + x_1 u + x_2 u^2 + \ldots + x_{127} u^{127}\). The XOR operation is used to add coefficients of “like” terms during the multiplication. The reduction modulus is the polynomial of degree 128 that corresponds to \(R \parallel 1\). Ref. [6] discusses this field in detail.
\(\bullet\) 演算を \(2^{128}\) 個の可能なブロック（の対）に施すことは、\(2^{128}\) 個の元からなる二元ガロア体（有限体）の乗算に対応します。固定ブロック \(R\) は、この体の表現を、次数が128未満の二元多項式の剰余乗算として定めます。ビット列を多項式として解釈する規約は「リトルエンディアン」です。すなわち、\(u\) を多項式の変数とすると、ブロック \(x_0 x_1 \ldots x_{127}\) は多項式 \(x_0 + x_1 u + x_2 u^2 + \ldots + x_{127} u^{127}\) に対応します。乗算では、「同類」項の係数の加算にXOR演算を用います。還元の法は、\(R \parallel 1\) に対応する次数128の多項式です。文献[6]がこの体を詳しく論じています。
For a positive integer \(i\), the \(i\)th power of a block \(X\) with this multiplication operation is denoted \(X^i\). For example, \(H^2 = H \bullet H\), \(H^3 = H \bullet H \bullet H\), etc.
正の整数\(i\)に対し、この乗算演算による\(i\)乗は、ブロック\(X\)に対して\(X^i\)と表します。たとえば、\(H^2 = H \bullet H\)、\(H^3 = H \bullet H \bullet H\)などです。
6.4 GHASH Function
6.4 GHASH関数
Algorithm 2 below specifies the GHASH function:
以下のアルゴリズム2はGHASH関数を規定します。
Algorithm 2: \(\mathrm{GHASH}_H(X)\)
Prerequisites:
block \(H\), the hash subkey.
Input:
bit string \(X\) such that \(\operatorname{len}(X) = 128m\) for some positive integer \(m\).
Output:
block \(\mathrm{GHASH}_H(X)\).
Steps:
1. Let \(X_1, X_2, \ldots, X_{m-1}, X_m\) denote the unique sequence of blocks such that \(X = X_1 \parallel X_2 \parallel \ldots \parallel X_{m-1} \parallel X_m\).
2. Let \(Y_0\) be the “zero block,” \(\mathtt{0}^{128}\).
3. For \(i = 1, \ldots, m\), let \(Y_i = (Y_{i-1} \oplus X_i) \bullet H\).
4. Return \(Y_m\).
アルゴリズム2：\(\mathrm{GHASH}_H(X)\)
前提条件：
ハッシュサブキーであるブロック \(H\)。
入力：
ビット列 \(X\)。ただし、\(\operatorname{len}(X) = 128m\) となる正の整数 \(m\) が存在するもの。
出力：
ブロック \(\mathrm{GHASH}_H(X)\)。
手順：
1. \(X_1, X_2, \ldots, X_{m-1}, X_m\) を、\(X = X_1 \parallel X_2 \parallel \ldots \parallel X_{m-1} \parallel X_m\) となる一意なブロック列とします。
2. \(Y_0\) を「ゼロブロック」\(\mathtt{0}^{128}\) とします。
3. \(i = 1, \ldots, m\) について、\(Y_i = (Y_{i-1} \oplus X_i) \bullet H\) とします。
4. \(Y_m\) を返します。
In effect, the GHASH function calculates \(X_1 \bullet H^m \oplus X_2 \bullet H^{m-1} \oplus \ldots \oplus X_{m-1} \bullet H^2 \oplus X_m \bullet H\). Ref. [6] describes methods for optimizing implementations of GHASH in both hardware and software.
GHASH関数は実質的に \(X_1 \bullet H^m \oplus X_2 \bullet H^{m-1} \oplus \ldots \oplus X_{m-1} \bullet H^2 \oplus X_m \bullet H\) を計算します。文献[6]は、ハードウェアとソフトウェアの両方におけるGHASHの実装を最適化する方法を記述しています。
GHASHの処理図。最初の入力ブロックX1にHを乗じてY1を得る。以後、前段の出力と次の入力ブロックの排他的論理和にHを乗じ、最後の出力Ymを得る。
Figure 1: \(\mathrm{GHASH}_H(X_1 \parallel X_2 \parallel \ldots \parallel X_m) = Y_m\).
図1：\(\mathrm{GHASH}_H(X_1 \parallel X_2 \parallel \ldots \parallel X_m) = Y_m\)。
6.5 GCTR Function
6.5 GCTR関数
Algorithm 3 below specifies the GCTR function. The suggested notation does not indicate the choice of the underlying block cipher.
以下のアルゴリズム3はGCTR関数を規定します。ここで示す表記は、基礎となるブロック暗号の選択を示すものではありません。
Algorithm 3: \(\operatorname{GCTR}_K(\mathit{ICB},X)\)
アルゴリズム3：\(\operatorname{GCTR}_K(\mathit{ICB},X)\)
Prerequisites:
approved block cipher CIPH with a 128-bit block size; key \(K\).
事前条件：
ブロックサイズが128ビットの承認済みブロック暗号CIPH；鍵\(K\)。
Input:
initial counter block \(\mathit{ICB}\);
bit string \(X\), of arbitrary length.
入力：
初期カウンターブロック\(\mathit{ICB}\)；
任意の長さのビット列\(X\)。
Output:
bit string \(Y\) of bit length \(\operatorname{len}(X)\).
出力：
ビット長\(\operatorname{len}(X)\)のビット列\(Y\)。
Steps:
手順：
1.If \(X\) is the empty string, then return the empty string as \(Y\).
1.\(X\)が空列なら、空列を\(Y\)として返します。
2.Let \(n=\left\lceil\frac{\operatorname{len}(X)}{128}\right\rceil\).
2.\(n=\left\lceil\frac{\operatorname{len}(X)}{128}\right\rceil\)とします。
3.Let \(X_1,X_2,\ldots,X_{n-1},X_n^*\) denote the unique sequence of bit strings such that \[X=X_1\parallel X_2\parallel\ldots\parallel X_{n-1}\parallel X_n^*;\] \(X_1,X_2,\ldots,X_{n-1}\) are complete blocks.2
3.\(X_1,X_2,\ldots,X_{n-1},X_n^*\)を、\[X=X_1\parallel X_2\parallel\ldots\parallel X_{n-1}\parallel X_n^*;\]となる一意なビット列の系列とします。\(X_1,X_2,\ldots,X_{n-1}\)は完全なブロックです。2
4.Let \(\mathit{CB}_1=\mathit{ICB}\).
4.\(\mathit{CB}_1=\mathit{ICB}\)とします。
5.For \(i=2\) to \(n\), let \(\mathit{CB}_i=\operatorname{inc}_{32}(\mathit{CB}_{i-1})\).
5.\(i=2\)から\(n\)まで、\(\mathit{CB}_i=\operatorname{inc}_{32}(\mathit{CB}_{i-1})\)とします。
6.For \(i=1\) to \(n-1\), let \(Y_i=X_i\oplus\operatorname{CIPH}_K(\mathit{CB}_i)\).
6.\(i=1\)から\(n-1\)まで、\(Y_i=X_i\oplus\operatorname{CIPH}_K(\mathit{CB}_i)\)とします。
- Let:\[Y_n^*=X_n^*\oplus\operatorname{MSB}_{\operatorname{len}(X_n^*)}(\operatorname{CIPH}_K(\mathit{CB}_n)).\]
- Let \(Y=Y_1\parallel Y_2\parallel\ldots\parallel Y_n^*\).
- Return \(Y\).
- 次のとおりとする：\[Y_n^*=X_n^*\oplus\operatorname{MSB}_{\operatorname{len}(X_n^*)}(\operatorname{CIPH}_K(\mathit{CB}_n)).\]
- \(Y=Y_1\parallel Y_2\parallel\ldots\parallel Y_n^*\)とします。
- \(Y\)を返します。
2 Consequently, \(X_n^*\) is either a complete block or a nonempty partial block, and if \(1 \le \operatorname{len}(X) \le 128\), then \(X = X_1^*\).
2 したがって、\(X_n^*\) は完全なブロックまたは空でない部分ブロックのいずれかであり、\(1 \le \operatorname{len}(X) \le 128\) の場合、\(X = X_1^*\) です。
In Steps 1 and 2, the input string of arbitrary length is partitioned into a sequence of blocks to the greatest extent possible, so that only the rightmost string in the sequence may be a “partial” block. In Steps 3 and 4, the 32-bit incrementing function is iterated on the initial counter block input to generate a sequence of counter blocks; the input block is the first block of the sequence. In Steps 5 and 6, the block cipher is applied to the counter blocks and the results are XORed with the corresponding blocks (or partial block) of the partition of the input string. In Step 7, the sequence of results is concatenated to form the output.
ステップ1および2では、任意の長さの入力文字列を可能な限りブロック列に分割します。そのため、列の最右端の文字列だけが「部分」ブロックとなる場合があります。ステップ3および4では、初期カウンターブロック入力に対して32ビットインクリメント関数を反復適用し、カウンターブロック列を生成します。入力ブロックはこの列の最初のブロックです。ステップ5および6では、ブロック暗号をカウンターブロックに適用し、その結果を入力文字列の分割で得た対応するブロック（または部分ブロック）とXORします。ステップ7では、結果の列を連結して出力を形成します。
Figure 2 below illustrates the GCTR function.
以下の図2はGCTR関数を示します。
図2：GCTR_K(ICB, X_1 || X_2 || ... || X_n*) = Y_1 || Y_2 || ... || Y_n*。上段にカウンタブロックの連鎖があり、ICB から inc へ、inc から CB_2 へ、そこから省略記号へ、さらに CB_(n-1) へ、inc へ、CB_n へと矢印が続く。各カウンタブロック（ICB、CB_2、CB_(n-1)、CB_n）から下の CIPH_K の箱へ矢印が延び、その出力が入力ブロック X_1、X_2、X_(n-1)、X_n* とそれぞれ排他的論理和（⊕）をとられ、出力ブロック Y_1、Y_2、Y_(n-1)、Y_n* となる。最後のブロックでは、CIPH_K の下の波括弧が出力の一部だけを使うことを示している。中間の省略されたブロックは省略記号で示されている。
Figure 2: \(\mathrm{GCTR}_K(\mathit{ICB}, X_1 \parallel X_2 \parallel \ldots \parallel X_n^*) = Y_1 \parallel Y_2 \parallel \ldots \parallel Y_n^*\).
図2：\(\mathrm{GCTR}_K(\mathit{ICB}, X_1 \parallel X_2 \parallel \ldots \parallel X_n^*) = Y_1 \parallel Y_2 \parallel \ldots \parallel Y_n^*\)。
7 GCM Specification
7 GCMの仕様
Algorithms 4 and 5 for the authenticated encryption and authenticated decryption functions of GCM are specified in Secs. 7.1 and 7.2 below. The specifications include the inputs, the outputs, the steps of the algorithm, diagrams, and summaries. The suggested notation does not indicate the choice of the underlying block cipher. The inputs that are typically fixed across many invocations of the function are called the prerequisites; however, some of the prerequisites may also be regarded as (varying) input. The prerequisites and the other inputs shall meet the requirements in Sec. 5.
GCMの認証付き暗号化関数および認証付き復号関数のアルゴリズム4および5は、以下の7.1節および7.2節に規定します。各仕様には、入力、出力、アルゴリズムの手順、図、および要約が含まれます。推奨表記法は、基礎となるブロック暗号の選択を示すものではありません。関数の複数回の呼び出しにわたって通常固定される入力を前提条件と呼びます。ただし、一部の前提条件は（変化する）入力とみなしてもよいです。前提条件およびその他の入力は、第5節の要件を満たさなければなりません。
For both algorithms, equivalent sets of steps that produce the correct output are permitted. For example, in Algorithm 5, the verification of the tag may precede the computation of the plaintext.
両アルゴリズムとも、正しい出力を生成する等価な手順の集合を使用してもよいです。たとえば、アルゴリズム5では、タグの検証を平文の計算より先に行ってもよいです。
7.1 Algorithm for the Authenticated Encryption Function
7.1 認証付き暗号化関数のアルゴリズム
Algorithm 4 below specifies the authenticated encryption function:
以下のアルゴリズム4は認証付き暗号化関数を規定します。
Algorithm 4: \(\mathrm{GCM\text{-}AE}_K(\mathit{IV}, P, A)\)
Prerequisites:
approved block cipher CIPH with a 128-bit block size;
key \(K\);
definitions of supported input-output lengths;
supported tag length \(t\) associated with the key.
Input:
initialization vector \(\mathit{IV}\) (whose length is supported);
plaintext \(P\) (whose length is supported);
additional authenticated data \(A\) (whose length is supported).
Output:
ciphertext \(C\);
authentication tag \(T\).
Steps:
1. Let \(H = \mathrm{CIPH}_K(\mathtt{0}^{128})\).
2. Define a block, \(J_0\), as follows:
If \(\operatorname{len}(\mathit{IV}) = 96\), then let \(J_0 = \mathit{IV} \parallel \mathtt{0}^{31} \parallel \mathtt{1}\).
If \(\operatorname{len}(\mathit{IV}) \ne 96\), then let \(s = 128 \lceil \operatorname{len}(\mathit{IV})/128 \rceil - \operatorname{len}(\mathit{IV})\), and let \(J_0 = \mathrm{GHASH}_H(\mathit{IV} \parallel \mathtt{0}^{s+64} \parallel [\operatorname{len}(\mathit{IV})]_{64})\).
3. Let \(C = \mathrm{GCTR}_K(\operatorname{inc}_{32}(J_0), P)\).
4. Let \(u = 128 \cdot \lceil \operatorname{len}(C)/128 \rceil - \operatorname{len}(C)\) and let \(v = 128 \cdot \lceil \operatorname{len}(A)/128 \rceil - \operatorname{len}(A)\).
5. Define a block, \(S\), as follows:
\(S = \mathrm{GHASH}_H(A \parallel \mathtt{0}^v \parallel C \parallel \mathtt{0}^u \parallel [\operatorname{len}(A)]_{64} \parallel [\operatorname{len}(C)]_{64})\).
6. Let \(T = \mathrm{MSB}_t(\mathrm{GCTR}_K(J_0, S))\).
7. Return \((C, T)\).
アルゴリズム4：\(\mathrm{GCM\text{-}AE}_K(\mathit{IV}, P, A)\)
前提条件：
ブロックサイズが128ビットの承認されたブロック暗号CIPH、
鍵 \(K\)、
サポートする入出力長の定義、
鍵に関連付けられた、サポートするタグ長 \(t\)。
入力：
初期化ベクトル \(\mathit{IV}\)（その長さがサポートされているもの）、
平文 \(P\)（その長さがサポートされているもの）、
追加認証データ \(A\)（その長さがサポートされているもの）。
出力：
暗号文 \(C\)、
認証タグ \(T\)。
手順：
1. \(H = \mathrm{CIPH}_K(\mathtt{0}^{128})\) とします。
2. ブロック \(J_0\) を次のように定義します。
\(\operatorname{len}(\mathit{IV}) = 96\) の場合、\(J_0 = \mathit{IV} \parallel \mathtt{0}^{31} \parallel \mathtt{1}\) とします。
\(\operatorname{len}(\mathit{IV}) \ne 96\) の場合、\(s = 128 \lceil \operatorname{len}(\mathit{IV})/128 \rceil - \operatorname{len}(\mathit{IV})\) とし、\(J_0 = \mathrm{GHASH}_H(\mathit{IV} \parallel \mathtt{0}^{s+64} \parallel [\operatorname{len}(\mathit{IV})]_{64})\) とします。
3. \(C = \mathrm{GCTR}_K(\operatorname{inc}_{32}(J_0), P)\) とします。
4. \(u = 128 \cdot \lceil \operatorname{len}(C)/128 \rceil - \operatorname{len}(C)\) とし、\(v = 128 \cdot \lceil \operatorname{len}(A)/128 \rceil - \operatorname{len}(A)\) とします。
5. ブロック \(S\) を次のように定義します。
\(S = \mathrm{GHASH}_H(A \parallel \mathtt{0}^v \parallel C \parallel \mathtt{0}^u \parallel [\operatorname{len}(A)]_{64} \parallel [\operatorname{len}(C)]_{64})\)。
6. \(T = \mathrm{MSB}_t(\mathrm{GCTR}_K(J_0, S))\) とします。
7. \((C, T)\) を返します。
In Step 1, the hash subkey for the GHASH function is generated by applying the block cipher to the “zero” block. In Step 2, the pre-counter block (\(J_0\)) is generated from the IV. In particular, when the length of the IV is 96 bits, then the padding string \(\mathtt{0}^{31} \parallel \mathtt{1}\) is appended to the IV to form the pre-counter block. Otherwise, the IV is padded with the minimum number of ‘0’ bits, possibly none, so that the length of the resulting string is a multiple of 128 bits (the block size); this string in turn is appended with 64 additional ‘0’ bits, followed by the 64-bit representation of the length of the IV, and the GHASH function is applied to the resulting string to form the pre-counter block. In Step 3, the 32-bit incrementing function is applied to the pre-counter block to produce the initial counter block for an invocation of the GCTR function on the plaintext. The output of this invocation of the GCTR function is the ciphertext.
ステップ1では、「ゼロ」ブロックにブロック暗号を適用してGHASH関数用のハッシュサブキーを生成します。ステップ2では、IVからプリカウンターブロック（\(J_0\)）を生成します。特に、IVの長さが96ビットの場合は、パディング文字列\(\mathtt{0}^{31} \parallel \mathtt{1}\)をIVに付加してプリカウンターブロックを形成します。それ以外の場合は、結果の文字列の長さが128ビット（ブロックサイズ）の倍数となるように、必要最小限の個数（0個の場合もある）の「0」ビットをIVに付加します。次に、この文字列に64個の追加の「0」ビットを付加し、その後にIVの長さの64ビット表現を付加します。結果の文字列にGHASH関数を適用してプリカウンターブロックを形成します。ステップ3では、プリカウンターブロックに32ビットインクリメント関数を適用して、平文に対するGCTR関数呼び出し用の初期カウンターブロックを生成します。このGCTR関数呼び出しの出力が暗号文です。
In Steps 4 and 5, the AAD and the ciphertext are each appended with the minimum number of ‘0’ bits, possibly none, so that the bit lengths of the resulting strings are multiples of the block size. The concatenation of these strings is appended with the 64-bit representations of the lengths of the AAD and the ciphertext, and the GHASH function is applied to the result to produce a single output block. In Step 6, this output block is encrypted using the GCTR function with the pre-counter block that was generated in Step 2, and the result is truncated to the specified tag length to form the authentication tag. The ciphertext and the tag are returned as the output in Step 7.
ステップ4および5では、AADと暗号文それぞれに、結果の文字列のビット長がブロックサイズの倍数となるよう必要最小限の「0」ビット（場合によっては追加なし）を付加します。これらの文字列を連結し、AADと暗号文の長さを64ビットで表した値を付加して、結果にGHASH関数を適用し、単一の出力ブロックを生成します。ステップ6では、ステップ2で生成したプリカウンターブロックを用いてGCTR関数でこの出力ブロックを暗号化し、結果を指定されたタグ長に切り詰めて認証タグを形成します。ステップ7では、暗号文とタグを出力として返します。
![Figure 3: GCM-AE_K(IV, P, A) = (C, T). IV has a dotted arrow down to J_0. J_0 has an arrow to inc_32, which has an arrow to GCTR_K; P also has an arrow down into this GCTR_K, whose output is C. Below, a row of blocks A, 0^v, C, 0^u, [len(A)]_64 and [len(C)]_64 is joined by a brace with an arrow down to GHASH_H. On the right, 0^128 has an arrow to CIPH_K, which has an arrow to H; H has an arrow into GHASH_H. GHASH_H has an arrow to a second GCTR_K, which also receives a line from J_0 running around the left side. This GCTR_K has an arrow to MSB_t, which has an arrow to T. The inputs IV, P and A are drawn with thick borders.](assets/38d/p0024-figure-01.png)
図3：GCM-AE_K(IV, P, A) = (C, T)。IV から J_0 へ点線の矢印が延びる。J_0 から inc_32 へ、inc_32 から GCTR_K へ矢印が延び、P からもこの GCTR_K へ矢印が下りて、その出力が C となる。その下に、A、0^v、C、0^u、[len(A)]_64、[len(C)]_64 のブロックが並び、波括弧でまとめられて GHASH_H へ矢印が下りる。右側では 0^128 から CIPH_K へ、CIPH_K から H へ矢印が延び、H から GHASH_H へ矢印が入る。GHASH_H から 2 つ目の GCTR_K へ矢印が延び、この GCTR_K には J_0 から左側を回る線も入る。この GCTR_K から MSB_t へ、MSB_t から T へ矢印が延びる。入力の IV、P、A は太枠で描かれている。
Figure 3: \(\mathrm{GCM\text{-}AE}_K(\mathit{IV}, P, A) = (C, T)\).
図3：\(\mathrm{GCM\text{-}AE}_K(\mathit{IV}, P, A) = (C, T)\)。
The authenticated encryption function is illustrated in Figure 3 above. The determination of J0 from IV (Step 2) is not depicted.
認証付き暗号化関数を上の図3に示します。IVからのJ0の決定（ステップ2）は図示していません。
7.2 Algorithm for the Authenticated Decryption Function
7.2 認証付き復号関数のアルゴリズム
Algorithm 5 below specifies the authenticated decryption function:
以下のアルゴリズム5は認証付き復号関数を規定します。
Algorithm 5: \(\mathrm{GCM\text{-}AD}_K(\mathit{IV}, C, A, T)\)
Prerequisites:
approved block cipher CIPH with a 128-bit block size;
key \(K\);
definitions of supported input-output lengths;
supported tag length \(t\) associated with the key.
Input:
initialization vector \(\mathit{IV}\);
ciphertext \(C\);
additional authenticated data \(A\);
authentication tag \(T\).
Output:
plaintext \(P\) or indication of inauthenticity \(\mathit{FAIL}\).
Steps:
1. If the bit lengths of \(\mathit{IV}\), \(A\) or \(C\) are not supported, or if \(\operatorname{len}(T) \ne t\), then return FAIL.
2. Let \(H = \mathrm{CIPH}_K(\mathtt{0}^{128})\).
3. Define a block, \(J_0\), as follows:
If \(\operatorname{len}(\mathit{IV}) = 96\), then \(J_0 = \mathit{IV} \parallel \mathtt{0}^{31} \parallel \mathtt{1}\).
If \(\operatorname{len}(\mathit{IV}) \ne 96\), then let \(s = 128 \lceil \operatorname{len}(\mathit{IV})/128 \rceil - \operatorname{len}(\mathit{IV})\), and \(J_0 = \mathrm{GHASH}_H(\mathit{IV} \parallel \mathtt{0}^{s+64} \parallel [\operatorname{len}(\mathit{IV})]_{64})\).
4. Let \(P = \mathrm{GCTR}_K(\operatorname{inc}_{32}(J_0), C)\).
5. Let \(u = 128 \cdot \lceil \operatorname{len}(C)/128 \rceil - \operatorname{len}(C)\) and let \(v = 128 \cdot \lceil \operatorname{len}(A)/128 \rceil - \operatorname{len}(A)\).
6. Define a block, \(S\), as follows:
\(S = \mathrm{GHASH}_H(A \parallel \mathtt{0}^v \parallel C \parallel \mathtt{0}^u \parallel [\operatorname{len}(A)]_{64} \parallel [\operatorname{len}(C)]_{64})\)
7. Let \(T' = \mathrm{MSB}_t(\mathrm{GCTR}_K(J_0, S))\).
8. If \(T = T'\), then return \(P\); else return \(\mathit{FAIL}\).
アルゴリズム 5：\(\mathrm{GCM\text{-}AD}_K(\mathit{IV}, C, A, T)\)
前提条件：
ブロックサイズが 128 ビットの承認済みブロック暗号 CIPH、
鍵 \(K\)、
サポートされる入出力長の定義、
鍵に関連付けられた、サポートされるタグ長 \(t\)。
入力：
初期化ベクトル \(\mathit{IV}\)、
暗号文 \(C\)、
追加認証データ \(A\)、
認証タグ \(T\)。
出力：
平文 \(P\)、または真正でないことを示す \(\mathit{FAIL}\)。
手順：
1. \(\mathit{IV}\)、\(A\)、\(C\) のビット長がサポートされていない場合、または \(\operatorname{len}(T) \ne t\) の場合は、FAIL を返します。
2. \(H = \mathrm{CIPH}_K(\mathtt{0}^{128})\) とします。
3. ブロック \(J_0\) を次のように定義します。
\(\operatorname{len}(\mathit{IV}) = 96\) の場合、\(J_0 = \mathit{IV} \parallel \mathtt{0}^{31} \parallel \mathtt{1}\) とします。
\(\operatorname{len}(\mathit{IV}) \ne 96\) の場合、\(s = 128 \lceil \operatorname{len}(\mathit{IV})/128 \rceil - \operatorname{len}(\mathit{IV})\) とし、\(J_0 = \mathrm{GHASH}_H(\mathit{IV} \parallel \mathtt{0}^{s+64} \parallel [\operatorname{len}(\mathit{IV})]_{64})\) とします。
4. \(P = \mathrm{GCTR}_K(\operatorname{inc}_{32}(J_0), C)\) とします。
5. \(u = 128 \cdot \lceil \operatorname{len}(C)/128 \rceil - \operatorname{len}(C)\)、\(v = 128 \cdot \lceil \operatorname{len}(A)/128 \rceil - \operatorname{len}(A)\) とします。
6. ブロック \(S\) を次のように定義します。
\(S = \mathrm{GHASH}_H(A \parallel \mathtt{0}^v \parallel C \parallel \mathtt{0}^u \parallel [\operatorname{len}(A)]_{64} \parallel [\operatorname{len}(C)]_{64})\)
7. \(T' = \mathrm{MSB}_t(\mathrm{GCTR}_K(J_0, S))\) とします。
8. \(T = T'\) ならば \(P\) を返し、そうでなければ \(\mathit{FAIL}\) を返します。
In Step 1, the implementation’s support for the lengths of the IV, the ciphertext, the AAD, and the authentication tag is verified. In Step 2, the hash subkey for the GHASH function is generated by applying the block cipher to the “zero” block. In Step 3, the pre-counter block (J0) is formed as for the authenticated encryption function (Step 2 of Section 7.1). In Step 4, the 32-bit incrementing function is applied to the pre-counter block to produce the initial counter block for an invocation of the GCTR function on the ciphertext. The output of this invocation of the GCTR function is the plaintext that corresponds to the ciphertext for the given IV.
ステップ1では、IV、暗号文、AADおよび認証タグの長さについて実装がサポートする値を検証します。ステップ2では、「ゼロ」ブロックにブロック暗号を適用してGHASH関数用のハッシュ部分鍵を生成します。ステップ3では、プリカウンターブロック（J0）を認証付き暗号化関数の場合と同様に形成します（7.1節のステップ2）。ステップ4では、プリカウンターブロックに32ビットインクリメント関数を適用して、暗号文に対するGCTR関数呼び出し用の初期カウンターブロックを生成します。このGCTR呼び出しの出力が、指定されたIVに対応する暗号文の平文です。
In Steps 5 and 6, the AAD and the ciphertext are each appended with the minimum number of ‘\(\mathtt{0}\)’ bits, possibly none, so that the bit lengths of the resulting strings are multiples of the block size. The concatenation of these strings is appended with 64-bit representations of the lengths of the AAD and the ciphertext, and the GHASH function is applied to the result to produce a single output block. In Step 7, this output block is encrypted using the GCTR function with the pre-counter block that was generated in Step 3, and the result is truncated to the specified tag length to form the authentication tag. In Step 8, the result of Step 7 is compared with the authentication tag that was received as an input: if they are identical, then the plaintext is returned; otherwise, \(\mathit{FAIL}\) is returned.
ステップ5および6では、AADと暗号文のそれぞれに、結果の文字列のビット長がブロックサイズの倍数となるよう、必要最小限の個数（0個の場合もある）の「\(\mathtt{0}\)」ビットを付加します。これらの文字列の連結に、AADと暗号文の長さの64ビット表現を付加し、その結果にGHASH関数を適用して単一の出力ブロックを生成します。ステップ7では、ステップ3で生成したプリカウンターブロックを用いてGCTR関数でこの出力ブロックを暗号化し、結果を指定されたタグ長に切り詰めて認証タグを形成します。ステップ8では、ステップ7の結果を、入力として受け取った認証タグと比較します。両者が一致する場合は平文を返し、そうでない場合は\(\mathit{FAIL}\)を返します。
Equivalent sets of steps that produce the correct output are permitted. In particular, the verification of the tag may precede the computation of the plaintext.
正しい出力を生成する等価な手順の集合を使用してもよいです。特に、タグの検証を平文の計算より先に行ってもよいです。
The authenticated decryption function is illustrated in Figure 4 below. The determination of J0 from IV (Step 3) is not depicted.
認証付き復号関数を以下の図4に示します。IVからのJ0の決定（ステップ3）は図示していません。
![Figure 4: GCM-AD_K(IV, C, A, T) = P or FAIL. IV has a dotted arrow down to J_0. J_0 has an arrow to inc_32, which has an arrow to GCTR_K; C has an arrow up into this GCTR_K, whose output goes up to P. A row of blocks A, 0^v, C, 0^u, [len(A)]_64 and [len(C)]_64 is joined by a brace with an arrow down to GHASH_H. On the right, 0^128 has an arrow to CIPH_K, which has an arrow to H; H has an arrow into GHASH_H. GHASH_H has an arrow to a second GCTR_K, which also receives a line from J_0 running around the left side. This GCTR_K has an arrow to MSB_t, which has an arrow to T′. T and T′ both have arrows into a box "if ≠", which has an arrow to FAIL. The inputs IV, A, C and T are drawn with thick borders.](assets/38d/p0026-figure-01.png)
図4：GCM-AD_K(IV, C, A, T) = P または FAIL。IV から J_0 へ点線の矢印が延びる。J_0 から inc_32 へ、inc_32 から GCTR_K へ矢印が延び、C からこの GCTR_K へ矢印が上がり、その出力が上の P へ向かう。A、0^v、C、0^u、[len(A)]_64、[len(C)]_64 のブロックの並びが波括弧でまとめられて GHASH_H へ矢印が下りる。右側では 0^128 から CIPH_K へ、CIPH_K から H へ矢印が延び、H から GHASH_H へ矢印が入る。GHASH_H から 2 つ目の GCTR_K へ矢印が延び、この GCTR_K には J_0 から左側を回る線も入る。この GCTR_K から MSB_t へ、MSB_t から T′ へ矢印が延びる。T と T′ からそれぞれ「if ≠」の箱へ矢印が入り、そこから FAIL へ矢印が延びる。入力の IV、A、C、T は太枠で描かれている。
Figure 4: \(\mathrm{GCM\text{-}AD}_K(\mathit{IV}, C, A, T) = P\) or \(\mathit{FAIL}\).
図4：\(\mathrm{GCM\text{-}AD}_K(\mathit{IV}, C, A, T) = P\)または\(\mathit{FAIL}\)。
8 Uniqueness Requirement on IVs and Keys
8 IVおよび鍵に関する一意性要件
The IVs in GCM must fulfill the following “uniqueness” requirement:
GCMのIVは、次の「一意性」要件を満たさなければなりません。
The probability that the authenticated encryption function ever will be invoked with the same IV and the same key on two (or more) distinct sets of input data shall be no greater than \(2^{-32}\).
認証付き暗号化関数が、2つ（またはそれ以上）の異なる入力データ集合に対して同じIVと同じ鍵で呼び出される確率は、\(2^{-32}\)以下でなければなりません。
Compliance with this requirement is crucial to the security of GCM. Across all instances of the authenticated encryption function with a given key, if even one IV is ever repeated, then the implementation may be vulnerable to the forgery attacks that are described in Ref [5] and summarized in Appendix A. In practice, this requirement is almost as important as the secrecy of the key.
この要件への適合は、GCMのセキュリティにとって極めて重要です。所与の鍵を用いる認証付き暗号化関数のすべてのインスタンスを通じて、IVがたとえ一度でも再使用された場合、実装は文献[5]で説明され、付録Aに要約されている偽造攻撃に対して脆弱となる可能性があります。実際、この要件は鍵の秘密性とほぼ同じくらい重要です。
The role of key establishment in supporting this requirement is discussed in Sec. 8.1. The two allowed IV constructions for satisfying this requirement are given in Sec. 8.2. Constraints on the number of invocations of the authenticated encryption function are given in Sec. 8.3.
この要件を満たすうえでの鍵確立の役割は8.1節で説明します。この要件を満たすために許可される二つのIV構成方法は8.2節に示します。認証付き暗号化関数の呼び出し回数に関する制約は8.3節に示します。
8.1 Key Establishment
8.1 鍵確立
The following requirement, which is the norm for secret key cryptographic algorithms in general, takes on explicit importance for GCM to support the uniqueness requirement in Sec. 8:
一般に秘密鍵暗号アルゴリズムの標準である次の要件は、8節の一意性要件を支えるため、GCMにおいて明確な重要性を持ちます。
Any GCM key that is established among its intended users shall, with high probability, be fresh.
意図された利用者間で確立されるGCM鍵は、高い確率で新鮮でなければなりません。
In practice, the requirements in Sec. 5.1 should ensure that a key is fresh when it is generated, if the generation mechanism is resistant to tampering. Achieving such resistance usually imposes requirements on the management of the key generation mechanism.
実際、5.1節の要件により、鍵生成機構が改ざんに耐性を持つ場合、鍵の生成時にその鍵が新鮮であることが確保されるはずです。このような耐性を実現するには通常、鍵生成機構の管理に関する要件が課されます。
In particular, if the key generation mechanism is deterministic, then the management of the mechanism shall provide strong assurance that no outside entity can induce the repetition of a previous set of inputs to the mechanism, or otherwise cause the repetition of a previous output. For example, GCM keys may be established using the key derivation functions of the following protocols as allowed in [9]: Transport Layer Security, Internet Key Exchange v1 and v2, and Secure Shell.
特に、鍵生成機構が決定論的である場合、その機構の管理により、外部主体が機構への過去の入力一式を再度与えたり、その他の方法で過去の出力を再現させたりできないことを強く保証しなければなりません。たとえば、[9]で許可されている次のプロトコルの鍵導出関数を用いてGCM鍵を確立してもよい：Transport Layer Security、Internet Key Exchange v1およびv2、Secure Shell。
Similarly, if a new key must be transported to its intended recipient(s), the method of transport/distribution shall provide strong assurance against “replay,” so that no party can induce the substitution of a previous key for the intended key.
同様に、新しい鍵を意図された受信者へ転送しなければならない場合、その転送／配布方法は「リプレイ」に対する強い保証を提供し、いかなる当事者も意図された鍵を以前の鍵に置き換えられないようにしなければなりません。
GCM keys should be established within the framework of an approved key management structure to assure their freshness, as well as their confidentiality and authenticity; the details of such structures are outside the scope of this Recommendation.
鍵の新鮮性ならびに機密性および真正性を確保するため、GCM鍵は承認済みの鍵管理構造の枠組み内で確立するべきです。このような構造の詳細は本勧告の適用範囲外です。
8.2 IV Constructions
8.2 IVの構成
This Recommendation provides two frameworks for constructing IVs. The first construction, described in Sec. 8.2.1, relies on deterministic elements to achieve the uniqueness requirement in Sec. 8; the second construction, described in Sec. 8.2.2, relies on a sufficiently long output string from an approved RBG with a sufficient security strength.
本勧告は、IVを構成するための二つの枠組みを示します。8.2.1節で説明する最初の構成方法は、8節の一意性要件を満たすために決定論的要素に依存します。8.2.2節で説明する二番目の構成方法は、十分なセキュリティ強度を持つ承認済みRBGからの十分に長い出力文字列に依存します。
For any supported IV length that is strictly less than 96 bits, the construction in Sec. 8.2.1, shall be used, across all instances of the authenticated encryption function with the given key.
96ビット未満のサポート対象IV長については、所与の鍵を用いる認証付き暗号化関数のすべてのインスタンスで、8.2.1節の構成方法を使用しなければなりません。
For any supported IV length that is 96 bits or greater, exactly one of the constructions, but not both, shall be used, across all instances of the authenticated encryption function with the given key.
96ビット以上のサポート対象IV長については、所与の鍵を用いる認証付き暗号化関数のすべてのインスタンスで、二つの構成方法のうち一方のみを使用し、両方を使用してはなりません。
For example, suppose that an implementation supports IV lengths of 64 bits, 96 bits, 128 bits, and 160 bits. For 64-bit IVs the only choice is the construction in Sec. 8.2.1. For the other three IV lengths, one possible combination of choices is the construction in Sec. 8.2.1 for 96-bit IVs and the construction in Sec. 8.2.2 for 128-bit and 160-bit IVs.
たとえば、実装が64ビット、96ビット、128ビット、160ビットのIV長をサポートするとします。64ビットIVについて選択できるのは8.2.1節の構成方法のみです。残る三つのIV長に対する選択の組み合わせの例として、8.2.1節の構成方法を96ビットIVに、8.2.2節の構成方法を128ビットおよび160ビットIVに用いることができます。
8.2.1 Deterministic Construction
8.2.1 決定論的構成方法
In the deterministic construction, the IV is the concatenation of two fields, called the fixed field and the invocation field. The fixed field shall identify the device, or, more generally, the context for the instance of the authenticated encryption function. The invocation field shall identify the sets of inputs to the authenticated encryption function in that particular device.
決定論的構成方法では、IVは固定フィールドと呼ばれるフィールドと、呼び出しフィールドと呼ばれるフィールドの連結です。固定フィールドは、デバイス、またはより一般には認証付き暗号化関数のインスタンスのコンテキストを識別しなければなりません。呼び出しフィールドは、そのデバイスにおける認証付き暗号化関数への入力一式を識別しなければなりません。
For any given key, no two distinct devices shall share the same fixed field, and no two distinct sets of inputs to any single device shall share the same invocation field. Compliance with these two requirements implies compliance with the uniqueness requirement on IVs in Sec. 8.
所与の鍵について、異なる二つのデバイスが同じ固定フィールドを共有してはならず、単一デバイスに対する異なる入力一式が同じ呼び出しフィールドを共有してはなりません。これら二つの要件に適合すれば、8節のIV一意性要件にも適合します。
If desired, the fixed field itself may be constructed from two or more smaller fields. Moreover, one of those smaller fields could consist of bits that are arbitrary (i.e., not necessarily deterministic nor unique to the device), as long as the remaining bits ensure that the fixed field is not repeated in its entirety for some other device with the same key.
必要であれば、固定フィールド自体を二つ以上の小さなフィールドから構成してもよいです。さらに、それらの小フィールドの一つは、任意のビット（すなわち、必ずしも決定論的でもデバイス固有でもないビット）で構成してもよいです。ただし、残りのビットにより、同じ鍵を持つ他のデバイスにおいて固定フィールド全体が繰り返されないことが確保される場合に限ります。
Similarly, the entire fixed field may consist of arbitrary bits when there is only one context to identify, such as when a fresh key is limited to a single session of a communications protocol. In this case, if different participants in the session share a common fixed field, then the protocol shall ensure that the invocation fields are distinct for distinct data inputs.
同様に、通信プロトコルの単一セッションに新鮮な鍵の使用が限定される場合など、識別すべきコンテキストが単一であるときは、固定フィールド全体を任意のビットで構成してもよいです。この場合、セッション内の異なる参加者が共通の固定フィールドを共有するなら、プロトコルは、異なるデータ入力に対して呼び出しフィールドが異なることを確保しなければなりません。
The invocation field typically is either 1) an integer counter or 2) a linear feedback shift register that is driven by a primitive polynomial to ensure a maximal cycle length. In either case, the invocation field increments upon each invocation of the authenticated encryption function.
呼び出しフィールドは通常、1) 整数カウンター、または2) 最大周期長を確保するため原始多項式で駆動される線形帰還シフトレジスターのいずれかです。いずれの場合も、認証付き暗号化関数が呼び出されるたびに、呼び出しフィールドをインクリメントします。
The lengths and positions of the fixed field and the invocation field shall be fixed for each supported IV length for the life of the key. In order to promote interoperability for the default IV length of 96 bits, this Recommendation suggests, but does not require, that the leading (i.e., leftmost) 32 bits of the IV hold the fixed field; and that the trailing (i.e., rightmost) 64 bits hold the invocation field.
固定フィールドおよび呼び出しフィールドの長さと位置は、鍵の有効期間中、サポート対象の各IV長について固定しなければなりません。デフォルトのIV長である96ビットにおける相互運用性を促進するため、本勧告は、IVの先頭（すなわち左端）の32ビットに固定フィールドを、末尾（すなわち右端）の64ビットに呼び出しフィールドを保持することを提案しますが、必須とはしません。
8.2.2 RBG-based Construction
8.2.2 RBGベースの構成方法
In the RBG-based construction, the IV is the concatenation of two fields, called the random field and the free field. For each IV length that is supported by the implementation and used with the RBG-based construction, the lengths of these fields shall be fixed for the life of the key. Moreover, the length of the random field shall be at least 96 bits; the free field may be empty.
RBGベースの構成方法では、IVはランダムフィールドと呼ばれるフィールドと、フリーフィールドと呼ばれるフィールドの連結です。実装がサポートし、RBGベースの構成方法で使用する各IV長について、これらのフィールドの長さは鍵の有効期間中固定しなければなりません。さらに、ランダムフィールドの長さは96ビット以上でなければならず、フリーフィールドは空でもよいです。
If \(i\) is a supported IV length that is associated to the RBG-based construction, then let \(r(i)\) denote the bit length of the random field. The random field shall either consist of 1) an output string of \(r(i)\) bits from an approved RBG with a sufficient security strength, or 2) the result of applying the \(r(i)\)–bit incrementing function to the random field of the preceding IV for the given key. The \(r(i)\)–bit output string from the RBG is called a direct random string, and the random fields that result from applying the \(r(i)\)–bit incrementing function are called its successors.
RBGベースの構成方法に関連付けられたサポート対象IV長を\(i\)とするとき、\(r(i)\)をランダムフィールドのビット長とします。ランダムフィールドは、1) 十分なセキュリティ強度を持つ承認済みRBGからの\(r(i)\)ビットの出力文字列、または2) 所与の鍵に対する直前のIVのランダムフィールドに\(r(i)\)ビットインクリメント関数を適用した結果のいずれかで構成しなければなりません。RBGからの\(r(i)\)ビット出力文字列を直接ランダム文字列と呼び、\(r(i)\)ビットインクリメント関数の適用によって得られるランダムフィールドをその後続値と呼びます。
There are no requirements on the bits in the free field. For example, they may identify the device, similar to the fixed field of the deterministic construction, except within the RBG-based construction these identifiers are not required to be distinct for each device. For any IV length that is associated to the RBG-construction, the free field is recommended to be empty, so that the random field is the entire IV.
フリーフィールドのビットには要件がありません。たとえば、決定論的構成方法の固定フィールドと同様にデバイスを識別してもよいです。ただし、RBGベースの構成方法では、これらの識別子がデバイスごとに異なる必要はありません。RBGベースの構成方法に関連付けられるいずれのIV長についても、ランダムフィールドがIV全体となるよう、フリーフィールドは空にすることが推奨されます。
The instantiations of the RBGs in any two distinct devices shall be independent, so that the distribution of direct random strings across all of the RBG instantiations is expected to be uniform. For example, if the initialization of the RBG instantiations depends only on a secret seed, then each instantiation shall be initialized with a distinct seed.
異なる二つのデバイスにおけるRBGのインスタンス化は独立していなければならず、その結果、すべてのRBGインスタンス化から得られる直接ランダム文字列の分布が一様であることが期待されます。たとえば、RBGインスタンス化の初期化が秘密シードのみに依存する場合、各インスタンス化を異なるシードで初期化しなければなりません。
8.3 Constraints on the Number of Invocations
8.3 呼び出し回数の制約
The following requirement applies to all implementations that use either 1) the deterministic construction with IVs whose length is not 96, or 2) the RBG-based construction, for IVs of any length. In other words, unless an implementation only uses 96-bit IVs that are generated by the deterministic construction:
次の要件は、1) 長さが96ビットではないIVに決定論的構成方法を使用する実装、または2) あらゆる長さのIVにRBGベースの構成方法を使用する実装すべてに適用されます。言い換えれば、実装が決定論的構成方法で生成された96ビットIVのみを使用する場合を除き、次の要件が適用されます。
The total number of invocations of the authenticated encryption function shall not exceed \(2^{32}\), including all IV lengths and all instances of the authenticated encryption function with the given key.
所与の鍵について、すべてのIV長および認証付き暗号化関数のすべてのインスタンスを合計した呼び出し回数は\(2^{32}\)を超えてはなりません。
This is a “global” requirement that can be achieved by appropriate “local” limits on each instance of the authenticated encryption function with a given key. For example, suppose an implementation consists of \(2^{10}\) devices that only support 64-bit, 96-bit, and 128-bit IVs. One way to satisfy the above requirement would be to limit each device to \(2^{20}\) invocations with 64-bit IVs, \(2^{21}\) invocations with 96-bit IVs, and \(2^{20}\) invocations with 128-bit IVs.
これは「グローバル」要件であり、所与の鍵を持つ認証付き暗号化関数の各インスタンスに適切な「ローカル」上限を設定して満たすことができます。たとえば、64ビット、96ビット、128ビットのIVのみをサポートする\(2^{10}\)台のデバイスから実装が構成されるとします。この要件を満たす方法の一つは、各デバイスで64ビットIVを用いる呼び出しを\(2^{20}\)回、96ビットIVを\(2^{21}\)回、128ビットIVを\(2^{20}\)回に制限することです。
For the RBG-based construction of IVs, the above requirement, in conjunction with the requirement that \(r(i) \ge 96\), is sufficient to ensure the uniqueness requirement in Sec. 8, as follows from the discussion in Ref. [4].
IVのRBGベース構成方法については、上記要件と\(r(i) \ge 96\)という要件を併せることで、8節の一意性要件を十分に確保できます。これは文献[4]の議論から分かります。
For the deterministic construction, the lengths of the two fields imply two additional operational constraints. These constraints apply to any supported IV length, including 96 bits:
決定論的構成方法では、二つのフィールドの長さにより、さらに二つの運用上の制約が生じます。これらの制約は、96ビットを含む、サポート対象のあらゆるIV長に適用されます。
• The bit length of the invocation field limits the number of invocations of the authenticated encryption function with any given fixed field and key. In particular, if \(s\) denotes the number of bits in the invocation field, then the authenticated encryption function cannot be invoked on more than \(2^s\) distinct input sets without violating the uniqueness requirement.
• 呼び出しフィールドのビット長は、任意の固定フィールドおよび鍵について、認証付き暗号化関数を呼び出せる回数を制限します。特に、\(s\)を呼び出しフィールドのビット数とすると、一意性要件に違反することなく、認証付き暗号化関数を異なる入力一式に対して\(2^s\)回を超えて呼び出すことはできません。
• Similarly, an \(s\)-bit fixed field implies a limit of \(2^s\) on the number of distinct devices/contexts that can implement the authenticated encryption function for the given key, with IVs of the given length.
• 同様に、\(s\)ビットの固定フィールドは、所与の鍵について、所与の長さのIVを用いて認証付き暗号化関数を実装できる異なるデバイス／コンテキスト数を\(2^s\)に制限します。
9 Practical Considerations for Validating Implementations
9 実装を検証するための実務上の考慮事項
Both the designer of a GCM implementation and the information technology (IT) professional who deploys and maintains it within a particular system have important roles in meeting the uniqueness requirement in Sec. 8, as discussed in Secs. 9.1 and 9.2 below.
GCM実装の設計者と、特定のシステム内に実装を配備・保守する情報技術（IT）専門家は、8節の一意性要件を満たすうえで重要な役割を担います。詳細は以下の9.1節および9.2節で説明します。
The additional requirements in these two sections are provided for the purpose of demonstrating compliance with the uniqueness requirement in Sec. 8 within a validation program. Specifically, analogous to the requirements in Ref. [9], the requirements in these two sections apply to implementations that are validated against the requirements of FIPS Pub. 140-2 (Ref. [3]), or any superseding version of FIPS 140.
両節の追加要件は、検証プログラム内で8節の一意性要件への適合を実証する目的で示します。具体的には、文献[9]の要件と同様に、両節の要件は、FIPS Pub. 140-2（文献[3]）またはその後継版のFIPS 140の要件に照らして検証される実装に適用されます。
Implementations that are not validated against the requirements of FIPS Pub. 140-2 may interpret the requirements in Secs. 9.1 and 9.2 as recommendations.
FIPS Pub. 140-2の要件に照らして検証されない実装は、9.1節および9.2節の要件を推奨事項として解釈してもよいです。
9.1 Design Considerations
9.1 設計上の考慮事項
In order to inhibit an unauthorized party from controlling or influencing the generation of IVs, GCM shall be implemented only within a cryptographic module that meets the requirements of FIPS Pub. 140-2. In particular, the cryptographic boundary of the module shall contain a “generation unit” that produces IVs according to one of the constructions in Sec. 8.2 above.
権限のない当事者がIVの生成を制御または左右することを防ぐため、GCMはFIPS Pub. 140-2の要件を満たす暗号モジュール内でのみ実装しなければなりません。特に、モジュールの暗号境界内には、上記8.2節のいずれかの構成方法に従ってIVを生成する「生成ユニット」が含まれなければなりません。
The documentation of the module for its validation against the requirements of FIPS 140-2 shall describe how the module complies with the uniqueness requirement on IVs. At a minimum, the documentation shall address the considerations in this section, and clearly document the responsibilities of the IT professional who configures, deploys, and maintains the GCM implementations within a larger system.
FIPS 140-2の要件への適合性検証に用いるモジュールの文書には、モジュールがIVの一意性要件にどのように適合するかを記載しなければなりません。最低限、本節の考慮事項を扱い、より大きなシステム内でGCM実装を構成、配備、保守するIT専門家の責任を明確に文書化しなければなりません。
The following are three important design considerations for GCM modules:
GCMモジュールに関する重要な設計上の考慮事項を次に三つ示します。
1.The freshness of keys shall be assured, as discussed in Sec. 8.1.
1.8.1節で説明したとおり、鍵の新鮮性を保証しなければなりません。
2.The IV shall be a critical security parameter as defined in FIPS Pub. 140-2 until the authenticated encryption function is invoked with the IV. Prior to this invocation, the IV shall be provided the same protection as other critical security parameters in a module that is validated to the requirements in FIPS Pub. 140-2.
2.IVは、認証付き暗号化関数でそのIVを用いた呼び出しが行われるまで、FIPS Pub. 140-2で定義される重要なセキュリティパラメーターでなければなりません。この呼び出しが行われる前は、IVに、FIPS Pub. 140-2の要件に照らして検証されたモジュール内の他の重要なセキュリティパラメーターと同じ保護を与えなければなりません。
3.A loss of power to the module shall not cause the repetition of IVs. If the generation unit cannot recover from a loss of power, then the authenticated encryption function shall enter a failure state until a fresh key can be established.
3.モジュールへの電力喪失によってIVが再使用されてはなりません。生成ユニットが電力喪失から復旧できない場合、新鮮な鍵を確立できるまで認証付き暗号化関数を故障状態にしなければなりません。
The IV construction that is implemented from Sec. 8.2 above affects the options for recovery from a loss of power. For the deterministic construction, all of the deterministic elements that are necessary to construct the IV would have to be available when power is restored. For example, these elements could be stored in non-volatile memory.
上記8.2節のどちらのIV構成方法を実装するかは、電力喪失から復旧する選択肢に影響します。決定論的構成方法では、IVを構成するために必要なすべての決定論的要素を、電力復旧時に利用できなければなりません。たとえば、これらの要素は不揮発性メモリに保存できます。
When power is restored, neither the preceding IV nor any other previous IV shall immediately be repeated for the key. One way to avoid such a repetition would be to ensure that the invocation field value that is periodically stored in the non-volatile memory is always one or more values ahead of the operational value in the sequence.
電力が復旧したとき、所与の鍵について直前のIVまたはその他の過去のIVを直ちに再使用してはなりません。このような再使用を避ける方法の一つは、不揮発性メモリに定期的に保存する呼び出しフィールド値を、シーケンス上の運用値より常に一つ以上先行させることです。
One potential advantage of the RBG-based construction is that the RBG may be designed to recover from a loss of power in a straightforward manner, i.e., without requiring action from the IT professional that maintains the system. For example, the RBG may incorporate a non-deterministic source of bits that would automatically be available to the RBG when power is restored.
RBGベースの構成方法が持つ潜在的な利点の一つは、システムを保守するIT専門家の対応を必要とせず、RBGが単純な方法で電力喪失から復旧するよう設計できることです。たとえば、電力復旧時に自動的にRBGが利用できる非決定論的なビット源をRBGに組み込んでもよいです。
Alternatively, the entire state of the RBG may be stored periodically in non-volatile memory. In this case, similar to the deterministic construction, when power is restored, the design shall ensure that the RBG shall not output strings for use within new IVs until the state of the RBG is advanced beyond the state that generated the last IV for the key. In other words, the direct random string for the first new IV shall be, with high probability, different than the direct random string in any IV that was generated before the loss of power.
別の方法として、RBGの状態全体を定期的に不揮発性メモリに保存してもよいです。この場合、決定論的構成方法と同様に、電力復旧時には、鍵に対する最後のIVを生成した状態を超えてRBGの状態が進むまで、新しいIVで使用する文字列をRBGが出力しないことを設計で確保しなければなりません。言い換えれば、最初の新しいIVの直接ランダム文字列は、電力喪失前に生成されたどのIVの直接ランダム文字列とも高い確率で異ならなければなりません。
Even if the process is not automatic, the IT professional who maintains the system may simply reinitialize the RBG when power is restored, for example, with a fresh seed. In this case, either the design of the module or the IT professional that maintains the system shall ensure that compliance is maintained with the independence condition on the RBGs in Sec. 8.2.2.
処理を自動化しない場合でも、システムを保守するIT専門家は、電力復旧時に、たとえば新鮮なシードを用いてRBGを再初期化してもよいです。この場合、モジュールの設計またはシステムを保守するIT専門家のいずれかが、8.2.2節のRBG独立性条件への適合が維持されることを確保しなければなりません。
9.2 Operational Considerations
9.2 運用上の考慮事項
Compliance with the uniqueness requirement on IVs, and hence the security of GCM, ultimately depends on the IT professional who configures, deploys, and maintains the GCM modules within a particular system. The documentation for a GCM module shall give the IT professional detailed instructions that are tailored to the particular design of the module.
IVの一意性要件への適合、ひいてはGCMのセキュリティは、最終的には、特定のシステム内でGCMモジュールを構成、配備、保守するIT専門家に依存します。GCMモジュールの文書には、モジュールの特定の設計に合わせた詳細な手順をIT専門家に示さなければなりません。
The following are some typical operational considerations for the uniqueness requirement:
一意性要件に関する典型的な運用上の考慮事項を次に示します。
•Is the configuration of any GCM module, or any operational value, vulnerable to control or influence from any unauthorized party?
•GCMモジュールの構成または運用上の値が、権限のない当事者による制御または影響を受ける可能性はありますか。
•For any given key, how are configuration choices enforced across all modules that ever implement the authenticated encryption function?
•所与の鍵について、認証付き暗号化関数を実装するすべてのモジュールにわたって、構成の選択はどのように強制されますか。
•How is the freshness of keys assured, as discussed in Sec. 8.1?
•8.1節で説明したように、鍵の新鮮性はどのように保証されますか。
•If an implementation does not exclusively use 96-bit IVs that are generated by the deterministic construction, how is the requirement in Sec 8.3 on the number of invocations ensured?
•実装が、決定論的構成方法で生成された96ビットIVのみを排他的に使用しない場合、呼び出し回数に関する8.3節の要件はどのように確保されますか。
•As discussed in Sec. 9.1, how does IV generation within the modules recover from a loss of power without violating the uniqueness requirement on IVs?
•9.1節で説明したように、IVの一意性要件に違反することなく、モジュール内のIV生成は電力喪失からどのように復旧しますか。
The following considerations are specific to the deterministic construction:
以下の考慮事項は決定論的構成方法に固有です。
•How are the device identifiers installed into the fixed field so that compliance with the requirements on the fixed field in Sec. 8.2.1 is ensured, both for the initially deployed modules and for any subsequent deployed modules?
•最初に配備されたモジュールとその後に配備されるモジュールの両方について、8.2.1節の固定フィールド要件への適合を確保するよう、デバイス識別子は固定フィールドにどのように設定されますか。
•Is the length of the invocation field sufficient to support all of the invocations that can occur in any module during the lifetime of any key, as discussed in the first bullet in Sec. 8.3?
•8.3節の第一項で説明するように、呼び出しフィールドの長さは、任意の鍵の有効期間中にいずれかのモジュールで発生し得るすべての呼び出しを支えるのに十分か。
•For any given key and IV length, is the length of the fixed field sufficient to support the number of modules that will implement authenticated encryption, as discussed in the second bullet in Sec. 8.3?
•所与の鍵およびIV長について、認証付き暗号化を実装するモジュール数を支えるのに固定フィールドの長さは十分か。これは8.3節の第二項で説明されています。
•If the default setting for the lengths of the fixed field and the invocation field can be altered, then how is the choice enforced across all modules with any given key?
•固定フィールドと呼び出しフィールドの長さに対するデフォルト設定を変更できる場合、所与の鍵を持つすべてのモジュールにわたって、その選択はどのように強制されますか。
The following consideration is specific to the RBG-based construction:
以下の考慮事項はRBGベースの構成方法に固有です。
•How are the RBGs for IV generation initialized so that compliance is ensured with the independence requirement in Sec. 8.2.2, for the initially deployed modules and for any subsequent deployed modules?
•最初に配備されたモジュールとその後に配備されるモジュールの両方について、8.2.2節の独立性要件への適合が確保されるよう、IV生成用RBGはどのように初期化されますか。
10 Conformance
10 適合性
The two categories of implementations that may claim conformance with this Recommendation are GCM and GMAC.
本勧告への適合を主張できる実装のカテゴリーはGCMとGMACの二つです。
Implementations may restrict the bit lengths of the plaintext, AAD, IVs, and authentication tags that it supports, as discussed in Secs. 5.2.1.1 and 5.2.1.2 above. Although such restrictions may affect interoperability, only the elimination of the plaintext altogether, i.e., GMAC, is considered as a distinct category of implementation.
実装は、前述の5.2.1.1節および5.2.1.2節で説明したように、サポートする平文、AAD、IV、認証タグのビット長を制限してもよいです。このような制限は相互運用性に影響する可能性がありますが、平文を完全に取り除くこと、すなわちGMACのみを、別個の実装カテゴリーとみなします。
For every algorithm that is specified in this Recommendation, a conforming implementation may replace the given set of steps with any mathematically equivalent sets of steps. In other words, different procedures that produce the correct output for any input are permitted.
本勧告で規定する各アルゴリズムについて、適合実装は、提示された手順の集合を数学的に等価な任意の手順の集合に置き換えてもよいです。言い換えれば、任意の入力に対して正しい出力を生成する異なる手順を使用してもよいです。
Appendix A: Importance of the Uniqueness Requirement on IVs
付録A：IV一意性要件の重要性
Sec. 8 contains a uniqueness requirement for the IVs of GCM, across all implementations of the authenticated encryption function with any given key. This appendix summarizes why this requirement is crucial to the security of GCM, as first described in Ref. [5].
8節には、所与の鍵を用いる認証付き暗号化関数のすべての実装にわたり、GCMのIVに関する一意性要件が含まれています。本付録では、文献[5]で最初に説明されたこの要件がGCMのセキュリティにとって極めて重要である理由を要約します。
The secure operation of a cryptographic algorithm depends not only on the proper implementation of the steps of the algorithm, but also on the adherence to the associated requirements. An obvious example for any symmetric key algorithm is that the key needs to be kept secret. For GCM, the requirement in Sec. 5.2.1 for the uniqueness of the IVs is almost as important, although not as obvious.
暗号アルゴリズムが安全に動作するためには、アルゴリズムの手順が適切に実装されていることだけでなく、関連する要件が遵守されていることも必要です。共通鍵アルゴリズム全般に関する明白な例は、鍵を秘密に保つ必要があることです。GCMでは、5.2.1節のIV一意性要件も同じくらい重要ですが、その重要性はそれほど明白ではありません。
Consider first the example of the Counter mode requirement in Ref. [10] for the counter blocks to be unique. If this requirement is breached, then the Counter mode encryption function may fail to provide the expected confidentiality for the data blocks that correspond to the repeating counter blocks, although the other data blocks are not affected.
まず、文献[10]にあるカウンターブロックを一意にするカウンターモードの要件を例に考えます。この要件に違反すると、カウンターモードの暗号化関数は、カウンターブロックが再使用されるデータブロックについて期待される機密性を提供できない可能性がありますが、他のデータブロックには影響しません。
The Counter mode decryption function has a vulnerability that is arguably more serious. Counter-mode ciphertext is “malleable” in the sense that flipping any of its bits will induce the corresponding bits of the plaintext to flip upon decryption. Therefore, if an adversary knows a plaintext-ciphertext pair and can induce the decryption function to use the counter blocks from the known pair, then, by choosing which bits to flip in the known ciphertext, the adversary can control the result of decryption, up to the length of the known plaintext.
カウンターモードの復号関数には、さらに深刻と言える脆弱性があります。カウンターモードの暗号文は「改ざん可能」であり、その任意のビットを反転すると、復号時に平文の対応するビットも反転します。したがって、攻撃者が平文と暗号文のペアを知っており、既知のペアで使われたカウンターブロックを復号関数に使用させることができる場合、既知の暗号文のどのビットを反転するかを選ぶことで、既知の平文の長さの範囲内で復号結果を制御できます。
This vulnerability motivates combining the Counter mode encryption mechanism with an authentication mechanism, such as occurs in GCM. The idea is to prevent the adversary’s altered ciphertext from being accepted as valid. However, as detailed in Ref. [5], the authentication assurance in GCM crucially depends on the uniqueness of the IVs.
この脆弱性を踏まえ、GCMのように、カウンターモードの暗号化機構と認証機構を組み合わせることが動機付けられます。その目的は、攻撃者が改変した暗号文を有効なものとして受け入れないようにすることです。しかし、文献[5]で詳述されるように、GCMの認証保証はIVの一意性に決定的に依存します。
In particular, if IVs are ever repeated for the GCM authenticated encryption function for a given key, then it is likely that an adversary will be able to determine the hash subkey from the resulting ciphertexts. The adversary then could easily construct a ciphertext forgery. In particular, given the ciphertext and tag outputs for an invocation of the authenticated encryption function, along with the associated IV and AAD inputs, the adversary could substitute any ciphertext and AAD strings and use the subkey to generate the valid substitute tag. Although this forgery would use the same IV, in most cases it will not be feasible for the authenticated decryption function to detect the repetition. Thus, the authentication assurance essentially is lost.
特に、所与の鍵でGCM認証付き暗号化関数に対してIVが再使用された場合、攻撃者は結果として得られた暗号文からハッシュサブキーを特定できる可能性が高いです。その後、攻撃者は容易に暗号文偽造を作成できます。認証付き暗号化関数のある呼び出しについて、暗号文とタグの出力、および関連するIVとAADの入力が与えられると、攻撃者は任意の暗号文文字列およびAAD文字列に置き換え、サブキーを使って有効な代替タグを生成できます。この偽造では同じIVを使うものの、ほとんどの場合、認証付き復号関数が再使用を検知することは現実的に不可能です。したがって、認証保証は実質的に失われます。
Worse, the loss of authentication means that GCM inherits the problematic malleability of its Counter mode ciphertext. In the above scenario, knowing the original plaintext that corresponds to the given ciphertext, the adversary can construct the substitute ciphertext in such a way as to correspond to any desired plaintext of the same length. In other words, the adversary essentially could control the plaintext output of the authenticated decryption function.
さらに、認証が失われると、GCMはカウンターモード暗号文の問題のある改ざん可能性を引き継ぎます。上記の状況で、所与の暗号文に対応する元の平文が分かっていれば、攻撃者は同じ長さの任意の所望の平文に対応するよう、代替暗号文を構成できます。言い換えれば、攻撃者は認証付き復号関数の平文出力を実質的に制御できます。
Appendix B: Authentication Assurance
付録B：認証保証
The creation of an authentication tag by the authenticated encryption function provides the mechanism whereby assurance of the authenticity of the plaintext and AAD (and IV) can be obtained upon the execution of the authenticated decryption function. The nature of this assurance depends on the output of the authenticated decryption function:
認証付き暗号化関数による認証タグの生成は、認証付き復号関数の実行時に平文およびAAD（ならびにIV）の真正性を保証するための機構を提供します。この保証の性質は、認証付き復号関数の出力によって異なります。
•If the output is the plaintext, then the design of the mode provides strong, but not absolute, assurance that the purported source of the data created the tag, i.e., that the plaintext and the AAD (and the IV and the tag) are authentic. Consequently, the mode also provides strong assurance that this information was not subsequently altered, either intentionally or unintentionally.
•出力が平文である場合、このモードの設計により、データの主張された送信元がタグを生成したこと、すなわち平文とAAD（およびIVとタグ）が真正であることについて、強いが絶対ではない保証が得られます。したがって、この情報がその後、意図的か偶発的かを問わず改変されていないことについても、モードは強い保証を提供します。
• If the output is \(\mathit{FAIL}\), then it is certain that at least one of the given inputs (i.e., the ciphertext, the AAD, the IV, or the tag) is not authentic.
• 出力が\(\mathit{FAIL}\)の場合、与えられた入力（すなわち暗号文、AAD、IV、またはタグ）のうち少なくとも一つが真正でないことは確実です。
In the first case, the assurance is not absolute because forgeries are possible, in principle. In other words, an adversary, i.e., a party without access to the key or to the authenticated encryption function, may be able to produce the correct tag for some triple of ciphertext, AAD, and IV.
最初の場合に保証が絶対ではないのは、原理上、偽造が可能であるためです。言い換えれば、攻撃者、すなわち鍵にも認証付き暗号化関数にもアクセスできない当事者が、暗号文、AAD、IVの組み合わせの一部について正しいタグを生成できる場合があります。
As with any tag-based authentication mechanism, if the adversary chooses a \(t\)-bit tag at random, it is expected to be correct for given data with probability \(1/2^{t}\). With GCM, however, an adversary can choose tags that increase this probability, proportional to the total length of the ciphertext and AAD. Consequently, GCM is not well-suited for use with short tag lengths or very long messages.
タグに基づく認証機構全般と同様に、攻撃者が\(t\)ビットのタグを無作為に選んだ場合、所与のデータに対して正しい確率は\(1/2^{t}\)と予想されます。しかしGCMでは、攻撃者はこの確率を暗号文とAADの合計長に比例して高めるタグを選ぶことができます。そのため、GCMはタグ長が短い場合やメッセージが非常に長い場合の使用には適していません。
In particular, if \(n\) denotes the total number of blocks in the encoding (i.e., the input to the GHASH function in the definition of \(S\) in Secs. 7.1 and 7.2 above) of the ciphertext and AAD, then there is a method of constructing a “targeted” ciphertext forgery that is expected to succeed with a probability of approximately \(n/2^{t}\). Moreover, each successful forgery in this attack 1) increases the probability that subsequent targeted forgeries will succeed, and 2) leaks information about the hash subkey, \(H\). Eventually, \(H\) may be compromised entirely, with consequences as described at the end of Appendix A: the authentication assurance is completely lost.
特に、ブロック総数\(n\)を、暗号文とAADの符号化（すなわち、上記7.1節および7.2節の\(S\)の定義におけるGHASH関数への入力）に含まれるブロックの総数とします。このとき、成功確率が約\(n/2^{t}\)と予想される「標的型」暗号文偽造を構成する方法があります。さらに、この攻撃で偽造に成功するたびに、1) 後続の標的型偽造の成功確率が高まり、2) ハッシュサブキー\(H\)に関する情報が漏えいします。最終的には\(H\)が完全に侵害される可能性があり、その場合、付録A末尾で説明した結果が生じます。すなわち、認証保証が完全に失われます。
Ref. [1] describes the attack, and Ref. [7] gives a detailed treatment of the security properties of GCM. Appendix C gives guidance and requirements for the use of the two shortest tags sizes, 32 and 64 bits.
文献[1]ではこの攻撃を説明し、文献[7]ではGCMのセキュリティ特性を詳しく扱っています。付録Cでは、最短のタグ長である32ビットおよび64ビットを使用するためのガイダンスと要件を示します。
Independent of this attack, an adversary may attempt to systematically guess many different tags for a given input to authenticated decryption, and thereby increase the probability that one (or more) of them, eventually, will be accepted as valid. For this reason, the system or protocol that implements GCM should monitor and, if necessary, limit the number of unsuccessful verification attempts for each key.
この攻撃とは別に、攻撃者は認証付き復号への所与の入力に対して、多数の異なるタグを体系的に推測し、そのうち一つ（または複数）が最終的に有効なものとして受け入れられる確率を高めようとする場合があります。このため、GCMを実装するシステムまたはプロトコルは、鍵ごとに認証検証に失敗した回数を監視し、必要に応じて制限するべきです。
Moreover, as with most block cipher modes of operation, the security assurance of GCM degrades as more data is processed with a single key. Therefore, the total number of blocks of plaintext and AAD that are protected by invocations of the authenticated encryption function during the lifetime of the key should be limited. A reasonable limit for most applications would be \(2^{64}\), consistent with the requirement on the number of invocations in Sec. 8.3.
さらに、ほとんどのブロック暗号利用モードと同様に、単一の鍵で処理するデータ量が増えるにつれてGCMのセキュリティ保証は低下します。したがって、鍵の有効期間中に認証付き暗号化関数の呼び出しによって保護する平文およびAADのブロック総数を制限するべきです。ほとんどの用途にとって妥当な上限は\(2^{64}\)であり、8.3節の呼び出し回数要件とも整合します。
Appendix C: Requirements and Guidelines for Using Short Tags
付録C：短いタグを使用するための要件とガイドライン
For some voice or video applications, short authentication tags can be appropriate. The forgery of some fraction of the individual authenticated “packets” may be tolerable, because each packet of data in a large stream may carry very little of the overall meaning.
音声または映像を扱う一部の用途では、短い認証タグが適切な場合があります。大規模なストリームに含まれる各データパケットが全体の意味のごく一部しか担わない場合、個々の認証済み「パケット」の一部が偽造されても許容できることがあります。
However, even for voice and video applications, short tags can be problematic for GCM, due to the targeted forgery attack that is summarized in Appendix B and detailed in Ref. [1]. Absent the requirements and guidelines in this appendix, it may be practical for the attack to produce the hash subkey, \(H\), after which the authentication assurance is completely lost. Nevertheless, this Recommendation does not preclude short tags entirely, because knowledgeable security professionals should be able to manage the risks in connection with this attack, and its potential improvement.
しかし音声・映像用途であっても、付録Bで要約し文献[1]で詳述する標的型偽造攻撃のため、短いタグはGCMに問題をもたらす場合があります。本付録の要件とガイドラインがなければ、攻撃によりハッシュサブキー\(H\)が得られ、その後認証保証が完全に失われることが現実的となり得ます。それでも本勧告は短いタグを全面的に排除しません。十分な知識を持つセキュリティ専門家であれば、この攻撃およびその潜在的な改善に伴うリスクを管理できるはずだからです。
The following guidelines implicitly describe the special circumstances that may be appropriate for short tags. A packet in this context is a set of inputs to the authenticated decryption function.
以下のガイドラインは、短いタグが適切となり得る特別な状況を暗黙に示します。この文脈でいうパケットとは、認証付き復号関数への入力一式です。
1.Packets that fail the integrity check within the authenticated decryption function should be silently discarded. In other words, the controlling protocol/system over which packets are received should not provide an ACK/NACK response regarding the integrity of individual packets. However, the receiver should log authentication errors internally—in a way which is undetectable from side-channel information—and terminate the connection or notify the user if the percentage of errors exceeds what would be considered normal. This is standard security practice with any protocol/system and any algorithm choice.
1.認証付き復号関数内の完全性検査に失敗したパケットは、通知せずに破棄するべきです。言い換えれば、パケットを受信する制御プロトコル／システムは、個々のパケットの完全性に関するACK/NACK応答を返すべきではありません。ただし、受信側は認証エラーを、サイドチャネル情報から検出できない方法で内部記録し、エラー率が通常とみなされる範囲を超えた場合には接続を終了するか、ユーザーに通知するべきです。これはあらゆるプロトコル／システムおよびアルゴリズムの選択における標準的なセキュリティ慣行です。
2.The AAD within packets should be limited to the necessary header information and should not contain messages to be authenticated along with the encrypted data.
2.パケット内のAADは必要なヘッダー情報に限るべきであり、暗号化データとともに認証されるメッセージを含めるべきではありません。
3.The substance or meaning of the overall message that is comprised of a large number of packets should not be lost or compromised by the forgery of a single, arbitrary packet. For example, packets could carry a sequence of snippets of voice or visual data, but an individual packet should not carry a .txt or .doc file. Ideally, the plaintext data underlying the encryption should not be so stereotypical as to be guessable.
3.多数のパケットから構成されるメッセージ全体の内容または意味は、任意の単一パケットの偽造によって失われたり損なわれたりするべきではありません。たとえば、パケットは音声または視覚データの一連の断片を運んでもよいですが、個々のパケットに.txtファイルまたは.docファイルを載せるべきではありません。理想的には、暗号化の基礎となる平文データは、推測されやすいほど定型的であるべきではありません。
4. The controlling protocol/system should establish a new GCM key—and thus a new hash subkey, \(H\)—frequently, depending on the maximum combined length of the ciphertext and AAD that can occur within a single packet. Moreover, for 32-bit tags, this combined length should be very small—on the order of tens or hundreds of bytes; 64-bit tags extend the maximum combined length into the millions of bytes.
4. 制御プロトコル／システムは、単一パケット内で発生し得る暗号文とAADの最大合計長に応じて、新しいGCM鍵、ひいては新しいハッシュサブキー\(H\)を頻繁に確立するべきです。さらに、32ビットタグの場合、この合計長は非常に短く、数十または数百バイト程度であるべきです。64ビットタグでは、最大合計長を数百万バイトまで拡大できます。
An example of a protocol that meets these guidelines is Secure Real-time Transport Protocol carrying Voice over Internet Protocol, running over User Datagram Protocol.
これらのガイドラインを満たすプロトコルの例は、ユーザーデータグラムプロトコル上で動作する、Voice over Internet Protocolを伝送するSecure Real-time Transport Protocolです。
Tables 1 and 2 below quantify the recommendations in Item 4 above, for 32-bit and 64-bit tags, respectively. Each row has two entries: 1) a maximum combined length for the ciphertext and the AAD in a single packet, in bytes, and 2) a corresponding maximum number of invocations of the authenticated decryption function, across all instances of the GCM with the given key.
以下の表1および表2は、上記項目4の推奨事項を、それぞれ32ビットタグおよび64ビットタグについて定量化します。各行には二つの値があります。1) 単一パケット内の暗号文とAADの最大合計長（バイト単位）、2) 所与の鍵を用いるGCMの全インスタンスにわたる認証付き復号関数の対応する最大呼び出し回数。
For any implementation that supports 32-bit or 64-bit tags, one of the rows in Table 1 or Table 2, respectively, shall be enforced. In particular, the supported lengths for the plaintext/ciphertext and the AAD shall ensure that every valid packet satisfies the length restriction in the row, and the controlling protocol/system shall ensure that the key is changed before the authenticated decryption function is invoked more than the maximum that is given in the row. A smaller maximum may also be enforced.
32ビットまたは64ビットタグをサポートする実装では、それぞれ表1または表2のいずれかの行を強制しなければなりません。特に、サポート対象の平文／暗号文長およびAAD長により、すべての有効なパケットが該当行の長さ制限を満たすようにし、制御プロトコル／システムは、その行に示す最大回数を超えて認証付き復号関数が呼び出される前に鍵が変更されるようにしなければなりません。これより小さい上限を強制してもよいです。
Table 1: Constraints with 32-bit Tags
表1：32ビットタグの制約
| Maximum Combined Length of the Ciphertext and AAD In a Single Packet (bytes) | Maximum Invocations of the Authenticated Decryption Function |
| \(2^{5}\) | \(2^{22}\) |
| \(2^{6}\) | \(2^{20}\) |
| \(2^{7}\) | \(2^{18}\) |
| \(2^{8}\) | \(2^{15}\) |
| \(2^{9}\) | \(2^{13}\) |
| \(2^{10}\) | \(2^{11}\) |
| 1パケット内の暗号文とAADの最大合計長（バイト） | 認証付き復号関数の最大呼び出し回数 |
| \(2^{5}\) | \(2^{22}\) |
| \(2^{6}\) | \(2^{20}\) |
| \(2^{7}\) | \(2^{18}\) |
| \(2^{8}\) | \(2^{15}\) |
| \(2^{9}\) | \(2^{13}\) |
| \(2^{10}\) | \(2^{11}\) |
Table 2: Constraints with 64-bit Tags
表2：64ビットタグの制約
| Maximum Combined Length of the Ciphertext and AAD In a Single Packet (bytes) | Maximum Invocations of the Authenticated Decryption Function |
| \(2^{15}\) | \(2^{32}\) |
| \(2^{17}\) | \(2^{29}\) |
| \(2^{19}\) | \(2^{26}\) |
| \(2^{21}\) | \(2^{23}\) |
| \(2^{23}\) | \(2^{20}\) |
| \(2^{25}\) | \(2^{17}\) |
| 1パケット内の暗号文とAADの最大合計長（バイト） | 認証付き復号関数の最大呼び出し回数 |
| \(2^{15}\) | \(2^{32}\) |
| \(2^{17}\) | \(2^{29}\) |
| \(2^{19}\) | \(2^{26}\) |
| \(2^{21}\) | \(2^{23}\) |
| \(2^{23}\) | \(2^{20}\) |
| \(2^{25}\) | \(2^{17}\) |
Appendix D: Protection Against Replay of Messages
付録D：メッセージのリプレイに対する保護
As described in Appendix B, the successful verification of the tag within the authenticated decryption function gives assurance of the authenticity of the data; however, the party that presents the input data to the authenticated decryption function may not be the original source of the plaintext and AAD. In other words, GCM, like many other authentication mechanisms, does not inherently prevent an adversary from intercepting the output of an invocation of authenticated encryption and “replaying” it for authenticated decryption at a later time, for example, in an attempt to impersonate a party that has access to the key. In some protocols an adversary may even be able to use data that the verifier itself generated earlier in the protocol.
付録Bで説明したように、認証付き復号関数内でタグ検証が成功すれば、データの真正性が保証されます。しかし、認証付き復号関数に入力データを提示する当事者が、平文およびAADの元の送信元とは限りません。言い換えれば、GCMは他の多くの認証機構と同様に、攻撃者が認証付き暗号化の出力を傍受し、後で認証付き復号に「リプレイ」することを本質的には防止しません。たとえば、鍵にアクセスできる当事者になりすます試みが考えられます。一部のプロトコルでは、検証者自身が以前に生成したデータを攻撃者が利用できる場合さえあります。
The controlling system or protocol may protect against such an event by monitoring for any duplication of the IVs that are presented for authenticated decryption. Alternatively, certain identifying information can be incorporated into the AAD. Examples of such information include a sequential message number or a timestamp. Upon successful verification of authenticity, this information may provide a means for the detection of replayed messages, out-of-sequence messages, or missing messages.
制御システムまたはプロトコルは、認証付き復号に提示されるIVの重複を監視することで、このような事象を防止してもよいです。別の方法として、ある種の識別情報をAADに組み込むことができます。そのような情報の例として、連続するメッセージ番号またはタイムスタンプがあります。真正性の検証に成功した後、こうした情報により、リプレイされたメッセージ、順序どおりでないメッセージ、または欠落メッセージを検知できる場合があります。
Appendix E: Bibliography
付録E：参考文献
[1] Ferguson, N., Authentication Weaknesses in GCM, Natl. Inst. Stand. Technol. [Web page], http://www.csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf, May 20, 2005.
[1] Ferguson, N., Authentication Weaknesses in GCM, Natl. Inst. Stand. Technol. [Web page], http://www.csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf, May 20, 2005.
[2] FIPS Publication 197, The Advanced Encryption Standard (AES), U.S. DoC/NIST, November 26, 2001.
[2] FIPS Publication 197, The Advanced Encryption Standard (AES), U.S. DoC/NIST, November 26, 2001.
[3] FIPS Publication 140-2, Security Requirements for Cryptographic Modules, U.S. DoC/NIST, May 25, 2001.
[3] FIPS Publication 140-2, Security Requirements for Cryptographic Modules, U.S. DoC/NIST, May 25, 2001.
[4] IEEE P1619.1™/D23, Draft Standard for Authenticated Encryption with Length Expansion for Storage Devices.
[4] IEEE P1619.1™/D23, Draft Standard for Authenticated Encryption with Length Expansion for Storage Devices.
[5] A. Joux, Authentication Failures in NIST version of GCM, Natl. Inst. Stand. Technol. [Web page], http://www.csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/800-38_Series-Drafts/GCM/Joux_comments.pdf.
[5] A. Joux, Authentication Failures in NIST version of GCM, Natl. Inst. Stand. Technol. [Web page], http://www.csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/800-38_Series-Drafts/GCM/Joux_comments.pdf.
[6] D. McGrew, J. Viega, The Galois/Counter Mode of Operation (GCM), Natl. Inst. Stand. Technol. [Web page], http://www.csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-revised-spec.pdf, May 31, 2005.
[6] D. McGrew, J. Viega, The Galois/Counter Mode of Operation (GCM), Natl. Inst. Stand. Technol. [Web page], http://www.csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-revised-spec.pdf, May 31, 2005.
[7] D. McGrew and J. Viega. The Security and Performance of the Galois/Counter Mode (GCM) of Operation. Proceedings of INDOCRYPT ’04, Springer-Verlag, 2004. Full paper available from the IACR Cryptology ePrint Archive: Report 2004/193, [Web page], http://eprint.iacr.org/2004/193/, October 7, 2004.
[7] D. McGrew and J. Viega. The Security and Performance of the Galois/Counter Mode (GCM) of Operation. Proceedings of INDOCRYPT ’04, Springer-Verlag, 2004. Full paper available from the IACR Cryptology ePrint Archive: Report 2004/193, [Web page], http://eprint.iacr.org/2004/193/, October 7, 2004.
[9] National Institute of Standards and Technology and Communications Security Establishment, Implementation Guidance for FIPS Pub. 140-2 and the Cryptographic Module Validation Program, Natl. Inst. Stand. Technol. [Web page], http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf.
[9] 米国国立標準技術研究所およびカナダ通信保安機構「FIPS Pub. 140-2の実装ガイダンスおよび暗号モジュール検証プログラム」Natl. Inst. Stand. Technol. [Web page], http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf.
[10] NIST Special Publication 800-38A, 2001 ED, Version 1, Recommendation for Block Cipher Modes of Operation—Methods and Techniques, December 2001, Natl. Inst. Stand. Technol. [Web page], http://www.csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf.
[10] NIST Special Publication 800-38A、2001 ED、Version 1、「ブロック暗号の利用モードに関する勧告—方法および技法」、2001年12月、Natl. Inst. Stand. Technol. [Web page], http://www.csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf.