Network Working Group S. Frankel
Request for Comments: 3566 NIST
Category: Standards Track H. Herbert
Intel
September 2003
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.
版权所有（C）互联网协会（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算法的一种流行方法是将分组密码与密码分组链接（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
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
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算法的一种流行方法是将分组密码与密码分组链接（CBC）操作模式结合使用。经典的CBC-MAC算法虽然对预先选定的固定长度[CBC-MAC-2]的消息是安全的，但在不同长度的消息（如典型IP数据报[CBC-MAC-2，第5节]中发现的类型）中是不安全的。事实上，在给定前一条消息的MAC的情况下，为第二条消息生成伪造消息是微不足道的。[手册，第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].
本备忘录规定了在CBC模式[MODES]中使用AES[AES]以及一组扩展[XCBC-MAC-1]来克服此限制。这种新算法被命名为AES-XCBC-MAC-96。使用AES分组密码，增加了块大小（128位）和密钥长度（128位），使新算法能够承受密码分析技术和计算能力的不断进步。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提供的数据完整性和数据源身份验证取决于密钥的分发范围。如果密钥仅由源和目标知道，则该算法将为双方之间发送的数据报提供数据源身份验证和数据完整性。此外，只有具有相同密钥的一方才能验证散列。
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].
本文件中出现的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照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位密文。对于消息M，在b位分组密码上具有强制性10*填充的基本CBC-MAC[CBC-MAC-1，CBC-MAC-2]计算如下：
(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) 将单个1位附加到M。然后将最小数量的0位附加到M，使M的长度为b的倍数。[注：这是可用于CBC-MAC的几种填充方案中的一种。其他几种填充方案在[模式]中描述。]
(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) Define E[0] = 0x00000000000000000000000000000000
(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:XOR M[i]和E[i-1]，然后用密钥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
AES-XCBC-MAC-96算法是基本CBC-MAC的一种变体，具有强制性的10*填充；但是，AES-XCBC-MAC-96对于任意长度的消息是安全的。AES-XCBC-MAC-96计算需要大量加密操作；此加密必须使用具有128位密钥的AES完成。给定一个128位密钥K，AES-XCBC-MAC-96按如下方式计算消息M：
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:
由n个块组成，M[1]。。。M[n]，其中块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: K1 = 0x01010101010101010101010101010101 encrypted with Key K K2 = 0x02020202020202020202020202020202 encrypted with Key K K3 = 0x03030303030303030303030303030303 encrypted with Key K
(1) 从128位密钥K派生3个128位密钥（K1、K2和K3），如下所示：K1=0x01010101010101010101010101010101用密钥K加密K2=0x020202020202020202用密钥K加密K3=0x03030303030303030303003用密钥K加密
(2) Define E[0] = 0x00000000000000000000000000000000
(2) Define 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:XOR M[i]和E[i-1]，然后用密钥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位：用E[n-1]和密钥K2对M[n]进行异或，然后用密钥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) 用单个“1”位填充M[n]，然后是将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）使用E[n-1]和密钥K3对M[n]进行异或，然后使用密钥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=Constant1A用密钥K加密| Constant1B用密钥K加密。
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.
但是，第二次加密操作仅适用于密钥大于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位的固定密钥长度。不能支持128位以外的密钥长度（即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位密钥生成。AES-XCBC-MAC-96选择了后一种方法，因为它类似于IPsec中使用的其他身份验证程序。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位密钥。此密钥以及3个派生密钥（K1、K2和K3）不得用于算法中指定以外的其他目的。特别是，它们不应在其他加密设置中用作密钥。这种滥用将使认证算法的安全性失效。
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的弱密钥。这并不意味着弱键不存在。如果在某个时刻识别出AES-XCBC-MAC-96的一组弱密钥，则必须拒绝使用这些弱密钥，然后请求替换密钥或新协商的安全关联。
[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]中所述的128位值并在[XCBC-MAC-2]中进行验证而得出的。对于ESP或AH，必须支持使用前96位的截断值。发送时，截断的值存储在authenticator字段中。收到后，计算整个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加密操作，但这些操作可以针对每个密钥提前执行一次。
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提供，他用两个独立的实现对它们进行了验证。所有值都是十六进制数。
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 #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
测试用例#2:AES-XCBC-MAC-96带3字节输入键（K）：000102030405060708090a0b0c0d0e0f消息（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
测试用例#3:AES-XCBC-MAC-96带16字节输入键（K）：000102030405060708090a0b0c0d0e0f消息（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
测试用例#4:AES-XCBC-MAC-96，带20字节输入键（K）：000102030405060708090A0B0C0D0D0E0F消息（M）：000102030405060708090A0B0C0D0D0E0F1011113 AES-XCBC-MAC:47F51B4564966215B8985C6305ED308 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
测试用例#5:AES-XCBC-MAC-96，带32字节输入键（K）：000102030405060708090A0B0C0D0D0E0F消息（M）：0001020304050608090A0C0D0E0F101111213141516171819 1A1B1C1D11E1F AES-XCBC-MAC:F54F0EC8D2B9F3D3680734BD5283FD4 AES-XCBC-MAC-96:F54F0EC8D2B9F368077734B
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
测试用例#6:AES-XCBC-MAC-96，带34字节输入键（K）：000102030405060708090A0B0C0D0D0E0F消息（M）：000102030405060708090A0C0D0E0F101111213141516171819 1A1B1C1D1E1F1F1F2021 AES-XCBC-MAC:BECB3BCDB518A30677D54FB816B4D8 AES-XCBC-MAC-96:BECB3B3BCDB518A377D548
Test Case #7 : AES-XCBC-MAC-96 with 1000-byte input Key (K) : 000102030405060708090a0b0c0d0e0f Message (M) : 00000000000000000000 ... 00000000000000000000 [1000 bytes]
测试用例#7:AES-XCBC-MAC-96，带1000字节输入键（K）：000102030405060708090a0b0c0d0e0f消息（M）：00000000000000000000。。。00000000000000000000[1000字节]
AES-XCBC-MAC : f0dafee895db30253761103b5d84528f AES-XCBC-MAC-96: f0dafee895db30253761103b
AES-XCBC-MAC:f0dafee895db30253761103b5d84528f AES-XCBC-MAC-96:f0dafee895db30253761103b
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作者的专家建议和对我们查询的快速响应：感谢Phil Rogaway提供了XCBC-MAC常量的值；以及John Black，以获得对算法规范的详细更正，并提供测试用例。还要感谢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)," November 2001.
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.和R.Atkinson，“IP认证头”，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, August 2000,
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.和R.Atkinson，“IP封装安全有效负载（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.，“RFC中用于表示需求水平的关键词”，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, August 2001.
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.和R.Atkinson，“互联网协议的安全架构”，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, December 2000, 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.和R.Canetti，“HMAC：用于消息认证的键控哈希”，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.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[HANDBOOK] Menezes, A., P. Van Oorschot and S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997.
[手册]Menezes，A.，P.Van Oorschot和S.Vanstone，“应用密码学手册”，CRC出版社，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, December 2001.
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.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[ROADMAP] Thayer, R., N. Doraswamy, and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[路线图]Thayer，R.，N.Doraswamy和R.Glenn，“IP安全文档路线图”，RFC 24111998年11月。
[XCBC-MAC-2] Rogaway, Phil, email communications, October 2001.
[XCBC-MAC-2]Rogaway，Phil，电子邮件通信，2001年10月。
Sheila Frankel NIST - National Institute of Standards and Technology 820 West Diamond Ave. Room 677 Gaithersburg, MD 20899
Sheila Frankel NIST-美国国家标准与技术研究所西钻石大道820号马里兰州盖瑟斯堡677室20899
Phone: +1 (301) 975-3297
EMail: sheila.frankel@nist.gov
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
霍华德·C·赫伯特英特尔公司局域网接入部，钱德勒大道西5000号。MS-CH7-404亚利桑那州钱德勒85226
Phone: +1 (480) 554-3116
EMail: howard.c.herbert@intel.com
Phone: +1 (480) 554-3116
EMail: howard.c.herbert@intel.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（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.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
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编辑功能的资金目前由互联网协会提供。