RFC 3686
Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)
RFC 3686 💖 Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)
okay bestie, this one is RFC 3686 🎀 and it's giving "how to use AES-CTR inside IPsec ESP without breaking everything." 💅
It was written by R. Housley from Vigil Security ✨ and it came out in January 2004 📅. It's a Standards Track document 🔥, which means it's a real protocol spec, not just vibes. The header doesn't list anything it obsoletes or updates, so it's not replacing or patching any other RFC 🌸.
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.
Copyright Notice 🌈
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract 💜
This document describes the use of Advanced Encryption Standard (AES) Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism. So basically it's AES-CTR as the encryption part of ESP, with the IV sent along explicitly 🦋.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used In This Document. . . . . . . . . . . . 2
2. AES Block Cipher . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Counter Mode . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Key Size and Rounds. . . . . . . . . . . . . . . . . . . 5
2.3. Block Size . . . . . . . . . . . . . . . . . . . . . . . 5
3. ESP Payload. . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Initialization Vector. . . . . . . . . . . . . . . . . . 6
3.2. Encrypted Payload. . . . . . . . . . . . . . . . . . . . 6
3.3. Authentication Data. . . . . . . . . . . . . . . . . . . 6
4. Counter Block Format . . . . . . . . . . . . . . . . . . . . . 7
5. IKE Conventions. . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Keying Material and Nonces . . . . . . . . . . . . . . . 8
5.2. Phase 1 Identifier . . . . . . . . . . . . . . . . . . . 9
5.3. Phase 2 Identifier . . . . . . . . . . . . . . . . . . . 9
5.4. Key Length Attribute . . . . . . . . . . . . . . . . . . 9
6. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
10. Intellectual Property Statement. . . . . . . . . . . . . . . . 16
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 191. Introduction 🦋
okay so the National Institute of Standards and Technology (NIST) recently picked the Advanced Encryption Standard (AES) [AES], also known as Rijndael 👑. AES is a block cipher and it can be used in lots of different modes. This doc is about AES Counter Mode (AES-CTR), with an explicit initialization vector (IV), used as the IPsec Encapsulating Security Payload (ESP) [ESP] confidentiality mechanism 🔐.
This doc doesn't give you an overview of IPsec 🙈. If you want to know how all the IPsec pieces work together to provide security services, that lives in [ARCH] and [ROADMAP] 📚.
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 [STDWORDS] 📝.
2. AES Block Cipher 🎀
This section is a quick run-through of the parts of the AES block cipher that matter here 💅. It also covers implementation requirements.
2.1. Counter Mode
NIST has defined five modes of operation for AES and other FIPS-approved block ciphers [MODES] 🌸. Each mode has its own characteristics. The five are ECB (Electronic Code Book), CBC (Cipher Block Chaining), CFB (Cipher FeedBack), OFB (Output FeedBack), and CTR (Counter).
Only AES Counter mode (AES-CTR) is discussed in this spec. AES-CTR needs the encryptor to make a unique value for every packet and send that value to the decryptor. This spec calls that per-packet value an initialization vector (IV) 🦋. The same IV and key combination MUST NOT be used more than once. The encryptor can make the IV in any way that keeps it unique. Common ways to do that include incrementing a counter for each packet and using linear feedback shift registers (LFSRs) ✨.
This spec also uses a nonce for extra protection against precomputation attacks 🛡️. The nonce value doesn't have to be secret. However, the nonce MUST be unpredictable before the IPsec security association that uses AES-CTR is set up 🙅♀️.
AES-CTR has a bunch of properties that make it really attractive for high-speed networking 🚀. It uses the AES block cipher to build a stream cipher. Data gets encrypted and decrypted by XORing it with the key stream, which is made by AES-encrypting sequential counter block values. AES-CTR is easy to implement, it can be pipelined and parallelized, and it also supports key stream precomputation 🔥.
Pipelining works because AES has multiple rounds (see section 2.2) 🌀. A hardware implementation (and some software ones) can make a pipeline by unrolling the loop that comes from this round structure. For example, once one 16-octet block has gone in, another 16-octet block can go in one round later, and so on. In AES-CTR, those inputs are the sequential counter block values used to make the key stream.
You can also use several independent AES encrypt implementations to go faster 🏎️. For example, you could run two AES encrypt implementations in parallel on a sequence of counter block values, which doubles the effective throughput.
The sender can precompute the key stream. Since the key stream doesn't depend on any data in the packet, it can be precomputed once the nonce and IV are assigned, and that can cut down packet latency ⏱️. The receiver can't do the same precomputation, because the IV won't be known until the packet arrives.
AES-CTR only uses the AES encrypt operation (for both encryption and decryption), so AES-CTR implementations end up smaller than implementations of a lot of other AES modes 🧚.
When it's used correctly, AES-CTR gives a high level of confidentiality 🔒. The problem is it's really easy to use incorrectly 😭. Because it's a stream cipher, reusing the per-packet value (the IV) with the same nonce and key is catastrophic 💀. An IV collision leaks information about the plaintext in both packets right away. For that reason, it's inappropriate to use this mode with static keys. You'd need extraordinary measures to stop an IV value from being reused with the static key across power cycles. To be safe, implementations MUST use fresh keys with AES-CTR 🔑. The Internet Key Exchange (IKE) [IKE] protocol can be used to set up fresh keys, and IKE can also provide the nonce value 🤝.
With AES-CTR, it's trivial to use a valid ciphertext to forge other ciphertexts that are valid to the decryptor. So using AES-CTR without a companion authentication function is just as catastrophic 😱. Implementations MUST use AES-CTR together with an authentication function, such as HMAC-SHA-1-96 [HMAC-SHA] 🫶.
To encrypt a payload with AES-CTR, the encryptor splits the plaintext, PT, into 128-bit blocks. The final block doesn't need to be 128 bits. It can be shorter 🍓.
PT = PT[1] PT[2] ... PT[n]Each PT block gets XORed with a block of the key stream to make the ciphertext, CT. AES-encrypting each counter block gives you 128 bits of key stream. The most significant 96 bits of the counter block are set to the nonce value, which is 32 bits, followed by the per-packet IV value, which is 64 bits. The least significant 32 bits of the counter block start out set to one. That counter goes up by one to make each next counter block, and each one gives another 128 bits of key stream. Encrypting n plaintext blocks looks like this:
CTRBLK := NONCE || IV || ONE
FOR i := 1 to n-1 DO
CT[i] := PT[i] XOR AES(CTRBLK)
CTRBLK := CTRBLK + 1
END
CT[n] := PT[n] XOR TRUNC(AES(CTRBLK))The AES() function does AES encryption with the fresh key 🔐.
The TRUNC() function cuts the output of the AES encrypt operation down to the same length as the final plaintext block, keeping the most significant bits ✂️.
Decryption is basically the same thing. Decrypting n ciphertext blocks goes like this:
CTRBLK := NONCE || IV || ONE
FOR i := 1 to n-1 DO
PT[i] := CT[i] XOR AES(CTRBLK)
CTRBLK := CTRBLK + 1
END
PT[n] := CT[n] XOR TRUNC(AES(CTRBLK))2.2. Key Size and Rounds
AES supports three key sizes: 128 bits, 192 bits, and 256 bits 🗝️. The default key size is 128 bits, and all implementations MUST support this key size. Implementations MAY also support 192-bit and 256-bit keys ✨.
AES uses a different number of rounds for each key size. With a 128-bit key, implementations MUST use 10 rounds. With a 192-bit key, implementations MUST use 12 rounds. With a 256-bit key, implementations MUST use 14 rounds 🔥.
2.3. Block Size
AES has a block size of 128 bits (16 octets) 🧩. So when you use AES-CTR, each AES encrypt operation makes 128 bits of key stream. AES-CTR encryption is the XOR of the key stream with the plaintext, and AES-CTR decryption is the XOR of the key stream with the ciphertext. If the key stream is longer than the plaintext or ciphertext, the extra bits just get thrown away 🗑️. That means AES-CTR doesn't need the plaintext padded to a multiple of the block size. However, to give limited traffic flow confidentiality, padding MAY be included, as specified in [ESP] 🌈.
3. ESP Payload 🧚
The ESP payload is the IV followed by the ciphertext 💜. The payload field, as defined in [ESP], is laid out like Figure 1 🦋.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Encrypted Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1. ESP Payload Encrypted with AES-CTR 🎀
3.1. Initialization Vector 🎀
The AES-CTR IV field MUST be eight octets, so it's always 8 bytes, no more, no less 💅. The IV MUST be chosen by the encryptor in a way that makes sure the same IV value is used only once for a given key 🔐. The encryptor can make the IV any way it likes, as long as it stays unique ✨. Common approaches include incrementing a counter for each packet and using linear feedback shift registers (LFSRs) 🧚.
Including the IV in each packet is the real MVP here 👑. It means the decryptor can still generate the key stream it needs to decrypt, even when some packets get lost or show up out of order 🙌.
3.2. Encrypted Payload 🌸
The encrypted payload is where the ciphertext lives 💜.
AES-CTR mode does not need plaintext padding, which is so convenient 🙈. However, ESP does need padding to 32-bit word-align the authentication data, so it's not a total free pass 💀. The padding, Pad Length, and the Next Header MUST be concatenated with the plaintext before encryption happens, as described in [ESP] 🫶.
3.3. Authentication Data 🔥
Okay, this one is so important bestie. Since it is trivial to build a forged AES-CTR ciphertext from a valid one, AES-CTR implementations MUST employ a non-NULL ESP authentication method 😭. HMAC-SHA-1-96 [HMAC-SHA] is a likely choice 🦋.
Don't skip the authentication step. Without it, anyone could whip up a fake ciphertext and it would be a total disaster 💀🚨.
4. Counter Block Format ✨
Every packet carries the IV that's needed to build the sequence of counter blocks, and those blocks are what generate the key stream used to decrypt the payload 🔑. The AES counter block cipher block is 128 bits 🎀. Here's what the counter block looks like 👇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector (IV) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2. Counter Block Format
Here's the breakdown of the counter block pieces 🧁:
- Nonce: The Nonce field is 32 bits. As the name suggests, the nonce is a single use value 🎟️. That means a fresh nonce value MUST be assigned for each security association, and it MUST be assigned at the very beginning of that security association 🌈. The nonce value doesn't need to be secret, but it MUST be unpredictable before the security association begins 🔮.
- Initialization Vector: The IV field is 64 bits 🦄. As described in section 3.1, the IV MUST be chosen by the encryptor in a way that ensures the same IV value is used only once for a given key 🔐.
- Block Counter: The block counter field is the least significant 32 bits of the counter block 🔢. It begins with the value of one, and it gets incremented to generate the later portions of the key stream ⭐. The block counter is a 32-bit big-endian integer value 💅.
Using the encryption process described in section 2.1, this construction lets each packet hold up to:
(2^32)-1 blocks = 4,294,967,295 blocks
= 68,719,476,720 octetsThat's a LOT of key stream per packet 😭. It can produce enough key stream for each packet to handle any IPv6 jumbogram [JUMBO] 🐋.
5. IKE Conventions 🧚
This section explains the conventions for generating keying material and nonces for use with AES-CTR through the Internet Key Exchange (IKE) [IKE] protocol 🔑. It also defines the identifiers and attributes you need to negotiate a security association that uses AES-CTR 🤝.
5.1. Keying Material and Nonces 🌸
As described in section 2.1, implementations MUST use fresh keys with AES-CTR 🗝️. IKE can be used to establish those fresh keys 💖. This section describes how to get the unpredictable nonce value from IKE. Note that this convention gives you a nonce that is secret as well as unpredictable 🤫.
IKE uses a pseudo-random function (PRF) to derive keying material 🎲. The PRF gets used iteratively to derive keying material of arbitrary size, which is called KEYMAT 🔁. Keying material gets pulled out of the output string without regard to boundaries 🍓.
The size of the requested KEYMAT MUST be four octets longer than what's needed for the associated AES key 📏. Here's how the keying material gets used:
AES-CTR with a 128 bit key 🩷 The KEYMAT requested for each AES-CTR key is 20 octets. The first 16 octets are the 128-bit AES key, and the remaining four octets are used as the nonce value in the counter block.
AES-CTR with a 192 bit key 💜 The KEYMAT requested for each AES-CTR key is 28 octets. The first 24 octets are the 192-bit AES key, and the remaining four octets are used as the nonce value in the counter block.
AES-CTR with a 256 bit key 🌈 The KEYMAT requested for each AES-CTR key is 36 octets. The first 32 octets are the 256-bit AES key, and the remaining four octets are used as the nonce value in the counter block.
5.2. Phase 1 Identifier 🙃
This document does not specify the conventions for using AES-CTR in IKE Phase 1 negotiations 🚫. If you want AES-CTR to work that way, a separate specification is needed, and an Encryption Algorithm Identifier needs to be assigned 📝.
5.3. Phase 2 Identifier 🎀
For IKE Phase 2 negotiations, IANA has assigned an ESP Transform Identifier of 13 for AES-CTR with an explicit IV 🦋.
5.4. Key Length Attribute 📏
Since AES supports three key lengths, the Key Length attribute MUST be specified in the IKE Phase 2 exchange [DOI] 💅. The Key Length attribute MUST have a value of 128, 192, or 256 🔥.
6. Test Vectors 🧪✨
okay so this section is literally a gift 🎁 It has nine test vectors that you can use to check whether your AES-CTR implementation is actually doing its thing. Vectors #1 to #3 use AES with a 128-bit key, #4 to #6 use a 192-bit key, and #7 to #9 use a 256-bit key. Think of them as a little answer key for your code 💅
Test Vector #1: Encrypting 16 octets using AES-CTR with 128-bit key 🌸
AES Key : AE 68 52 F8 12 10 67 CC 4B F7 A5 76 55 77 F3 9E
AES-CTR IV : 00 00 00 00 00 00 00 00
Nonce : 00 00 00 30
Plaintext String : 'Single block msg'
Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67
Counter Block (1): 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 01
Key Stream (1): B7 60 33 28 DB C2 93 1B 41 0E 16 C8 06 7E 62 DF
Ciphertext : E4 09 5D 4F B7 A7 B3 79 2D 61 75 A3 26 13 11 B8Test Vector #2: Encrypting 32 octets using AES-CTR with 128-bit key 🦋
AES Key : 7E 24 06 78 17 FA E0 D7 43 D6 CE 1F 32 53 91 63
AES-CTR IV : C0 54 3B 59 DA 48 D9 0B
Nonce : 00 6C B6 DB
Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
Counter Block (1): 00 6C B6 DB C0 54 3B 59 DA 48 D9 0B 00 00 00 01
Key Stream (1): 51 05 A3 05 12 8F 74 DE 71 04 4B E5 82 D7 DD 87
Counter Block (2): 00 6C B6 DB C0 54 3B 59 DA 48 D9 0B 00 00 00 02
Key Stream (2): FB 3F 0C EF 52 CF 41 DF E4 FF 2A C4 8D 5C A0 37
Ciphertext : 51 04 A1 06 16 8A 72 D9 79 0D 41 EE 8E DA D3 88
: EB 2E 1E FC 46 DA 57 C8 FC E6 30 DF 91 41 BE 28Test Vector #3: Encrypting 36 octets using AES-CTR with 128-bit key 💖
AES Key : 76 91 BE 03 5E 50 20 A8 AC 6E 61 85 29 F9 A0 DC
AES-CTR IV : 27 77 7F 3F 4A 17 86 F0
Nonce : 00 E0 01 7B
Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
: 20 21 22 23
Counter Block (1): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 01
Key Stream (1): C1 CE 4A AB 9B 2A FB DE C7 4F 58 E2 E3 D6 7C D8
Counter Block (2): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 02
Key Stream (2): 55 51 B6 38 CA 78 6E 21 CD 83 46 F1 B2 EE 0E 4C
Counter Block (3): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 03
Key Stream (3): 05 93 25 0C 17 55 36 00 A6 3D FE CF 56 23 87 E9
Ciphertext : C1 CF 48 A8 9F 2F FD D9 CF 46 52 E9 EF DB 72 D7
: 45 40 A4 2B DE 6D 78 36 D5 9A 5C EA AE F3 10 53
: 25 B2 07 2FTest Vector #4: Encrypting 16 octets using AES-CTR with 192-bit key 🎀
AES Key : 16 AF 5B 14 5F C9 F5 79 C1 75 F9 3E 3B FB 0E ED
: 86 3D 06 CC FD B7 85 15
AES-CTR IV : 36 73 3C 14 7D 6D 93 CB
Nonce : 00 00 00 48
Plaintext String : 'Single block msg'
Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67
Counter Block (1): 00 00 00 48 36 73 3C 14 7D 6D 93 CB 00 00 00 01
Key Stream (1): 18 3C 56 28 8E 3C E9 AA 22 16 56 CB 23 A6 9A 4F
Ciphertext : 4B 55 38 4F E2 59 C9 C8 4E 79 35 A0 03 CB E9 28Test Vector #5: Encrypting 32 octets using AES-CTR with 192-bit key 🌈
AES Key : 7C 5C B2 40 1B 3D C3 3C 19 E7 34 08 19 E0 F6 9C
: 67 8C 3D B8 E6 F6 A9 1A
AES-CTR IV : 02 0C 6E AD C2 CB 50 0D
Nonce : 00 96 B0 3B
Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
Counter Block (1): 00 96 B0 3B 02 0C 6E AD C2 CB 50 0D 00 00 00 01
Key Stream (1): 45 33 41 FF 64 9E 25 35 76 D6 A0 F1 7D 3C C3 90
Counter Block (2): 00 96 B0 3B 02 0C 6E AD C2 CB 50 0D 00 00 00 02
Key Stream (2): 94 81 62 0F 4E C1 B1 8B E4 06 FA E4 5E E9 E5 1F
Ciphertext : 45 32 43 FC 60 9B 23 32 7E DF AA FA 71 31 CD 9F
: 84 90 70 1C 5A D4 A7 9C FC 1F E0 FF 42 F4 FB 00Test Vector #6: Encrypting 36 octets using AES-CTR with 192-bit key 🍓
AES Key : 02 BF 39 1E E8 EC B1 59 B9 59 61 7B 09 65 27 9B
: F5 9B 60 A7 86 D3 E0 FE
AES-CTR IV : 5C BD 60 27 8D CC 09 12
Nonce : 00 07 BD FD
Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
: 20 21 22 23
Counter Block (1): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 01
Key Stream (1): 96 88 3D C6 5A 59 74 28 5C 02 77 DA D1 FA E9 57
Counter Block (2): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 02
Key Stream (2): C2 99 AE 86 D2 84 73 9F 5D 2F D2 0A 7A 32 3F 97
Counter Block (3): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 03
Key Stream (3): 8B CF 2B 16 39 99 B2 26 15 B4 9C D4 FE 57 39 98
Ciphertext : 96 89 3F C5 5E 5C 72 2F 54 0B 7D D1 DD F7 E7 58
: D2 88 BC 95 C6 91 65 88 45 36 C8 11 66 2F 21 88
: AB EE 09 35Test Vector #7: Encrypting 16 octets using AES-CTR with 256-bit key 👑
AES Key : 77 6B EF F2 85 1D B0 6F 4C 8A 05 42 C8 69 6F 6C
: 6A 81 AF 1E EC 96 B4 D3 7F C1 D6 89 E6 C1 C1 04
AES-CTR IV : DB 56 72 C9 7A A8 F0 B2
Nonce : 00 00 00 60
Plaintext String : 'Single block msg'
Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67
Counter Block (1): 00 00 00 60 DB 56 72 C9 7A A8 F0 B2 00 00 00 01
Key Stream (1): 47 33 BE 7A D3 E7 6E A5 3A 67 00 B7 51 8E 93 A7
Ciphertext : 14 5A D0 1D BF 82 4E C7 56 08 63 DC 71 E3 E0 C0Test Vector #8: Encrypting 32 octets using AES-CTR with 256-bit key ⭐
AES Key : F6 D6 6D 6B D5 2D 59 BB 07 96 36 58 79 EF F8 86
: C6 6D D5 1A 5B 6A 99 74 4B 50 59 0C 87 A2 38 84
AES-CTR IV : C1 58 5E F1 5A 43 D8 75
Nonce : 00 FA AC 24
Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
Counter block (1): 00 FA AC 24 C1 58 5E F1 5A 43 D8 75 00 00 00 01
Key stream (1): F0 5F 21 18 3C 91 67 2B 41 E7 0A 00 8C 43 BC A6
Counter block (2): 00 FA AC 24 C1 58 5E F1 5A 43 D8 75 00 00 00 02
Key stream (2): A8 21 79 43 9B 96 8B 7D 4D 29 99 06 8F 59 B1 03
Ciphertext : F0 5E 23 1B 38 94 61 2C 49 EE 00 0B 80 4E B2 A9
: B8 30 6B 50 8F 83 9D 6A 55 30 83 1D 93 44 AF 1CTest Vector #9: Encrypting 36 octets using AES-CTR with 256-bit key 🔥
AES Key : FF 7A 61 7C E6 91 48 E4 F1 72 6E 2F 43 58 1D E2
: AA 62 D9 F8 05 53 2E DF F1 EE D6 87 FB 54 15 3D
AES-CTR IV : 51 A5 1D 70 A1 C1 11 48
Nonce : 00 1C C5 B7
Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
: 20 21 22 23
Counter block (1): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 01
Key stream (1): EB 6D 50 81 19 0E BD F0 C6 7C 9E 4D 26 C7 41 A5
Counter block (2): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 02
Key stream (2): A4 16 CD 95 71 7C EB 10 EC 95 DA AE 9F CB 19 00
Counter block (3): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 03
Key stream (3): 3E E1 C4 9B C6 B9 CA 21 3F 6E E2 71 D0 A9 33 39
Ciphertext : EB 6C 52 82 1D 0B BB F7 CE 75 94 46 2A CA 4F AA
: B4 07 DF 86 65 69 FD 07 F4 8C C0 B5 83 D6 07 1F
: 1E C0 E6 B87. Security Considerations 🔥
okay bestie, this is the scary section and i need you to actually listen 💀 when AES-CTR mode is used properly it gives strong confidentiality ✨ Bellare, Desai, Jokipii, Rogaway show in [BDJR] that the privacy guarantees of counter mode are at least as strong as the ones for CBC mode when you use the same block cipher. it's giving main character 👑
BUT it is SO easy to misuse this counter mode 😭 if counter block values are ever used for more than one packet with the same key, the same key stream gets used to encrypt both packets, and the confidentiality guarantees are voided. bye bye security 🫠
so what happens if the encryptor XORs the same key stream with two different plaintexts? say two plaintext byte sequences P1, P2, P3 and Q1, Q2, Q3 are both encrypted with key stream K1, K2, K3. the two ciphertexts look like this:
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
(Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3)if an attacker gets to see both of these ciphertext streams, confidentiality is a catastrophic failure 💀 because:
(P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1
(P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2
(P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3once the attacker has the two plaintexts XORed together, it's pretty straightforward to pull them apart 🙈 so using any stream cipher, AES-CTR included, to encrypt two plaintexts under the same key stream leaks the plaintext. no thoughts, just leaks.
Therefore, stream ciphers, including AES-CTR, should not be used with static keys. It is inappropriate to use AES-CTR with static keys. Extraordinary measures would be needed to prevent reuse of a counter block value with the static key across power cycles. 🚨
so to be safe, ESP implementations MUST use fresh keys with AES-CTR 🔑 the Internet Key Exchange (IKE) protocol [IKE] can be used to establish fresh keys, and IKE can also be used to establish the nonce at the beginning of the security association. iykyk 🫶
when IKE is used to establish fresh keys between two peer entities, separate keys are established for the two traffic flows, which is lowkey perfect 🦋 but when a mechanism other than IKE is used to establish fresh keys, and that mechanism only establishes a single key to encrypt packets, there is a high probability that the peers will select the same IV values for some packets. that's a counter block collision waiting to happen 😬 so to avoid counter block collisions, ESP implementations that permit use of the same key for encrypting outbound traffic and decrypting incoming traffic with the same peer MUST ensure that the two peers assign different Nonce values to the security association. no shared nonces, no drama 💅
data forgery is trivial with CTR mode, honestly it's unhinged 💀 the demonstration of this attack is similar to the key stream reuse stuff we just talked about. if a known plaintext byte sequence P1, P2, P3 is encrypted with key stream K1, K2, K3, the attacker can replace the plaintext with one they pick themselves. the ciphertext is:
(P1 XOR K1), (P2 XOR K2), (P3 XOR K3)the attacker just XORs a chosen sequence Q1, Q2, Q3 with the ciphertext to get:
(Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3))which is the same as:
((Q1 XOR P1) XOR K1), ((Q2 XOR P2) XOR K2), ((Q3 XOR P3) XOR K3)and decrypting the attacker-made ciphertext gives exactly what they wanted:
(Q1 XOR P1), (Q2 XOR P2), (Q3 XOR P3)so yeah, ESP implementations MUST use AES-CTR in conjunction with ESP authentication 🛡️ no authentication, no slay.
also, AES has a 128-bit block size no matter what mode you use, so the ciphertext it generates becomes distinguishable from random values after 2^64 blocks are encrypted with a single key 👀 ESP with Enhanced Sequence Numbers allows for up to 2^64 packets in one security association, so there is real potential for more than 2^64 blocks to be encrypted with one key. implementations SHOULD generate a fresh key before 2^64 blocks are encrypted with the same key 🔄 and fun fact: ESP with 32-bit Sequence Numbers won't exceed 2^64 blocks even if every packet is a maximum-length IPv6 jumbogram [JUMBO] 🧚
there are fairly generic precomputation attacks against all block cipher modes that allow a meet-in-the-middle attack against the key. these attacks need huge tables of ciphertext tied to known plaintext and known keys, so they're a lot of work 😮💨 assuming the memory and processor resources are there for a precomputation attack, the theoretical strength of AES-CTR (and any other block cipher mode) is limited to 2^(n/2) bits, where n is the number of bits in the key. the best countermeasure is long keys 🗝️ so implementations that use 128-bit AES keys should take precautions to make precomputation attacks harder. and the unpredictable nonce in the counter block really boosts the size of the table the attacker would need to compute to pull one off 🌸
8. Design Rationale 🧠
okay so this part is about WHY the spec is built the way it is, and it's giving architecture tea ☕ when this spec was being developed, people considered using the ESP sequence number field instead of an explicit IV field. this choice is not a cryptographic security issue, because either approach prevents counter block collisions ✨
in a very conservative model of encryption security, at most 2^64 blocks ought to be encrypted with AES-CTR under a single key. under that constraint, no more than 64 bits are needed to identify each packet within a security association. the ESP extended sequence number is 64 bits, so it's an obvious candidate for an implicit IV 👀 that would dictate a single method for assigning the per-packet value in the counter block. using an explicit IV doesn't dictate a method, and that's desirable for several reasons, bestie 💅
- only the encryptor can make sure the value isn't used for more than one packet, so there's no point picking a mechanism that lets the decryptor figure out whether counter block values collide. the damage from a collision is already done, whether the decryptor detects it or not 💀
- it allows adders, LFSRs, and any other technique that meets the encryptor's time budget, as long as the technique gives a unique value for each packet 🔢 adders are simple and straightforward to implement, but because of carries, they don't execute in constant time. LFSRs are an alternative that does execute in constant time ⚡
- complexity is in the control of the implementer 🛠️ and the encryptor implementer's decision doesn't make the decryptor more (or less) complex. no extra homework for the decryptor, periodt.
- when the encryptor has more than one cryptographic hardware device, an IV prefix can be assigned to each device, which makes sure collisions won't happen 🙌 and since the decryptor doesn't need to examine the IV structure, it's unaffected by whatever IV structure the encryptor picks. you can't do the same trick with ESP sequence numbers, because their semantics require sequential value generation 🙃
- assurance boundaries are super important to implementations that will be evaluated against FIPS Pub 140-1 or FIPS Pub 140-2 [SECRQMTS] 🔐 the assignment of the per-packet counter block value needs to be inside the assurance boundary. some implementations put the sequence number inside the assurance boundary, but others don't. a sequence number collision doesn't have dire consequences, but, as described in section 6, a collision in counter block values has disastrous consequences 😭
- coupling with the sequence number is possible in architectures where sequence number assignment happens inside the assurance boundary. in this case, the sequence number and the IV field contain the same value 🔗
- decoupling from the sequence number is possible in architectures where sequence number assignment happens outside the assurance boundary 🧩
the explicit IV field directly follows from decoupling the sequence number and the per-packet counter block value. the overhead of 64 bits for the IV field is acceptable 🙆♀️ and it's way less than the overhead of Cipher Block Chaining (CBC) mode. normally, CBC needs a full block for the IV and, on average, half a block for padding. AES-CTR with an explicit IV has about one-third of the overhead of AES-CBC, and the overhead is constant for each packet ✨
including the nonce is a weak countermeasure against precomputation attacks 🛡️ for it to work, the attacker must not be able to predict the nonce value well in advance of security association establishment. long keys are the strong countermeasure, and AES offers key sizes that thwart these attacks for many decades to come 🗓️
a 28-bit block counter value is enough to generate a key stream that encrypts the largest possible IPv6 jumbogram [JUMBO], but a 32-bit field is used anyway 🤷♀️ this size is convenient for both hardware and software implementations, so everybody wins 🎀
9. IANA Considerations 📋
IANA has assigned 13 as the ESP transform number for AES-CTR with an explicit IV 🎉 that's the number you'll look for, bestie 🦋
10. Intellectual Property Statement ⚖️
okay this part is a little legal-y but it's important, so here we go 🤓
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. It also doesn't 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 implementors or users of this specification, can be obtained from the IETF Secretariat 📄
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address that information to the IETF Executive Director 📬
11. Acknowledgements 💜
this document is the result of extensive discussions and compromises 🫶 not everyone is completely satisfied with the outcome, but the document is better for their contributions, and that's a whole mood 🌈
the author thanks the members of the IPsec working group for their contributions to the design, with special shoutouts to (in alphabetical order) Steve Bellovin, David Black, Niels Ferguson, Charlie Kaufman, Steve Kent, Tero Kivinen, Paul Koning, David McGrew, Robert Moskowitz, Jesse Walker, and Doug Whiting 👑✨
the author thanks and Alireza Hodjat, John Viega, and Doug Whiting for assistance with the test vectors 🧪💖
12. References 📚
This section provides normative and informative references. 🔍
12.1. Normative References ✨
okay so these are the must-read docs 📚💅 if you want the actual rules, not just vibes. bestie, these are the ones this spec is built on, no cap 🫶
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)", November 2001.
[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", NIST Special Publication 800-38A, December 2001.
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References 🌸
these ones are more like the background tea ☕ you don't have to read them but they explain why things are the way they are, iykyk 🙈
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[BDJR] Bellare, M, Desai, A., Jokipii, E. and P. Rogaway, "A Concrete Security Treatment of Symmetric Encryption: Analysis of the DES Modes of Operation", Proceedings 38th Annual Symposium on Foundations of Computer Science, 1997.
[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[JUMBO] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[ROADMAP] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[SECRQMTS] National Institute of Standards and Technology. FIPS Pub 140-1: Security Requirements for Cryptographic Modules. 11 January 1994.
National Institute of Standards and Technology. FIPS Pub 140-2: Security Requirements for Cryptographic Modules. 25 May 2001. [Supercedes FIPS Pub 140-1]
13. Author's Address 🎀
this is where you find the author, Russell Housley, if you wanna slide into the DMs of the person who wrote it 💌
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com14. Full Copyright Statement 💜
okay this part is the legal stuff, but it's still important bestie 🙈 read it so nobody gets in trouble later
Copyright (C) The Internet Society (2004). 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 assignees.
⚠️ this is the warranty disclaimer, and it's written in all caps for a reason, so read it carefully 💀 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. thank you to them for keeping the lights on for all these RFCs ✨🫶
📦 where this page comes from
- ietf: rfc3686 2004-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms