[要約] RFC 3566は、IPsecのAHおよびESPプロトコルにおいて、AES-XCBC-MAC-96アルゴリズムを使用してメッセージ認証を行う方法を規定しています。HMACとは異なる、AESブロック暗号を基盤としたメッセージ認証コード（MAC）の手法であり、特にハードウェア実装における効率性が高いという特徴があります。128ビットの鍵を用い、生成されたMACの上位96ビットをパケット内の認証データとして使用する手順を標準化しています。
Network Working Group S. Frankel
Request for Comments: 3566 NIST
Category: Standards Track H. Herbert
Intel
September 2003
The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
AES-XCBC-MAC-96 アルゴリズムとその IPsec での利用
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96.
メッセージ認証コード（MAC）は、鍵に依存する一方向ハッシュ関数です。MAC アルゴリズムを構築する一般的な方法の 1 つは、ブロック暗号を暗号ブロックチェーン（CBC）動作モードと組み合わせて使用することです。従来の CBC-MAC アルゴリズムは、事前に選択された固定長のメッセージに対しては安全ですが、一般的な IP データグラムに見られるような様々な長さのメッセージに対しては安全ではないことが示されています。本文書は、この制限を克服するために、いくつかの拡張機能を備えた CBC モードでの AES の使用を規定します。この新しいアルゴリズムは AES-XCBC-MAC-96 と命名されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. Specification of Requirements . . . . . . . . . . . . . . 2 3. Basic CBC-MAC with Obligatory 10* Padding . . . . . . . . 3 4. AES-XCBC-MAC-96 . . . . . . . . . . . . . . . . . . . . . 3 4.1. Keying Material. . . . . . . . . . . . . . . . . . . 5 4.2. Padding . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Truncation . . . . . . . . . . . . . . . . . . . . . 6 4.4. Interaction with the ESP Cipher Mechanism. . . . . . 6 4.5. Performance. . . . . . . . . . . . . . . . . . . . . 6 4.6. Test Vectors . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 8 7. Intellectual Property Rights Statement . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . 9 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 10 11. Full Copyright Statement . . . . . . . . . . . . . . . . . 11
Message authentication provides data integrity and data origin authentication with respect to the original message source. A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length [CBC-MAC-2], has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams [CBC-MAC-2, section 5]. In fact, it is trivial to produce forgeries for a second message given the MAC of a prior message. [HANDBOOK, section 9.62, p. 354]
メッセージ認証は、元のメッセージソースに対するデータの整合性とデータ起源の認証を提供します。メッセージ認証コード（MAC）は、鍵に依存する一方向ハッシュ関数です。MAC アルゴリズムを構築する一般的な方法の 1 つは、ブロック暗号を暗号ブロックチェーン（CBC）動作モードと組み合わせて使用することです。従来の CBC-MAC アルゴリズムは、事前に選択された固定長のメッセージに対しては安全ですが [CBC-MAC-2]、一般的な IP データグラムに見られるような様々な長さのメッセージに対しては安全ではないことが示されています [CBC-MAC-2 のセクション 5]。実際、以前のメッセージの MAC が与えられた場合、別のメッセージに対する偽造メッセージを作成することは容易です。[HANDBOOK のセクション 9.62, 354ページ]
This memo specifies the use of AES [AES] in CBC mode [MODES] with a set of extensions [XCBC-MAC-1] to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. Using the AES block cipher, with its increased block size (128 bits) and increased key length (128 bits), provides the new algorithm with the ability to withstand continuing advances in crypto-analytic techniques and computational capability. AES-XCBC-MAC-96 is used as an authentication mechanism within the context of the IPsec Encapsulating Security Payload (ESP) and the Authentication Header (AH) protocols. For further information on ESP, refer to [ESP] and [ROADMAP]. For further information on AH, refer to [AH] and [ROADMAP].
本文書は、この制限を克服するために、いくつかの拡張機能 [XCBC-MAC-1] を備えた CBC モード [MODES] での AES [AES] の使用を規定します。この新しいアルゴリズムは AES-XCBC-MAC-96 と命名されています。ブロックサイズ（128 ビット）および鍵長（128 ビット）が増加した AES ブロック暗号を使用することで、暗号解読技術の継続的な進歩や計算能力の向上に対抗する能力を新しいアルゴリズムに提供します。AES-XCBC-MAC-96 は、IPsec の暗号ペイロードカプセル化（ESP）および認証ヘッダー（AH）プロトコルの文脈における認証メカニズムとして使用されます。ESP の詳細については、[ESP] および [ROADMAP] を参照してください。AH の詳細については、[AH] および [ROADMAP] を参照してください。
The goal of AES-XCBC-MAC-96 is to ensure that the datagram is authentic and cannot be modified in transit. Data integrity and data origin authentication as provided by AES-XCBC-MAC-96 are dependent upon the scope of the distribution of the secret key. If the key is known only by the source and destination, this algorithm will provide both data origin authentication and data integrity for datagrams sent between the two parties. In addition, only a party with the identical key can verify the hash.
AES-XCBC-MAC-96 の目標は、データグラムが真正であり、転送中に改ざんされないことを保証することです。AES-XCBC-MAC-96 が提供するデータの整合性とデータ起源の認証は、秘密鍵の配布範囲に依存します。鍵が送信元と送信先のみに知られている場合、このアルゴリズムは 2 者間で送信されるデータグラムのデータ起源の認証とデータの整合性の両方を提供します。また、同一の鍵を持つ当事者のみがハッシュを検証できます。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that appear in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC-2119].
本文書に登場するキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、BCP 14、RFC 2119 [RFC-2119] で説明されているように解釈されるものとします。
CBC-MAC uses a block cipher for encryption; the block cipher transforms b bits of plaintext to b bits of ciphertext. The basic CBC-MAC [CBC-MAC-1, CBC-MAC-2] with Obligatory 10* Padding over a b-bit block cipher is calculated as follows for a message M:
CBC-MAC は、暗号化にブロック暗号を使用します。ブロック暗号は、b ビットの平文を b ビットの暗号文に変換します。b ビットのブロック暗号に対する必須の 10* パディングを用いた基本的な CBC-MAC [CBC-MAC-1, CBC-MAC-2] は、メッセージ M に対して次のように計算されます。
(1) Append a single 1 bit to M. Then append the minimum number of 0 bits to M such that the length of M is a multiple of b. [NOTE: This is 1 of several padding schemes that can be used for CBC-MAC. Several others are described in [MODES].]
(1) M の末尾に 1 つの 1 ビットを追加します。次に、M の長さが b の倍数になるように、最小限の数の 0 ビットを M に追加します。[注：これは CBC-MAC に使用できるいくつかのパディングスキームの 1 つです。他のいくつかについては [MODES] で説明されています。]
(2) Break M into n blocks, M[1] ... M[n], where the blocksize of blocks M[1] ... M[n] is b bits
(2) M を n 個のブロック M[1] ... M[n] に分割します。ここで、各ブロック M[1] ... M[n] のブロックサイズは b ビットです。
(3) Define E[0] = 0x00000000000000000000000000000000
(3) E[0] = 0x000000000000000000000000000000000 と定義します。
(4) For each block M[i], where i = 1 ... n: XOR M[i] with E[i-1], then encrypt the result with Key K, yielding E[i].
(4) 各ブロック M[i]（i = 1 ... n）について、M[i] と E[i-1] の排他的論理和（XOR）を計算し、その結果を鍵 K で暗号化して E[i] を生成します。
(5) E[n] is the b-bit authenticator.
(5) E[n] は b ビットの認証子です。
Basic CBC-MAC with obligatory 10* padding has been shown to be secure for messages up to (but not including) a pre-selected fixed length, in which the length is a multiple of the blocksize. This algorithm is not suitable for IPsec for the following reasons:
必須の 10* パディングを用いた基本的な CBC-MAC は、ブロックサイズの倍数である事前に選択された固定長に達するまでの（ただしその長さを含まない）メッセージに対して安全であることが示されています。このアルゴリズムは、以下の理由により IPsec には適していません。
+ Any IPsec authenticator must be able to handle messages of arbitrary length. However, the basic CBC-MAC cannot securely handle messages that exceed the pre-selected fixed length.
+ どのような IPsec 認証子も、任意の長さのメッセージを処理できる必要があります。しかし、基本的な CBC-MAC は、事前に選択された固定長を超えるメッセージを安全に処理することができません。
+ For messages shorter than the pre-selected fixed length, padding the message to the pre-selected fixed length may necessitate additional encryption operations, adding an unacceptable computational penalty.
+ 事前に選択された固定長よりも短いメッセージの場合、メッセージを事前に選択された固定長にパディングするために追加の暗号化操作が必要になることがあり、許容できない計算上のペナルティが課されます。
[AES] describes the underlying AES algorithm, while [CBC-MAC-1] and [XCBC-MAC-1] describe the AES-XCBC-MAC algorithm.
[AES] は基礎となる AES アルゴリズムを定義しており、[CBC-MAC-1] および [XCBC-MAC-1] は AES-XCBC-MAC アルゴリズムを定義しています。
The AES-XCBC-MAC-96 algorithm is a variant of the basic CBC-MAC with obligatory 10* padding; however, AES-XCBC-MAC-96 is secure for messages of arbitrary length. The AES-XCBC-MAC-96 calculations require numerous encryption operations; this encryption MUST be accomplished using AES with a 128-bit key. Given a 128-bit secret key K, AES-XCBC-MAC-96 is calculated as follows for a message M that consists of n blocks, M[1] ... M[n], in which the blocksize of blocks M[1] ... M[n-1] is 128 bits and the blocksize of block M[n] is between 1 and 128 bits:
AES-XCBC-MAC-96 アルゴリズムは、必須の 10* パディングを用いた基本的な CBC-MAC の変種ですが、任意の長さ of メッセージに対して安全です。AES-XCBC-MAC-96 の計算には多数の暗号化操作が必要であり、この暗号化には 128 ビットの鍵を用いた AES を使用しなければなりません（MUST）。128 ビットの秘密鍵 K が与えられた場合、n 個のブロック M[1] ... M[n] からなるメッセージ M に対して、AES-XCBC-MAC-96 は次のように計算されます。ここで、ブロック M[1] ... M[n-1] のブロックサイズは 128 ビットであり、ブロック M[n] のブロックサイズは 1 から 128 ビットの間です。
(1) Derive 3 128-bit keys (K1, K2 and K3) from the 128-bit secret key K, as follows
(1) 次のように、128 ビットの秘密鍵 K から 3 つの 128 ビットの鍵（K1、K2、K3）を導出します。
K1 = 0x01010101010101010101010101010101 encrypted with Key K
K2 = 0x02020202020202020202020202020202 encrypted with Key K
K3 = 0x03030303030303030303030303030303 encrypted with Key K
(2) Define E[0] = 0x00000000000000000000000000000000
(2) E[0] = 0x00000000000000000000000000000000 と定義します。
(3) For each block M[i], where i = 1 ... n-1: XOR M[i] with E[i-1], then encrypt the result with Key K1, yielding E[i].
(3) 各ブロック M[i]（i = 1 ... n-1）について、M[i] と E[i-1] の排他的論理和（XOR）を計算し、その結果を鍵 K1 で暗号化して E[i] を生成します。
(4) For block M[n]:
(4) ブロックM [n]の場合：
a) If the blocksize of M[n] is 128 bits: XOR M[n] with E[n-1] and Key K2, then encrypt the result with Key K1, yielding E[n].
a) M[n] のブロックサイズが 128 ビットの場合：M[n]、E[n-1]、および鍵 K2 の排他的論理和（XOR）を計算し、その結果を鍵 K1 で暗号化して E[n] を生成します。
b) If the blocksize of M[n] is less than 128 bits:
b) M[n] のブロックサイズが 128 ビット未満の場合：
i) Pad M[n] with a single "1" bit, followed by the number of "0" bits (possibly none) required to increase M[n]'s blocksize to 128 bits.
i) M[n] に 1 つの「1」ビットを追加し、続いて M[n] のブロックサイズを 128 ビットに増やすために必要な数の「0」ビット（不要な場合はなし）でパディングします。
ii) XOR M[n] with E[n-1] and Key K3, then encrypt the result with Key K1, yielding E[n].
ii) M[n]、E[n-1]、および鍵 K3 の排他的論理和（XOR）を計算し、その結果を鍵 K1 で暗号化して E[n] を生成します。
(5) The authenticator value is the leftmost 96 bits of the 128-bit E[n].
(5) 認証子の値は、128 ビットの E[n] の左端 96 ビットです。
NOTE1: If M is the empty string, pad and encrypt as in (4)(b) to create M[1] and E[1]. This will never be the case for ESP or AH, but is included for completeness sake.
注1：M が空の文字列である場合、(4)(b) のようにパディングと暗号化を行い、M[1] および E[1] を作成します。これは ESP または AH の場合は決してありませんが、完全性のために含まれています。
NOTE2: [CBC-MAC-1] defines K1 as follows: K1 = Constant1A encrypted with Key K | Constant1B encrypted with Key K.
注2：[CBC-MAC-1] は K1 を次のように定義しています。K1 = (鍵 K で暗号化された Constant1A) | (鍵 K で暗号化された Constant1B)
However, the second encryption operation is only needed for AES-XCBC-MAC with keys greater than 128 bits; thus, it is not included in the definition of AES-XCBC-MAC-96.
ただし、2 番目の暗号化操作は 128 ビットを超える鍵を持つ AES-XCBC-MAC でのみ必要とされるため、AES-XCBC-MAC-96 の定義には含まれていません。
AES-XCBC-MAC-96 verification is performed as follows: Upon receipt of the AES-XCBC-MAC-96 authenticator, the entire 128-bit value is computed and the first 96 bits are compared to the value stored in the authenticator field.
AES-XCBC-MAC-96 の検証は次のように実行されます。AES-XCBC-MAC-96 認証子を受信すると、128 ビット値全体が計算され、その先頭の 96 ビットが認証子フィールドに格納されている値と比較されます。
AES-XCBC-MAC-96 is a secret key algorithm. For use with either ESP or AH a fixed key length of 128-bits MUST be supported. Key lengths other than 128-bits MUST NOT be supported (i.e., only 128-bit keys are to be used by AES-XCBC-MAC-96).
AES-XCBC-MAC-96 は共通鍵アルゴリズムです。ESP または AH のいずれかで使用する場合、128 ビットの固定鍵長をサポートしなければなりません（MUST）。128 ビット以外の鍵長をサポートしてはなりません（MUST NOT）（すなわち、AES-XCBC-MAC-96 では 128 ビットの鍵のみが使用されます）。
AES-XCBC-MAC-96 actually requires 384 bits of keying material (128 bits for the AES keysize + 2 times the blocksize). This keying material can either be provided through the key generation mechanism or it can be generated from a single 128-bit key. The latter approach has been selected for AES-XCBC-MAC-96, since it is analogous to other authenticators used within IPsec. The reason AES-XCBC-MAC-96 uses 3 keys is so the length of the input stream does not need to be known in advance. This may be useful for systems that do one-pass assembly of large packets.
AES-XCBC-MAC-96 は、実際には 384 ビットの鍵情報を必要とします（AES の鍵サイズに 128 ビット、およびブロックサイズの 2 倍）。この鍵情報は、鍵生成メカニズムを通じて提供されるか、単一の 128 ビットの鍵から生成することができます。後者のアプローチは、IPsec 内で使用される他の認証子と同様であるため、AES-XCBC-MAC-96 に採用されています。AES-XCBC-MAC-96 が 3 つの鍵を使用する理由は、入力ストリームの長さを事前に知る必要がないためです。これは、巨大なパケットのワンパス処理を行うシステムに有用です。
A strong pseudo-random function MUST be used to generate the required 128-bit key. This key, along with the 3 derived keys (K1, K2 and K3), should be used for no purposes other than those specified in the algorithm. In particular, they should not be used as keys in another cryptographic setting. Such abuses will invalidate the security of the authentication algorithm.
必要な 128 ビットの鍵を生成するには、強力な擬似ランダム関数を使用しなければなりません（MUST）。この鍵は、3 つの派生鍵（K1、K2、K3）とともに、アルゴリズムで指定されている以外の目的で使用してはなりません（SHOULD NOT）。特に、これらを他の暗号設定の鍵として使用すべきではありません。そのような誤用は、認証アルゴリズムのセキュリティを無効にします。
At the time of this writing there are no specified weak keys for use with AES-XCBC-MAC-96. This does not mean to imply that weak keys do not exist. If, at some point, a set of weak keys for AES-XCBC-MAC-96 are identified, the use of these weak keys MUST be rejected followed by a request for replacement keys or a newly negotiated Security Association.
本書の執筆時点では、AES-XCBC-MAC-96 で使用される特定の弱い鍵（weak keys）は指定されていません。これは弱い鍵が存在しないことを意味するものではありません。もし、将来的に AES-XCBC-MAC-96 の弱い鍵のセットが特定された場合、それらの弱い鍵の使用は拒否されなければならず（MUST）、代替の鍵の要求または新しいセキュリティアソシエーション（SA）のネゴシエーションが行われなければなりません。
[ARCH] describes the general mechanism for obtaining keying material when multiple keys are required for a single SA (e.g., when an ESP SA requires a key for confidentiality and a key for authentication).
[ARCH] は、単一の SA に対して複数の鍵が必要とされる場合（たとえば、ESP SA が機密性のための鍵と認証のための鍵を必要とする場合）に鍵情報を取得するための一般的なメカニズムを説明しています。
In order to provide data origin authentication, the key distribution mechanism must ensure that unique keys are allocated and that they are distributed only to the parties participating in the communication.
データ起源認証を提供するためには、鍵配布メカニズムが一意の鍵を割り当て、それらが通信に参加する当事者間のみに配布されることを保証しなければなりません。
Current attacks do not necessitate a specific recommended frequency for key changes. However, periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and the keys, reduces the information available to a cryptanalyst, and limits the damage resulting from a compromised key.
現在の攻撃法では、特定の推奨される鍵交換頻度は必要とされていません。しかし、定期的な鍵の更新は、アルゴリズムや鍵の潜在的な弱点への対策となり、暗号解読者が利用可能な情報を減らし、鍵が漏洩した場合の被害を抑えるための基本的なセキュリティ対策です。
AES-XCBC-MAC-96 operates on 128-bit blocks of data. Padding requirements are specified in [CBC-MAC-1] and are part of the XCBC algorithm. If you build AES-XCBC-MAC-96 according to [CBC-MAC-1] you do not need to add any additional padding as far as AES-XCBC-MAC-96 is concerned. With regard to "implicit packet padding" as defined in [AH], no implicit packet padding is required.
AES-XCBC-MAC-96 は 128 ビットのデータブロックで動作します。パディング要件は [CBC-MAC-1] で規定されており、XCBC アルゴリズムの一部です。[CBC-MAC-1] に従って AES-XCBC-MAC-96 を構築する場合、AES-XCBC-MAC-96 に関する限り、追加のパディングを追加する必要はありません。[AH] で定義されている「暗黙のパケットパディング」に関しては、暗黙のパケットパディングは不要です。
AES-XCBC-MAC produces a 128-bit authenticator value. AES-XCBC-MAC-96 is derived by truncating this 128-bit value as described in [HMAC] and verified in [XCBC-MAC-2]. For use with either ESP or AH, a truncated value using the first 96 bits MUST be supported. Upon sending, the truncated value is stored within the authenticator field. Upon receipt, the entire 128-bit value is computed and the first 96 bits are compared to the value stored in the authenticator field. No other authenticator value lengths are supported by AES-XCBC-MAC-96.
AES-XCBC-MAC は 128 ビットの認証子値を生成します。AES-XCBC-MAC-96 は、[HMAC] で説明され [XCBC-MAC-2] で検証されているように、この 128 ビット値を切り捨てることで導出されます。ESP または AH のいずれかで使用する場合、最初の 96 ビットを使用した切り捨てられた値をサポートしなければなりません（MUST）。送信時、切り捨てられた値は認証子フィールドに格納されます。受信時、128 ビット値全体が計算され、その先頭の 96 ビットが認証子フィールドに格納されている値と比較されます。AES-XCBC-MAC-96 では、他の認証子値の長さはサポートされていません。
The length of 96 bits was selected because it is the default authenticator length as specified in [AH] and meets the security requirements described in [XCBC-MAC-2].
96 ビットという長さは、[AH] で規定されているデフォルトの認証子の長さであり、[XCBC-MAC-2] で説明されているセキュリティ要件を満たしているため選択されました。
As of this writing, there are no known issues which preclude the use of AES-XCBC-MAC-96 with any specific cipher algorithm.
本書の執筆時点では、AES-XCBC-MAC-96 を特定の暗号アルゴリズムと併用することを妨げる既知の問題はありません。
For any CBC MAC variant, the major computational effort is expended in computing the underlying block cipher. This algorithm uses a minimum number of AES invocations, one for each block of the message or fraction thereof, resulting in performance equivalent to classic CBC-MAC.
どの CBC-MAC バリアントであっても、計算負荷の大部分は基礎となるブロック暗号の計算に費やされます。このアルゴリズムは、メッセージの各ブロック（またはその端数部分）に対して最小限の回数の AES 呼び出しを使用するため、従来の CBC-MAC と同等のパフォーマンスをもたらします。
The key expansion requires 3 additional AES encryption operations, but these can be performed once in advance for each secret key.
鍵の拡張には追加で 3 回の AES 暗号化操作が必要ですが、これらは各秘密鍵に対して事前に対で 1 回だけ実行しておくことができます。
These test cases were provided by John Black, co-author of the XCBC-MAC algorithm, who verified them with 2 independent implementations. All values are hexadecimal numbers.
これらのテストケースは、XCBC-MAC アルゴリズムの共同開発者である John Black 氏によって提供され、2 つの独立した実装で検証されました。すべての値は 16 進数です。
Test Case #1 : AES-XCBC-MAC-96 with 0-byte input
Key (K) : 000102030405060708090a0b0c0d0e0f
Message (M) : <empty string>
AES-XCBC-MAC : 75f0251d528ac01c4573dfd584d79f29
AES-XCBC-MAC-96: 75f0251d528ac01c4573dfd5
Test Case #2 : AES-XCBC-MAC-96 with 3-byte input
Key (K) : 000102030405060708090a0b0c0d0e0f
Message (M) : 000102
AES-XCBC-MAC : 5b376580ae2f19afe7219ceef172756f
AES-XCBC-MAC-96: 5b376580ae2f19afe7219cee
Test Case #3 : AES-XCBC-MAC-96 with 16-byte input
Key (K) : 000102030405060708090a0b0c0d0e0f
Message (M) : 000102030405060708090a0b0c0d0e0f
AES-XCBC-MAC : d2a246fa349b68a79998a4394ff7a263
AES-XCBC-MAC-96: d2a246fa349b68a79998a439
Test Case #4 : AES-XCBC-MAC-96 with 20-byte input
Key (K) : 000102030405060708090a0b0c0d0e0f
Message (M) : 000102030405060708090a0b0c0d0e0f10111213
AES-XCBC-MAC : 47f51b4564966215b8985c63055ed308
AES-XCBC-MAC-96: 47f51b4564966215b8985c63
Test Case #5 : AES-XCBC-MAC-96 with 32-byte input
Key (K) : 000102030405060708090a0b0c0d0e0f
Message (M) : 000102030405060708090a0b0c0d0e0f10111213141516171819
1a1b1c1d1e1f
AES-XCBC-MAC : f54f0ec8d2b9f3d36807734bd5283fd4
AES-XCBC-MAC-96: f54f0ec8d2b9f3d36807734b
Test Case #6 : AES-XCBC-MAC-96 with 34-byte input
Key (K) : 000102030405060708090a0b0c0d0e0f
Message (M) : 000102030405060708090a0b0c0d0e0f10111213141516171819
1a1b1c1d1e1f2021
AES-XCBC-MAC : becbb3bccdb518a30677d5481fb6b4d8
AES-XCBC-MAC-96: becbb3bccdb518a30677d548
Test Case #7 : AES-XCBC-MAC-96 with 1000-byte input
Key (K) : 000102030405060708090a0b0c0d0e0f
Message (M) : 00000000000000000000 ... 00000000000000000000
[1000 bytes]
The security provided by AES-XCBC-MAC-96 is based upon the strength of AES. At the time of this writing there are no practical cryptographic attacks against AES or AES-XCBC-MAC-96.
AES-XCBC-MAC-96 が提供するセキュリティは、AES の強度に基づいています。本書の執筆時点では、AES または AES-XCBC-MAC-96 に対する実用的な暗号解読攻撃は存在しません。
As is true with any cryptographic algorithm, part of its strength lies in the correctness of the algorithm implementation, the security of the key management mechanism and its implementation, the strength of the associated secret key, and upon the correctness of the implementation in all of the participating systems. This document contains test vectors to assist in verifying the correctness of AES-XCBC-MAC-96 code.
他の暗号アルゴリズムと同様に、その強度の側面は、アルゴリズム実装の正確性、鍵管理メカニズムとその実装のセキュリティ、関連する秘密鍵の強度、および参加するすべてのシステムにおける実装の正確性に依存します。本書には、AES-XCBC-MAC-96 コードの正確性を検証するのに役立つテストベクトルが含まれています。
IANA has assigned AH Transform Identifier 9 to AH_AES-XCBC-MAC. IANA has assigned AH/ESP Authentication Algorithm Value 9 to AES-XCBC-MAC.
IANA は、AH 変換識別子 9 を AH_AES-XCBC-MAC に割り当てています。また、IANA は、AH/ESP 認証アルゴリズム値 9 を AES-XCBC-MAC に割り当てています。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
IETF は、本書に記載された技術の実装または使用に関係すると主張される可能性のある知的財産権その他の権利の有効性もしくは範囲、またはそのような権利に基づくライセンスが利用可能であるか否かの範囲に関して、いかなる立場もとりません。また、そのような権利を特定するための努力を行ったことを示すものでもありません。標準化過程および標準関連の文書における権利に関する IETF の手順に関する情報は、BCP 11 に記載されています。公開のために利用可能にされた権利の主張のコピー、およびライセンスの保証、または本仕様の実装者もしくは利用者によるそのような所有権の使用に関する一般ライセンスもしくは許可を取得しようとした試みの結果は、IETF 事務局から入手できます。
Portions of this text were unabashedly borrowed from [HMAC-SHA].
本テキストの一部は、[HMAC-SHA] からそのまま借用されました。
Thanks to the XCBC-MAC authors for their expert advice and rapid response to our queries: to Phil Rogaway for providing values for the XCBC-MAC constants; and to John Black for detailed corrections to the algorithm specifications and for providing the test cases. Thanks also to Andrew Krywaniuk for insisting on (and providing wording for) a rationale for the 3-key approach.
我々の問い合わせに対して専門的なアドバイスと迅速な対応をしてくださった XCBC-MAC の著者たちに感謝します。特に、XCBC-MAC 定数の値を提供してくださった Phil Rogaway 氏、およびアルゴリズム仕様の詳細な修正とテストケースを提供してくださった John Black 氏に感謝します。また、3 鍵アプローチの理論的根拠を主張（および文言を提示）してくださった Andrew Krywaniuk 氏にも感謝します。
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)," November 2001. http://csrc.nist.gov/publications/fips/fips197/ fips-197.{ps,pdf}
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)," 2001年11月. http://csrc.nist.gov/publications/fips/fips197/fips-197.{ps,pdf}
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1998年11月.
[CBC-MAC-1] Black, J. and P. Rogaway, "CBC MACs for Arbitrary-Length Messages: The Three-Key Constructions," in M. Bellare, editor, Advances in Cryptology -- CRYPTO '00, volume 1880 of Lecture Notes in Computer Science, p. 0197, August 2000, Springer-Verlag. http://www.cs.ucdavis.edu/~rogaway/papers/3k.ps
[CBC-MAC-1] Black, J. and P. Rogaway, "CBC MACs for Arbitrary-Length Messages: The Three-Key Constructions," in M. Bellare, editor, Advances in Cryptology -- CRYPTO '00, volume 1880 of Lecture Notes in Computer Science, p. 0197, 2000年8月, Springer-Verlag. http://www.cs.ucdavis.edu/~rogaway/papers/3k.ps
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, 1998年11月.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997年3月.
[XCBC-MAC-1] Black, J. and P. Rogaway, "A Suggestion for Handling Arbitrary-Length Messages with the CBC MAC," NIST Second Modes of Operation Workshop, August 2001. http://csrc.nist.gov/encryption/modes/proposedmodes/ xcbc-mac/xcbc-mac-spec.pdf
[XCBC-MAC-1] Black, J. and P. Rogaway, "A Suggestion for Handling Arbitrary-Length Messages with the CBC MAC," NIST Second Modes of Operation Workshop, 2001年8月. http://csrc.nist.gov/encryption/modes/proposedmodes/xcbc-mac/xcbc-mac-spec.pdf
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, 1998年11月.
[CBC-MAC-2] Bellare, M., J. Kilian and P. Rogaway, "The Security of the Cipher Block Chaining Message Authentication Code," Journal of Computer and System Sciences (JCSS), Vol. 61, No. 3, December 2000, pp. 362-399. http://www.cse.ucsd.edu/users/mihir/papers/cbc.{ps,pdf}
[CBC-MAC-2] Bellare, M., J. Kilian and P. Rogaway, "The Security of the Cipher Block Chaining Message Authentication Code," Journal of Computer and System Sciences (JCSS), Vol. 61, No. 3, 2000年12月, pp. 362-399. http://www.cse.ucsd.edu/users/mihir/papers/cbc.{ps,pdf}
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, 1997年2月.
[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, 1998年11月.
[HANDBOOK] Menezes, A., P. Van Oorschot and S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997.
[HANDBOOK] Menezes, A., P. Van Oorschot and S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997.
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques," NIST Special Publication 800-38A, December 2001. http://csrc.nist.gov/publications/nistpubs/800-38a /sp800-38a.pdf
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques," NIST Special Publication 800-38A, 2001年12月. http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, 1996年10月.
[ROADMAP] Thayer, R., N. Doraswamy, and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[ROADMAP] Thayer, R., N. Doraswamy, and R. Glenn, "IP Security Document Roadmap", RFC 2411, 1998年11月.
[XCBC-MAC-2] Rogaway, Phil, email communications, October 2001.
[XCBC-MAC-2] Rogaway, Phil, email communications, 2001年10月.
Sheila Frankel NIST - National Institute of Standards and Technology 820 West Diamond Ave. Room 677 Gaithersburg, MD 20899
Sheila Frankel, NIST - National Institute of Standards and Technology, 820 West Diamond Ave., Room 677, Gaithersburg, MD 20899
Phone: +1 (301) 975-3297
EMail: sheila.frankel@nist.gov
Howard C. Herbert Intel Corporation Lan Access Division 5000 West Chandler Blvd. MS-CH7-404 Chandler, Arizona 85226
Howard C. Herbert, Intel Corporation, Lan Access Division, 5000 West Chandler Blvd., MS-CH7-404, Chandler, Arizona 85226
Phone: +1 (480) 554-3116
EMail: howard.c.herbert@intel.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文書とその翻訳は、コピーして他者に提供することができ、また、これについてコメントし、他の方法で説明し、またはその実装を支援する派生著作物は、いかなる制限も受けることなく、全体的または部分的に作成、コピー、公開、配布することができます。ただし、上記の著作権表示およびこの段落がすべてのコピーおよび派生著作物に含まれていることを条件とします。ただし、本文書自体は、インターネット標準プロセスの策定のために必要な場合を除き、インターネット学会（Internet Society）または他のインターネット関連団体への著作権表示または参照を削除するなどの方法で変更することはできません。この場合、インターネット標準プロセスで定義されている著作権の手順に従う必要があります。また、英語以外の言語に翻訳するために必要な場合も同様です。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限定的な許諾は永続的であり、インターネット学会またはその後継者もしくは譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文書およびここに含まれる情報は「現状有姿」で提供され、インターネット学会およびインターネットエンジニアリングタスクフォースは、明示的か黙示的かを問わず、ここにある情報の使用がいかなる権利も侵害しないという保証、または商品性や特定の目的に対する適合性の黙示的な保証を含むがこれらに限定されない、すべての保証を否認します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディタ機能の資金は、現在インターネット学会によって提供されています。