Internet Draft J. Walker, Intel September 2001 R. Moskowitz, TruSecure Expiration Date: April 2002 The AES128 CTR Mode of Operation and Its Use With IPsec draft-moskowitz-aes128-ctr-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Table of Contents 1. Abstract...........................................................1 2. Conventions used in this document..................................2 3. Introduction.......................................................2 4. CTR rules in ESP...................................................3 4.1. Padding..........................................................3 4.2. The Counter......................................................3 4.3. Keying Material for AES128-CTR...................................4 4.4. Data Authenticity for AES128-CTR.................................4 5. Security Considerations............................................4 6. IANA Considerations................................................5 7. ICANN Considerations...............................................5 8. References.........................................................5 9. Acknowledgments....................................................5 APPENDIX A. Test Vectors for AES128 CTR Mode..........................5 11. Author's Address..................................................8 16. Copyright Statement...............................................9 1. Abstract This document describes the use of the AES Cipher Algorithm with 128 bit key in Counter (CTR) Mode, with an implicit counter, as a Moskowitz, Walker 1 INTERNET DRAFT September 2001 confidentiality mechanism within the context of the IPsec Encapsulating Security Payload [ESP]. CTR is a parallelizable block-cipher mode of operation. It uses the underlying block cipher as a stream cipher. Accordingly, great care must be exercised to utilize it appropriately within IPsec. 2. 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 [RFC-2119]. 3. Introduction Counter mode (CTR) is a block-cipher mode of operation. It uses a block cipher as a stream cipher. Although it has not yet been standardized, it is one of the oldest modes of operation. It is particularly easy to implement, and parallelizable. The size of the generated ciphertext increases only by the size of the counter value over that for the plaintext. Furthermore, it only uses the block cipher encryption primitive for both encryption and decryption. Counter mode also guarantees a high level of privacy when the underlying block cipher does and it is used correctly. Thus, counter mode has many properties that make it attractive for use with AES and high-speed networking. Counter mode also has properties that render it harder to use than other modes of operation. Being a stream cipher, any reuse of the counter (from which the mode is named) with the same key is catastrophic, in that it immediately leaks information about the encrypted plaintext. Hence it is inappropriate to use this mode of operation with statically configured keys, unless the implementation takes extraordinary measures to prevent reuse of a counter value with the key. Also, it is trivial to use any valid ciphertext to forge other valid ciphertexts, so it is equally catastrophic to use the mode of operation without message authentication. Counter mode is easy to describe abstractly. Assume the cipher block E uses a block size of B bits; for AES, B = 128. The encrypting party establishes a counter C when the session key is fixed: C := 0 To encrypt a message M, the sender partitions M into B-bit blocks M = M[1] M[2] à M[n-1] M[n]. Each block of M is then XORÆd with an encrypted counter value: C[0] := C for i := 1 to n-1 do C := C + 1 Walker, Moskowitz 2 INTERNET DRAFT September 2001 C[i] := M[i] XOR E(C) C := C + 1 C[n] := M[n] XOR Chop(E(C)) output C[0] C[1] à C[n] as the ciphertext Here, if block M[n] consists of k bits, the function Chop() truncates its argument to the k most significant bits. To decrypt a counter mode-encrypted ciphertext C[0] C[1] à C[n], this process is reversed: C := C[0] for i := 1 to n-1 do C := C + 1 M[i] := C[i] XOR E(C) C := C + 1 M[n] := C[n] XOR Chop(E(C)) output M[1] à M[n] as the recovered plaintext 4. CTR rules in ESP For CTR to be used in ESP, four factors MUST be standardize. These are the padding rules, the construction of the counter, the keying material, and data authentication. 4.1. Padding CTR mode does not require padding of the cleartext. However, ESP does. ESP uses padding to 32-bit word-align the authentication data. The padding, Pad Length, and the Next Header MUST be concatenated with the cleartext before encrypting, as per ESP rules. 4.2. The Counter Each ESP datagram must convey the counter used to encrypt the payload. When AES is used as the block cipher, the counter consists of 128 bits. This specification defines the CTR mode counter implicitly: Counter ::= (0x0000000000000 || SPI || Seq# || 0x000) where SPI identifies the security association, Seq# is the ESP sequence number, represented as a big-Endian integer value, and the 12 least significant bits of the counter begins with the value 0, again represented as a big-Endian integer value. The first 128-bit block of the datagram plaintext is encrypted by XORing the plaintext block with the value AES(Counter+1), the second by XORing the second block of plaintext with AES(Counter+2), etc. This construction permits each datagram to consist of up to 2^12 = 4096 128-bit blocks, or 65536 bytes of total encrypted data, including padding. Walker, Moskowitz 3 INTERNET DRAFT September 2001 4.3. Keying Material for AES128-CTR Provide the 128 most-significant bits as the encryption key size to the keying material extraction process. The remaining bits are applied to the ESP authentication method. 4.4. Data Authenticity for AES128-CTR Since it is trivial to construct one valid ciphertext from any other valid ciphertext when counter mode is used, implementations MUST require the use of a non-NULL ESP authentication method with counter mode. 5. Security Considerations When used properly, AES-CTR mode provides strong confidentiality guarantees. Bellare et. al. show in [MODES] that the privacy guarantees under counter mode are at least as strong as those for CBC mode when using the same block cipher for both. However, it is very easy to misuse this construction. If a counter value is ever reused with a key, the confidentiality guarantees are voided. This is very easy to see: if the same counter value i is used to encrypt two plaintexts P[1] and P[2], then it is trivial to recover information about the plaintexts: C[i] := E(i) C[1] := P[1] XOR C[i] C[2] := P[2] XOR C[i] C[1] XOR C[2] = (P[1] XOR C[i]) XOR (P[2] XOR C[i]) = P[1] XOR P[2] Practically, this implies this mode of operation should not be used with statically configured keys. ESP implementations therefore SHOULD NOT support CTR mode with statically configured keys; if it does, the implementation MUST take other precautions to assure the implementation will never reuse a counter value with a key. Similarly, data forgery is trivial with CTR mode. The argument is very similar to the privacy case: if a known plaintext P[1] is counter mode encrypted under i, then it can be replaced with plaintext P[2], since C[i] := E(i) C[1] := P[1] XOR C[i] C[2] = (P[2] XOR P[1]) XOR C[1] Accordingly, implementations MUST NOT allow the use of CTR mode without ESP authentication. Walker, Moskowitz 4 INTERNET DRAFT September 2001 6. IANA Considerations IANA has assigned ESP transform number XX to AES128-CTR. 7. ICANN Considerations There are no ICANN considerations here. 8. References [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [ESP], Kent, S., and Atkinson, R., "IP Encapsulating Security Payload", RFC 2406, November 1998. [MENEZES], Menezes, A., van Oorschot, P., and Vanstone, S., "Handbook of Applied Cryptography", CRC Press, 1997. [MODES], Bellare, M, Desai, A., Jokipii, E., and Rogaway, P., ôA Concrete Security Treatment of Symmetric Encryption: Analysis of the DES Modes of Operationô, Proceedings 38th Annual Symposium on Foundations of Computer Science, 1997 9. Acknowledgments TBS APPENDIX A. Test Vectors for AES128 CTR Mode The following test vectors were computed using the algorithm from Section 3 above. The counter value was constructed as in Section 4.2. These two conditions mean the counter value is incremented and then transformed into a Big-Endian value prior to encryption. key = 00000000000000000000000000000000 counter = 1000 plaintext = 00000000000000000000000000000000 ciphertext = 8eaedd7f7b46339c7589ae9d73498648 key = c34c052cc0da8d73451afe5f03be297f counter = 2000 plaintext = 8eaedd7f7b46339c7589ae9d73498648 ciphertext = be70f1bd31cf5671269ef79935d7e58b key = c98d5fb63b68c027e88317d8233c5b9d counter = 3000 plaintext = be70f1bd31cf5671269ef79935d7e58b Walker, Moskowitz 5 INTERNET DRAFT September 2001 ciphertext = db7a53c1fe52d21a25048df2e0ef5684 key = 6a5964499d35cea7e1ac707b37b923ed counter = 4000 plaintext = db7a53c1fe52d21a25048df2e0ef5684 ciphertext = 0293c3e5e8f70561eb875bfd1e8ccd9d key = 5f060d3716b345c253f6749abac10917 counter = 5000 plaintext = 0293c3e5e8f70561eb875bfd1e8ccd9d 00000000000000000000000000000000 ciphertext = f86217238848f2428924a5e23a30d41e fda94a058c491959ca2bc0b546c612b1 key = f3ce6e546edba6223b2489f48fc94c5d counter = 6000 plaintext = f86217238848f2428924a5e23a30d41e fda94a058c491959ca2bc0b546c612b1 ciphertext = e18800d55abfa320e7688f847c765fe6 e61d9e4035caf76839ce1f3f5666d432 key = 9591f146c6ff55f71138f822aec4182d counter = 7000 plaintext = e18800d55abfa320e7688f847c765fe6 e61d9e4035caf76839ce1f3f5666d432 ciphertext = 1bde1ed88f361135eb0af3aac4f04695 f714185babc5f7f1b373d7a534a67a3d key = 0eb6c75b7a7103eff9d178145b69589d counter = 8000 plaintext = 1bde1ed88f361135eb0af3aac4f04695 f714185babc5f7f1b373d7a534a67a3d ciphertext = 40a828ac02241e92677754784010ad83 85a6c61123e66b50bb1ed9c1894e3b6d key = 2f6f7a25c070604d6a23ad786a05e5ab counter = 9000 plaintext = 40a828ac02241e92677754784010ad83 85a6c61123e66b50bb1ed9c1894e3b6d 00000000000000000000000000000000 00000000000000000000000000000000 ciphertext = a306bd9d74436128027eac3f80c60a55 e32ed7e95ec3bf14542c594c24191fc5 1bb2bba73511d1195d65109ce2c08aaf d1362f2c8ee6a438ee996f7ec9aa6ef6 key = 11ef4d8c58fe48b2ebd10a6d20c87415 counter = a000 plaintext = a306bd9d74436128027eac3f80c60a55 e32ed7e95ec3bf14542c594c24191fc5 1bb2bba73511d1195d65109ce2c08aaf d1362f2c8ee6a438ee996f7ec9aa6ef6 ciphertext = da6816cc4bdbc9e70f182e2ef003764a Walker, Moskowitz 6 INTERNET DRAFT September 2001 bc6cc452169986c1aab6bab49a7cfb8c 2dea11fc8031110fffc699e3286f14f8 62945e21dc2d9a3bf566f20dea27fd0a key = 10a1acc3425688664fab789cb73ca8a5 counter = b000 plaintext = da6816cc4bdbc9e70f182e2ef003764a bc6cc452169986c1aab6bab49a7cfb8c 2dea11fc8031110fffc699e3286f14f8 62945e21dc2d9a3bf566f20dea27fd0a ciphertext = 84f937044a5aa566a5d1792e0591609a 36cd91ddc2a78d9c7e58d030cd81bf13 d38385e80804f15ca51cf219918c1c44 1d1491689e9264edaf40e3a56c052e39 key = 1bf58c409996b2f0e5abb93919646154 counter = c000 plaintext = 84f937044a5aa566a5d1792e0591609a 36cd91ddc2a78d9c7e58d030cd81bf13 d38385e80804f15ca51cf219918c1c44 1d1491689e9264edaf40e3a56c052e39 ciphertext = 6a8888ff1501f99ed8a23426ffebb918 b12b4a52e801a79a3984208577ea0aba 6909a93e7d9186af2b7f2d39283e8ad1 479a1979b53a3bbe0e293e3535c433c8 key = 68b539de87ad0bd1f94adecbc7d9d1c4 counter = d000 plaintext = 6a8888ff1501f99ed8a23426ffebb918 b12b4a52e801a79a3984208577ea0aba 6909a93e7d9186af2b7f2d39283e8ad1 479a1979b53a3bbe0e293e3535c433c8 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 ciphertext = 87849e665e824d5b63ebcdd2f3e5f8d9 7fca7d994f32bd625c8045b6adad1bbf d62794d947ac071f9d1891a2ef7b041c 43b2840a5d86c3294d996b2e08fe8b66 5dce18e88feca383914967de9770de83 c25102a433467d712a0c75cb1a537c0a 8d8bf7452eb508cb108042f46f3c04e6 173d915cbf1fa272273e56f09ac34353 key = 0f5566ab94f6a3e53287113baf8dca7a counter = e000 plaintext = 87849e665e824d5b63ebcdd2f3e5f8d9 7fca7d994f32bd625c8045b6adad1bbf d62794d947ac071f9d1891a2ef7b041c 43b2840a5d86c3294d996b2e08fe8b66 5dce18e88feca383914967de9770de83 c25102a433467d712a0c75cb1a537c0a Walker, Moskowitz 7 INTERNET DRAFT September 2001 8d8bf7452eb508cb108042f46f3c04e6 173d915cbf1fa272273e56f09ac34353 ciphertext = 54114ffde7ef68e65861557d8d29949e 9e5d369d566217dd7e86eee61504099f 05242d6d1a8c6f1bb747361e145f64ac a8cf780493ab5e26156c11e5cc9c9853 29688343a3b73a68acaeb50dc144c938 e9d6e8cd8f20c5bd18c001900d49a0bd 409cd49bc4f08873231eb345328ed32c 514be68d572ff3f53fbe92f1c8de23d1 key = 8480339a9135f39e3880ec88fe3f9135 counter = f000 plaintext = 54114ffde7ef68e65861557d8d29949e 9e5d369d566217dd7e86eee61504099f 05242d6d1a8c6f1bb747361e145f64ac a8cf780493ab5e26156c11e5cc9c9853 29688343a3b73a68acaeb50dc144c938 e9d6e8cd8f20c5bd18c001900d49a0bd 409cd49bc4f08873231eb345328ed32c 514be68d572ff3f53fbe92f1c8de23d1 ciphertext = 8e98f31a8c36a2189c45d2cc820c91e5 2289d925838a0caeb598d5ee82ea9e76 cf5e414bdba0f8a33f0df20ce37aba97 a4a787412871120a36ec7ddb44823e5b 3cf23e687d5995c3ac2ddd74f68d489c f7dd8c73e4506d6fd7f22d7b84900589 0494c0bfe59a879dd5e75c7a7ae32e19 e16528837b102df9f3004d48a4eed298 key = e01f358504f55405eb8682771b8ded9e counter = 10000 plaintext = 8e98f31a8c36a2189c45d2cc820c91e5 2289d925838a0caeb598d5ee82ea9e76 cf5e414bdba0f8a33f0df20ce37aba97 a4a787412871120a36ec7ddb44823e5b 3cf23e687d5995c3ac2ddd74f68d489c f7dd8c73e4506d6fd7f22d7b84900589 0494c0bfe59a879dd5e75c7a7ae32e19 e16528837b102df9f3004d48a4eed298 ciphertext = 1d3389c2986ee4f53346ddc8a1539562 e58e6f8ba0a78cd6de78579caac8b632 4f5611959f6071a4700245e4500516db 11e8f73c8588f109557e9a60f1bc8757 946184932bce426376844ec72a124b3e 0f4917f01b13b34a16757c4f8348d90b 00e53f7777ce7889f2d90716add0eaed a950aefa0ac515c8955050366194fee3 11. Author's Address Walker, Moskowitz 8 INTERNET DRAFT September 2001 Robert Moskowitz TruSecure Corporation 1200 Walnut Bottom Rd. Carlisle, PA 17013 Email: rgm@trusecure.com Jesse Walker Intel Corporation 2111 N.E. 25th Avenue Hillsboro, Oregon 97229 Email: jesse.walker@intel.com 16. Copyright Statement Copyright (c) The Internet Society (2001). All Rights Reserved. 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. Walker, Moskowitz 9