Network Working Group D. McGrew Internet-Draft Cisco Systems, Inc. Intended status: Standards Track February 2007 Expires: August 5, 2007 Authenticated Encryption with AES-CBC and HMAC-SHA1 (and other generic combinations of ciphers and MACs) draft-mcgrew-aead-aes-cbc-hmac-sha-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). McGrew Expires August 5, 2007 [Page 1]
Internet-Draft AEAD-AES-CBC-HMAC-SHA1 February 2007 Abstract This document specifies algorithms for authenticated encryption with additional authenticated data (AEAD) that are based on the composition of the Advanced Encryption Standard (AES) in the Cipher Block Chaining (CBC) mode of operation for encryption, and the HMAC- SHA1 message authentication code (MAC). It also separately defines a generic composition method that can be used with other MACs and randomized ciphers. These algorithms are randomized, and thus are suitable for use with applications that cannot provide distinct nonces to each invocation of the AEAD encrypt operation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 2. A Generic Composition Method . . . . . . . . . . . . . . . . . 4 2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 5 3. AEAD_AES_CBC_128_HMAC_SHA1 . . . . . . . . . . . . . . . . . . 7 3.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Message Authentication . . . . . . . . . . . . . . . . . . 7 3.3. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 4. AEAD_AES_256_HMAC_SHA_256 . . . . . . . . . . . . . . . . . . 9 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 McGrew Expires August 5, 2007 [Page 2]
Internet-Draft AEAD-AES-CBC-HMAC-SHA1 February 2007 1. Introduction Authenticated encryption [BN00] is a form of encryption that, in addition to providing confidentiality for the plaintext that is encrypted, provides a way to check its integrity and authenticity. Authenticated encryption with Associated Data, or AEAD, adds the ability to check the integrity and authenticity of some associated data (also called "additional authenticated data") that is not encrypted. This document defines two AEAD algorithms, using the interface defined in [M07], based on AES and HMAC-SHA1, with key sizes of 128 bits and 256 bits. 1.1. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. McGrew Expires August 5, 2007 [Page 3]
Internet-Draft AEAD-AES-CBC-HMAC-SHA1 February 2007 2. A Generic Composition Method This section defines a particular "generic composition" method, using the the encrypt-then-MAC method defined in Section 4.3 of [AE]. The method describes how to make a randomized AEAD algorithm out of a randomized cipher, such as a block cipher mode of operation that uses a random initialization vector, and a MAC. 2.1. Encryption We briefly recall the interface defined in Section 2 of [M07]. The AEAD encryption algorithm takes as input four octet strings: a secret key K, a plaintext P, associated data A, and a nonce N. An authenticated ciphertext value is provided as output. The data in the plaintext are encrypted and authenticated, and the associated data are authenticated, but not encrypted. The AEAD encryption process is as follows, or uses an equivalent set of steps: 1. The secondary keys MAC_KEY and ENC_KEY are generated from the input key K as follows. Each of these two keys is an octet string. A. MAC_KEY consists of the first MAC_KEY_LEN octets of K, in order. B. ENC_KEY consists of the last ENC_KEY_LEN octets of K, in order. Here we denote the number of octets in the MAC_KEY as MAC_KEY_LEN, and the number of bits in ENC_KEY as ENC_KEY_LEN. 2. An Initialization Vector (IV) is generated uniformly at random, for use in the cipher. (Note that this IV is distinct from the nonce that may be provided as an input to the authenticated encryption operation.) 3. The plaintext P is encrypted using the cipher with ENC_KEY as the key, and the IV generated in the previous step. We denote the ciphertext output from this step as S, and it MUST include the IV as its prefix. 4. A message authentication code (MAC) is computed by applying the MAC to the following data, in order: A. the nonce N, B. the associated data A, McGrew Expires August 5, 2007 [Page 4]
Internet-Draft AEAD-AES-CBC-HMAC-SHA1 February 2007 C. the ciphertext S computed in the previous step D. the number of bits in N expressed as a 64-bit unsigned integer in network byte order, E. and the number of bits in A expressed as a 64-bit unsigned integer in network byte order. The string MAC_KEY is used as the MAC key. We denote the output of the MAC computed in this step as T. 5. The AEAD Ciphertext consists of the string S, with the string T appended to it. This Ciphertext is returned as the output of the AEAD encryption operation. The encryption process can be illustrated as follows. Here P, A, and C denote the AEAD plaintext, associated data, and ciphertext, respectively. S = ENC(ENC_KEY, P) T = MAC(MAC_KEY, N || A || S || len(N) || len(A)) C = S || T Here ENC(X,P) denotes the encryption of P using the cipher with the key X; recall that the IV is included in its output. The expression MAC(Y,M) denotes the application of the MAC to the message M, using the key Y. The concatenation of two octet strings A and B is denoted as A || B, and len(X) denotes the number of bits in the string X, expressed as an unsigned integer in network byte order. 2.2. Decryption The authenticated decryption operation has four inputs: K, N, and A, as defined above, and the Ciphertext C. It has only a single output, either a plaintext value P or a special symbol FAIL that indicates that the inputs are not authentic. The authenticated decryption algorithm takes is as follows, or uses an equivalent set of steps: 1. The secondary keys MAC_KEY and ENC_KEY are generated from the input key K as follows. Each of these two keys is an octet string. A. MAC_KEY consists of the first MAC_KEY_LEN octets of K, in order. McGrew Expires August 5, 2007 [Page 5]
Internet-Draft AEAD-AES-CBC-HMAC-SHA1 February 2007 B. ENC_KEY consists of the last ENC_KEY_LEN octets of K, in order. As above, we denote the number of octets in the MAC_KEY as MAC_KEY_LEN, and the number of bits in ENC_KEY as ENC_KEY_LEN. 2. The final T_LEN octets are stripped from C. Here T_LEN denotes the number of octets in the MAC, which is a fixed parameter of the AEAD algorithm. We denote the initial octets of C as S, and denote the final T_LEN octets as T. 3. The integrity and authenticity of N, A, and C are checked by computing MAC validation algorithm, using the same inputs as in Step 5 of the encryption operation. In the MAC-validation step, the message consists of N, A, the number of bits in N expressed as a 64-bit unsigned integer in network byte order, the number of bits in A expressed as a 64-bit unsigned integer in network byte order, as S, in that order. The value MAC_KEY is used as the key. The value T, from the previous step, is used as the correct MAC value for validation purposes. If the MAC-validation operation indicates that the MAC T is valid, then the processing is continued. Otherwise, all of the data used in the MAC validation are discard, and the AEAD decryption operation returns an indication that it failed, and the operation halts. 4. The value S is decrypted, using the first 128 bits of the ciphertext as the IV. The value ENC_KEY is used as the decryption key. 5. The plaintext value is returned.. The length of the ciphertext can be inferred from that of the plaintext. The number L of octets in the ciphertext is given by L = 16 * ( floor(M / 16) + 2) where M denotes the number of octets in the plaintext, and the function floor() rounds its argument down to the nearest integer. This fact is useful to applications that need to reserve space for a ciphertext within a message or data structure. McGrew Expires August 5, 2007 [Page 6]
Internet-Draft AEAD-AES-CBC-HMAC-SHA1 February 2007 3. AEAD_AES_CBC_128_HMAC_SHA1 This algorithm is randomized and stateless. It is based on the "generic composition" of CBC encryption with HMAC authentication, with the the encrypt-then-MAC method defined in Section 4.3 of [AE]. It uses the HMAC message authentication code [RFC2104] with the SHA-1 hash function [SHA1] to provide message authentication. Test cases for HMAC_SHA1 are provided in [RFC2202]. For encryption, it uses AES in the cipher block chaining (CBC) mode of operation as defined in Section 6.2 of [MODES], with the padding method defined by Appendix A of the same reference. The input key K is 36 octets long. 3.1. Encryption The AES CBC IV is 16 octets long. ENC_KEY_LEN is 16 octets. Prior to CBC encryption, the plaintext is padded by appending a single '1' bit to that data and then appending to the resulting string as few '0' bits as are necessary to make the number of bits in the plaintext into a multiple of 128. Note that padding MUST be added to the data; if the number of bits in the payload data is a multiple of 128, then 128 bits of padding will be added. The plaintext is then encrypted using AES-128 in CBC mode, using ENC_KEY as the key and the random IV. The IV is included in the ciphertext as its initial 16 octets. 3.2. Message Authentication HMAC-SHA1 is used as the MAC. MAC_KEY_LEN is 20 octets. The HMAC- SHA1 output is truncated to 16 octets, by stripping off the final four octets. 3.3. Decryption After CBC decryption, the padding is removed by deleting the final '1' bit and all of the following '0' bits. The remaining data forms the plaintext. The HMAC-SHA1 validation operation consists of computing the HMAC- SHA1 value of the message, truncating it to 16 octets by discarding the final four octets, then comparing that value with the MAC value. If values are not equal, then the message is rejected. Otherwise, it is accepted. The lengths of the inputs are restricted as follows: McGrew Expires August 5, 2007 [Page 7]
Internet-Draft AEAD-AES-CBC-HMAC-SHA1 February 2007 K_LEN is 36 octets, P_MAX is 2^64 - 1 octets, A_MAX is 2^64 - 1 octets, N_MIN is zero octets, N_MAX is 2^64 octets, and C_MAX is 2^64 + 47 octets. 3.4. Test Cases A future version of this document will include test cases. McGrew Expires August 5, 2007 [Page 8]
Internet-Draft AEAD-AES-CBC-HMAC-SHA1 February 2007 4. AEAD_AES_256_HMAC_SHA_256 AEAD_AES_CBC_256_HMAC_SHA_256 is like AEAD_AES_CBC_128_HMAC_SHA1, with the following differences: AES-256 is used instead of AES-128. HMAC-SHA-256 is used instead of HMAC-SHA1. ENC_KEY_LEN and MAC_KEY_LEN are each 32 octets. The input key length is 64 octets. McGrew Expires August 5, 2007 [Page 9]
Internet-Draft AEAD-AES-CBC-HMAC-SHA1 February 2007 5. Rationale The AEAD_AES_CBC_128_HMAC_SHA1 and AEAD_AES_CBC_256_HMAC_SHA_256 algorithms are intended for use in applications that make use of the AEAD interface. It is expected to be useful with cryptomodules that contain efficient implementations of AES-CBC and HMAC-SHA1, but which do not implement any other AEAD algorithms. They are not intended to replace existing uses of AES-CBC and HMAC-SHA1, except in those circumstances where the existing use is not sufficiently secure or sufficiently general-purpose. One advantage of these algorithms is that they are suitable for use in applications that cannot provide distinct nonces to each invocation of the AEAD encryption operation. In short, they can be used with zero-length nonces. However, the algorithms can accept nonces; this ensures that they can be used with applications that are designed to work primarily with algorithms that expect nonces. The nonce data is authenticated. McGrew Expires August 5, 2007 [Page 10]
Internet-Draft AEAD-AES-CBC-HMAC-SHA1 February 2007 6. Security Considerations This initial version of this document has not been reviewed; regarding security, it should be considered guilty until proven innocent. Review has been requested from the IRTF Crypto Forum Research Group (CFRG). The algorithms defined in this document use the "generic composition" of CBC encryption with HMAC authentication, with the encrypt-then-MAC method defined in Section 4.3 of [AE]. This method has sound and well-understood security properties; for details, please see that reference. As with any block cipher mode of operation, the security of AES-CBC degrades as the amount of data that is process increases. Each fixed key value SHOULD NOT be used to protect more than 2^64 bytes of data. This limit ensures that the AES-CBC algorithm will stay under the "birthday bound", i.e., that it is unlikely that there will be two AES plaintext inputs that are equal. (If this event occurs, information about the colliding plaintexts is leaked, so it is desirable to bound the amount of plaintext processed in order to make it unlikely.) The nonce data is authenticated, as is expected in [M07]. The lengths of the inputs and N and A are included in the MAC computation in order to prevent attacks in which an adversary constructs a forgery by manipulating N, A, and C in such a way that N || A | C are unchanged. McGrew Expires August 5, 2007 [Page 11]
Internet-Draft AEAD-AES-CBC-HMAC-SHA1 February 2007 7. References 7.1. Normative References [M07] McGrew, D., "An Interface and Registry for Authenticated Encryption with Associated Data", Internet Draft (approved for RFC) draft-mcgrew-auth-enc-05.txt, November 2007. [MODES] Dworkin, M., "NIST Special Publication 800-38: Recommendation for Block Cipher Modes of Operation", U.S. National Institue of Standards and Technology http:// csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- SHA-1", RFC 2202, September 1997. [SHA1] "FIPS 180-1: Secure Hash Standard,", Federal Information Processing Standard (FIPS) http://www.itl.nist.gov/fipspubs/fip180-1.htm. 7.2. Informative References [AE] "Authenticated encryption: Relations among notions and analysis of the generic composition paradigm", Proceedings of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531-545 http://www. [BN00] "Authenticated encryption: Relations among notions and analysis of the generic composition paradigm", Proceedings of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531- 545 http://www-cse.ucsd.edu/users/mihir/papers/oem.html. McGrew Expires August 5, 2007 [Page 12]
Internet-Draft AEAD-AES-CBC-HMAC-SHA1 February 2007 Author's Address David A. McGrew Cisco Systems, Inc. 510 McCarthy Blvd. Milpitas, CA 95035 US Phone: (408) 525 8651 Email: mcgrew@cisco.com URI: http://www.mindspring.com/~dmcgrew/dam.htm McGrew Expires August 5, 2007 [Page 13]
Internet-Draft AEAD-AES-CBC-HMAC-SHA1 February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). McGrew Expires August 5, 2007 [Page 14]