RFC 5116

An Interface and Algorithms for Authenticated Encryption

📅 published January 2008, from ietf

RFC 5116: An Interface and Algorithms for Authenticated Encryption 🎀

okay bestie, let's get into it 💖 this one is from the Network Working Group, written by D. McGrew from Cisco Systems, Inc., and it's a Standards Track doc dated January 2008 ✨ it doesn't list anything it obsoletes or updates in this title block, so nothing to flag there 🙈

Status of This Memo 📜

okay so this doc is an Internet standards track protocol for the Internet community, and it's literally asking people to talk about it and suggest improvements 🫶 if you want the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 and yes, distribution of this memo is unlimited, so share away 🦋

Abstract ✨

this doc defines algorithms for Authenticated Encryption with Associated Data (AEAD) 🔐 it also sets up a uniform interface and a registry for those algorithms, so they can be used as an application-independent set of cryptoalgorithm suites 💅 the vibe is that this gives you wins in efficiency and security, and it promotes reusing crypto implementations 🙌 iconic behaviour from a design standpoint 👑

Table of Contents 📑

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Background . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.4.  Conventions Used in This Document  . . . . . . . . . . . .  4
   2.  AEAD Interface . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Authenticated Encryption . . . . . . . . . . . . . . . . .  5
     2.2.  Authenticated Decryption . . . . . . . . . . . . . . . . .  7
     2.3.  Data Formatting  . . . . . . . . . . . . . . . . . . . . .  7
   3.  Guidance on the Use of AEAD Algorithms . . . . . . . . . . . .  8
     3.1.  Requirements on Nonce Generation . . . . . . . . . . . . .  8
     3.2.  Recommended Nonce Formation  . . . . . . . . . . . . . . .  9
       3.2.1.  Partially Implicit Nonces  . . . . . . . . . . . . . . 10
     3.3.  Construction of AEAD Inputs  . . . . . . . . . . . . . . . 11
     3.4.  Example Usage  . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Requirements on AEAD Algorithm Specifications  . . . . . . . . 12
   5.  AEAD Algorithms  . . . . . . . . . . . . . . . . . . . . . . . 14
     5.1.  AEAD_AES_128_GCM . . . . . . . . . . . . . . . . . . . . . 14
       5.1.1.  Nonce Reuse  . . . . . . . . . . . . . . . . . . . . . 14
     5.2.  AEAD_AES_256_GCM . . . . . . . . . . . . . . . . . . . . . 15
     5.3.  AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . . 15
       5.3.1.  Nonce Reuse  . . . . . . . . . . . . . . . . . . . . . 16
     5.4.  AEAD_AES_256_CCM . . . . . . . . . . . . . . . . . . . . . 16
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   7.  Other Considerations . . . . . . . . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     10.2. Informative References . . . . . . . . . . . . . . . . . . 19

1. Introduction 🌸

okay so authenticated encryption [BN00] is a form of encryption that not only keeps the plaintext confidential, it also gives you a way to check its integrity and authenticity 🔒 it's giving double protection ✨ then there's AEAD [R02], which adds the ability to check the integrity and authenticity of some Associated Data (AD) 🎀 the AD is also called "additional authenticated data", and it does not get encrypted, so it's just sitting there being verified 🫶

1.1. Background 📚

so a lot of crypto apps need both confidentiality and message authentication 💅 confidentiality is the security service that makes sure data is only available to the people who are allowed to get it, and it's usually done with encryption 🤫 message authentication is the service that makes sure data hasn't been altered or forged by unauthorized entities, and it can be done with a Message Authentication Code (MAC) 🔐 people also call this data integrity 💜

for ages, lots of apps used an encryption method and a MAC together to get both of those services, with each algorithm using its own independent key 🙃 more recently, the idea of getting both services from one cryptoalgorithm has become accepted 🙌 in that concept, the cipher and the MAC get replaced by an Authenticated Encryption with Associated Data (AEAD) algorithm ✨ main character energy for sure 👑

several crypto algorithms that implement AEAD have been defined, including block cipher modes of operation and dedicated algorithms 🧚 some of them have been adopted and proven useful in practice 💖 and AEAD is pretty close to an 'idealized' view of encryption, like the kind used in the automated analysis of cryptographic protocols (see, for example, Section 2.5 of [BOYD]) 🤓 the benefits of AEAD algorithms and this interface are outlined in Section 1.3 🦋

1.2. Scope 🔭

in this doc, we define an AEAD algorithm as an abstraction 🌈 we do that by specifying an interface to an AEAD and by defining an IANA registry for AEAD algorithms 🗂️ then we fill that registry with four AEAD algorithms based on the Advanced Encryption Standard (AES) in Galois/Counter Mode [GCM], with 128- and 256-bit keys, plus AES in Counter and CBC MAC Mode [CCM], also with 128- and 256-bit keys 🍓

here's the roadmap, bestie 🗺️ we define the AEAD interface (Section 2), then give guidance on using AEAD algorithms (Section 3), and outline the requirements that each AEAD algorithm must meet (Section 4) 💅 after that we define several AEAD algorithms (Section 5) and set up an IANA registry for them (Section 6) 🎀 and lastly, we talk about some other considerations (Section 7) ✨

the AEAD interface spec doesn't address security protocol issues like anti-replay services or access control decisions made on authenticated data 🙈 the whole point is to abstract the cryptography away from those issues 🧊 and the interface, plus the guidance on how to use it, are consistent with the recommendations from [EEM04] 🫶

1.3. Benefits 💎

the AEAD approach helps apps that need crypto security services adopt them way more easily ✨ it's a win for the application designer, because they get to focus on important stuff like security services, canonicalization, and data marshaling 💅 they don't have to design crypto mechanisms to meet their security goals, which is honestly such a relief 😭

the best part is that the security of an AEAD algorithm can be analyzed on its own, separate from how it's used in a particular application 🔥 this frees the AEAD user from having to think about things like the relative order of authentication and encryption 🙃 and the security of the particular cipher-and-MAC combo, like the potential loss of confidentiality through the MAC 💀 the application designer using the AEAD interface doesn't even need to pick a particular AEAD algorithm during the design stage 🧚 and the interface is pretty simple, since it only requires a single key as input and a single identifier to indicate which algorithm is in use in a given case 🌸

the AEAD approach also helps implementers of crypto algorithms 🛠️ it makes optimizations available that otherwise wouldn't be possible, which can reduce the amount of computation, the implementation cost, and/or the storage requirements 💜 the simpler interface makes testing easier too, and that's a considerable benefit for a crypto algorithm implementation 🥹

and because there's a uniform interface for accessing cryptographic services, a single crypto implementation can more easily support multiple applications 🌈 for example, a hardware module that supports the AEAD interface can easily provide crypto acceleration to any app using that interface 🚀 even apps that weren't designed yet when the module was built 🤯 that's the kind of future-proofing I'm obsessed with 😍

1.4. Conventions Used in This Document 📖

okay so 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] 🎀 these are the capital-letter words you'll see throughout, and they're defined over there, so go check [RFC2119] if you want the full deal 🧐

2. AEAD Interface 🔐

an AEAD algorithm has two operations: authenticated encryption and authenticated decryption ✨ the inputs and outputs of these algorithms are defined below in terms of octet strings 🧩

an implementation MAY accept additional inputs 🌸 for example, an input could be provided to let the user pick between different implementation strategies 🎛️ however, such extensions MUST NOT affect interoperability with other implementations 🫶 that's the one line you really don't want to mess with, periodt 💅

(more parts coming, bestie! 🧚💖)

2.1. Authenticated Encryption ✨

okay so the authenticated encryption operation takes four inputs, and every single one is an octet string 🫶

  • A secret key K, which MUST be generated in a way that is uniformly random or pseudorandom. 🔑 no cap, this key has to be genuinely random.
  • A nonce N. Each nonce provided to distinct invocations of the Authenticated Encryption operation MUST be distinct, for any particular value of the key, unless each and every nonce is zero-length. Applications that can generate distinct nonces SHOULD use the nonce formation method defined in Section 3.2, and MAY use any other method that meets the uniqueness requirement. Other applications SHOULD use zero-length nonces. 🌸
  • A plaintext P, which contains the data to be encrypted and authenticated. 💌
  • The associated data A, which contains the data to be authenticated, but not encrypted. 🎀

there's only one output 👑

  • A ciphertext C, which is at least as long as the plaintext, or an indication that the requested encryption operation could not be performed.

every input and output is a variable-length octet string, and their lengths have to follow these rules 📏

  • The number of octets in the key K is between 1 and 255. For each AEAD algorithm, the length of K MUST be fixed.
  • For any particular value of the key, either 1) each nonce provided to distinct invocations of the Authenticated Encryption operation MUST be distinct, or 2) each and every nonce MUST be zero-length. If zero-length nonces are used with a particular key, then each and every nonce used with that key MUST have a length of zero. Otherwise, the number of octets in the nonce SHOULD be twelve (12). Nonces with different lengths MAY be used with a particular key. Some algorithms cannot be used with zero-length nonces, but others can; see Section 4. Applications that conform to the recommended nonce length will avoid having to construct nonces with different lengths, depending on the algorithm that is in use. This guidance helps to keep algorithm-specific logic out of applications. 🙌
  • The number of octets in the plaintext P MAY be zero.
  • The number of octets in the associated data A MAY be zero.
  • The number of octets in the ciphertext C MAY be zero.

this spec doesn't put a maximum length on the nonce, the plaintext, the ciphertext, or the additional authenticated data 🌈 however, a particular AEAD algorithm MAY further restrict the lengths of those inputs and outputs, and a particular AEAD implementation MAY further restrict the lengths of its inputs and outputs too. if an implementation gets handed an input that's outside the admissible lengths, or outside the lengths that implementation supports, it MUST return an error code and it MUST NOT output any other information. like, partially encrypted or partially decrypted data MUST NOT be returned. absolutely not 🙅‍♀️

both confidentiality and message authentication are provided on the plaintext P. when P is zero-length, the AEAD algorithm acts as a Message Authentication Code on the input A. 🦋

the associated data A protects information that needs to be authenticated but doesn't need to stay secret. when you're using an AEAD to secure a network protocol, this input could include addresses, ports, sequence numbers, protocol version numbers, and other fields that tell the system how the plaintext or ciphertext should be handled, forwarded, or processed. a lot of the time you want these fields authenticated, but they have to stay in the clear so the network or system can actually function. when this data goes into the input A, you get authentication without copying the data into the plaintext. it's giving efficiency 💅

the secret key K MUST NOT be included in any of the other inputs (N, P, and A). (this restriction doesn't mean you have to check those inputs for substrings that match the key. it just means the key must not be explicitly copied into them.) 🔐

the nonce is authenticated internally to the algorithm, so you don't need to put it in the AD input. the nonce MAY be included in P or A if that's convenient for the application. ✨

the nonce MAY be stored or transported with the ciphertext, or it MAY be reconstructed right before the authenticated decryption operation. the decryption module just needs enough info to rebuild the nonce. (for example, a system could use a nonce made of a sequence number in a particular format, which could be inferred from the order of the ciphertexts.) and here's the best part: because authenticated decryption detects incorrect nonce values, no security failure happens if a nonce gets rebuilt incorrectly and fed into decryption. 🥹 any nonce reconstruction method still has to account for ciphertexts getting lost or reordered between encryption and decryption.

applications MUST NOT assume any particular structure or formatting of the ciphertext. don't go guessing, bestie 🙈

2.2. Authenticated Decryption 🔓

the authenticated decryption operation has four inputs: K, N, A, and C, same as above. it has only one output, either a plaintext value P or a special symbol FAIL that means the inputs aren't authentic. a ciphertext C, a nonce N, and associated data A are authentic for key K when C was generated by the encrypt operation with inputs K, N, P, and A, for some values of N, P, and A. the authenticated decrypt operation will, with high probability, return FAIL whenever the inputs N, P, and A were crafted by a nonce-respecting adversary that doesn't know the secret key (assuming the AEAD algorithm is secure). the vibes are: if someone forged it, it gets caught 🚫💀

2.3. Data Formatting 🍓

this document doesn't specify any particular encoding for the AEAD inputs and outputs, since the encoding doesn't affect the security services an AEAD algorithm provides. so the format is up to you 🧚

when you're choosing how application data is laid out, an application SHOULD position the ciphertext C so that it appears after any other data needed to construct the other inputs to the authenticated decryption operation. for example, if the nonce and ciphertext both show up in a packet, the nonce should come before the ciphertext. this rule makes hardware implementations of AEAD algorithms efficient and simple, which is so iconic 🔥

3. Guidance on the Use of AEAD Algorithms 📚

this section gives advice that must be followed if you want to use an AEAD algorithm securely. it's not optional bestie, it's the main character rules 👑

if an application can't meet the uniqueness requirement on nonce generation, then it MUST use a zero-length nonce. randomized or stateful algorithms, which get defined below, are suitable for those applications. otherwise, an application SHOULD use nonces with a length of twelve octets. algorithms are encouraged to support that length, so applications should use it to help with interoperability 🫶

3.1. Requirements on Nonce Generation 🎲

it is essential for security that nonces are built in a way that respects the requirement that each nonce value be distinct for each invocation of the authenticated encryption operation, for any fixed value of the key. in this section we're calling out some consequences of that requirement in different scenarios 👀

when multiple devices encrypt using a single key, those devices have to coordinate so the nonces are unique. a simple way to do that is to use a nonce format with a field that's distinct for each device, as described in Section 3.2. there's no need to coordinate the details of the nonce format between the encrypter and the decrypter, as long as the entire nonce is sent or stored with the ciphertext and so is available to the decrypter. if the decrypter doesn't have the complete nonce, then it'll need to know how the nonce is structured so it can rebuild it. applications SHOULD give encryption engines some freedom in picking their nonces. for example, a nonce could hold both a counter and a field that's set by the encrypter but not processed by the receiver. that freedom helps a set of encryption devices coordinate more easily so their nonces stay distinct 🤝

if a secret key is going to be used for a long time, like across multiple reboots, then the nonce will need to be stored in non-volatile memory. in that case, checkpointing the nonce is essential. that means the current nonce value should be stored so there's enough state to resume encryption after an unexpected failure 💾 one simple way to be pretty sure a nonce won't get reused is to wait until the encryption process gets confirmation from the storage process that the next nonce value has been stored. but that can add a lot of latency, so it may be smarter to store a nonce value that's several values ahead in the sequence. for example, nonce 100 could be stored, and then nonces 1 through 99 could be used for encryption. nonce value 200 could be stored at the same time nonces 1 through 99 are being used, and so on 🌟

many problems with nonce reuse can be avoided by changing the key in a situation where nonce coordination is difficult. 🔄

each AEAD algorithm SHOULD describe what security degradation would result from an inadvertent reuse of a nonce value. ⚠️

okay bestie, this is the nonce recipe the RFC really wants you to use 💅 It's RECOMMENDED, so the nonce gets split into two parts. The front part is a Fixed field and the back part is a Counter field. For any given fixed key, both lengths stay the same, so the whole nonce length is locked in too 🔒 Implementations SHOULD support 12-octet nonces where the Counter field is four octets long 🎀

     <----- variable ----> <----------- variable ----------->
    +---------------------+----------------------------------+
    |        Fixed        |              Counter             |
    +---------------------+----------------------------------+

Figure 1: Recommended nonce format

The Counter fields of successive nonces make a monotonically increasing sequence 📈 That's when you read them as unsigned integers in network byte order. The Counter field length MUST stay constant for every nonce generated for a given encryption device, no switching it up mid-tour 🙅‍♀️ The Counter part SHOULD be equal to zero for the first nonce, then go up by one for each nonce after that 🌸 BUT (plot twist) any particular Counter value MAY be skipped over and left out of the sequence if that's more convenient 🦋 For example, an app could skip the starting Counter=0 and set the first nonce's Counter field to 1. So with a Counter field that's C octets long, at most 2^(8*C) nonces can ever be generated 💜

The Fixed field MUST stay constant for every nonce generated for a given encryption device 💖 If different devices are encrypting with one single key, then every device MUST use its own distinct Fixed field so the nonces stay unique ✨ So if the Fixed field is F octets long, at most 2^(8*F) distinct encrypters can share a key. Iconic math, honestly 🧚

3.2.1. Partially Implicit Nonces

Sometimes you don't want to send or store the whole nonce, and you'd rather rebuild it from context right before decryption 🧩 For example, ciphertexts could be stored in order on a disk, and the nonce for each one could be inferred from where it sits, as long as the decrypter knows the rule for making nonces 🗂️ We call the part of the nonce that gets stored or sent alongside the ciphertext the explicit part. The part that gets inferred is the implicit part 🫶

When part of the nonce is implicit, the following version of the format is RECOMMENDED 🔥 The Fixed field gets split into two sub-fields, a Fixed-Common field and a Fixed-Distinct field. Check out Figure 2 below 👀 If different devices are encrypting with a single key, each distinct device MUST use a distinct Fixed-Distinct field 💅 The Fixed-Common field is shared by all nonces. The Fixed-Distinct field and the Counter field MUST be in the explicit part of the nonce. The Fixed-Common field MAY be in the implicit part of the nonce. These rules make sure the nonce is easy to rebuild from the explicit data ✨

   +-------------------+--------------------+---------------+
   |    Fixed-Common   |   Fixed-Distinct   |    Counter    |
   +-------------------+--------------------+---------------+
    <---- implicit ---> <------------ explicit ------------>

Figure 2: Partially implicit nonce format

Okay, the why behind this format is seriously good. This nonce construction uses the best known practice 🏆 It's used by both GCM Encapsulating Security Payload (ESP) [RFC4106] and CCM ESP [RFC4309], where the Fixed field holds the Salt value and the lowest eight octets of the nonce are carried explicitly in the ESP packet. In GCM ESP the Fixed field must be at least four octets long so it can hold the Salt value 🌈 In CCM ESP the Fixed field must be at least three octets long, for the same reason. This nonce generation method is also used by several counter mode variants, including CTR ESP 💜

3.3. Construction of AEAD Inputs

Here's where it gets dramatic 🎭 If the AD input is built from multiple data elements, it is ESSENTIAL that it can be parsed unambiguously into its parts, WITHOUT using any unauthenticated data while parsing 🔐 (In math terms, the AD input has to be an injective function of the data elements. Don't worry, I'm not going to test you on it 🙈) If an app builds its AD input so that two different sets of data elements produce the same AD value, then an attacker could make a receiver accept a bogus set by swapping one set for the other 😱 The requirement that the AD be uniquely parseable makes sure this attack is off the table 🚫 This requirement is trivially met if the AD is made of fixed-width elements 🧸 If the AD has a variable-length string in it, you can meet the requirement by also including the length of that string in the AD 📏

Same energy for the plaintext 💖 If the plaintext is built from multiple data elements, it is ESSENTIAL that it can be parsed unambiguously into its constituent elements, WITHOUT using any unauthenticated data in the parsing process 🔍 Note that data included in the AD may be used when parsing the plaintext. But the AD isn't encrypted, so there's a potential loss of confidentiality when information about the plaintext ends up in the AD 🙀

3.4. Example Usage

To use an AEAD algorithm, an app has to define how the encryption algorithm's inputs come from application data, and how the ciphertext and nonce get conveyed 📦 The cleanest way is to express each input in terms of the data that forms it. Then express the application data in terms of the outputs of the AEAD encryption operation 🧁

For example, AES-GCM ESP [RFC4106] can be written like this. The AEAD inputs are:

P = RestOfPayloadData || TFCpadding || Padding || PadLength ||
    NextHeader

N = Salt || IV

A = SPI || SequenceNumber

where the symbol "||" means concatenation 🔗 and the fields RestOfPayloadData, TFCpadding, Padding, PadLength, NextHeader, SPI, and SequenceNumber are as defined in [RFC4303]. The fields Salt and IV are as defined in [RFC4106]. The field RestOfPayloadData holds the plaintext data that is described by the NextHeader field, and nothing else 💅 (Recall that the PayloadData field contains both the IV and the RestOfPayloadData. See Figure 2 of [RFC4303] for a picture 🖼️)

The format of the ESP packet can be written as:

ESP = SPI || SequenceNumber || IV || C

where C is the AEAD ciphertext, which in this case includes the authentication tag 🏷️ Heads up, we haven't covered the use of the ESP Extended Sequence Number here, so don't go looking for it in this example 🙃

4. Requirements on AEAD Algorithm Specifications

Okay, this section is the checklist every AEAD algorithm has to pass ✅ Each AEAD algorithm MUST only accept keys with a fixed key length K_LEN, and it MUST NOT require any particular data format for the keys it gets as input 🔑 An algorithm that does need that kind of structure (like subkeys in a particular parity-check format) will have to provide it internally 🛠️

Each AEAD algorithm MUST accept any plaintext with a length between zero and P_MAX octets, inclusive 📝 The value of P_MAX is specific to each algorithm. P_MAX MUST be larger than zero, and it SHOULD be at least 65,536 (2^16) octets 📦 That size is a typical upper limit for network data packets 🌐 Other apps may use even bigger values of P_MAX, so it's desirable for general-purpose algorithms to support higher values 🚀

Each AEAD algorithm MUST accept any associated data with a length between zero and A_MAX octets, inclusive 🎀 The value of A_MAX is specific to each algorithm. A_MAX MUST be larger than zero, and it SHOULD be at least 65,536 (2^16) octets. Other apps may use even larger values of A_MAX, so general-purpose algorithms should support higher values too 💜

Each AEAD algorithm MUST accept any nonce with a length between N_MIN and N_MAX octets, inclusive, where the values of N_MIN and N_MAX are specific to that algorithm 🧾 The values of N_MAX and N_MIN MAY be equal. Each algorithm SHOULD accept a nonce that is twelve (12) octets long 🌸 Randomized or stateful algorithms (more on those below) MAY have an N_MAX value of zero 🦋

An AEAD algorithm MAY structure its ciphertext output in any way. For example, the ciphertext can include an authentication tag 🏷️ Each algorithm SHOULD choose a structure that's easy to process efficiently ⚡

An Authenticated Encryption algorithm MAY use a random source, for example to generate an internal initialization vector that gets baked into the ciphertext output 🎲 An AEAD algorithm like this is called randomized. Note that only encryption is random. Decryption is always deterministic 🧠 A randomized algorithm MAY have a value of N_MAX that equals zero ✨

An Authenticated Encryption algorithm MAY keep internal state between invocations of the encrypt operation, for example to build distinct values that the algorithm uses as internal nonces 🧩 An AEAD algorithm like this is called stateful. This approach could let an algorithm stay secure even when the app gives it zero-length nonces 🫶 A stateful algorithm MAY have a value of N_MAX that equals zero 💅

The specification of an AEAD algorithm MUST include the values of K_LEN, P_MAX, A_MAX, N_MIN, and N_MAX defined above 📋 It also MUST specify the number of octets in the largest possible ciphertext, which we call C_MAX 📏

Each AEAD algorithm MUST describe how the length of the plaintext relates to the length of the ciphertext 🧮 This relation MUST NOT depend on external parameters, like an authentication strength parameter (for example, the authentication tag length) 🚫 That sort of dependence would make the algorithm harder to use, because the info in the AEAD registry wouldn't be enough to guarantee interoperability 😬

EACH AEAD algorithm specification SHOULD describe what security degradation would result from an accidental reuse of a nonce value 🙀 (Nonce reuse is a total vibe killer, bestie 💀)

Each AEAD algorithm specification SHOULD provide a reference to a detailed security analysis. This document doesn't pick one particular security model, since several different models have been used in the literature 📚 The security analysis SHOULD define or reference a security model 🔍

An algorithm that is randomized or stateful, as defined above, SHOULD describe itself using those terms 🏷️

5. AEAD Algorithms

Okay, here's the lineup 👑 This section defines four AEAD algorithms. Two are based on AES GCM, and two are based on AES CCM 💖 Each pair includes one algorithm with a 128-bit key size and one with a 256-bit key size 🌈

5.1. AEAD_AES_128_GCM ✨

okay so AEAD_AES_128_GCM is basically the GCM mode from [GCM] with AES-128 as the block cipher 💅 you hand it the key, nonce, plaintext, and associated data, and it does its thing. the auth tag is 16 octets (128 bits) 🔐 and the final ciphertext is just the GCM output with that tag stuck on the end 🎀 test cases live in the appendix of [GCM] if you want to check your work 🌸 here are the input and output lengths:

  • K_LEN is 16 octets,
  • P_MAX is 2^36 - 31 octets,
  • A_MAX is 2^61 - 1 octets,
  • N_MIN and N_MAX are both 12 octets, and
  • C_MAX is 2^36 - 15 octets.

every AEAD_AES_128_GCM ciphertext is exactly 16 octets longer than its plaintext, no more, no less 🧚 if you want the security analysis, it's in [MV04] 📚

5.1.1. Nonce Reuse

okay this part is SO important bestie 😭 if two GCM encryptions use the same key and the same nonce but different plaintexts, that's a disaster. it wrecks confidentiality for those two plaintexts and it wrecks all the authenticity and integrity protection that key was giving you 💀 so GCM should only be used when nonce uniqueness can be provided with assurance 🔒 the feature that makes GCM so fast (minimal latency) is literally the same thing that causes the trouble on later uses of the key 🙈 also, it's fine to feed the same nonce value into the decryption operation more than once ✨

the consequences are honestly iconic in the worst way 💀 if an attacker sees two ciphertexts made with the same nonce and key, the only way it's not a big deal is if the plaintext and AD values in both encrypt calls were identical. first, confidentiality is gone, because they can recover the bitwise exclusive-or of the two plaintexts 😱 second, integrity is gone, because they can recover the internal hash key used for data integrity, and once they have that key, forging stuff is trivial 🥀

5.2. AEAD_AES_256_GCM 🦋

this one is basically the same as AEAD_AES_128_GCM, just with a couple of upgrades 👑

  • K_LEN is 32 octets, instead of 16 octets, and
  • AES-256 GCM is used instead of AES-128 GCM.

5.3. AEAD_AES_128_CCM 🌈

AEAD_AES_128_CCM works as specified in [CCM], using AES-128 as the block cipher 🧁 you give it the key, nonce, associated data, and plaintext. the formatting and counter generation are as specified in Appendix A of that reference, and the parameter values from that appendix are:

  • the nonce length n is 12,
  • the tag length t is 16, and
  • the value of q is 3.

the auth tag is 16 octets (128 bits), and the ciphertext is the CCM output with that tag appended 🎀 test cases are in [CCM] 📖 here are the input and output lengths:

  • K_LEN is 16 octets,
  • P_MAX is 2^24 - 1 octets,
  • A_MAX is 2^64 - 1 octets,
  • N_MIN and N_MAX are both 12 octets, and
  • C_MAX is 2^24 + 15 octets.

an AEAD_AES_128_CCM ciphertext is exactly 16 octets longer than its plaintext 🫶 the security analysis of AES CCM is in [J02] 🔍

5.3.1. Nonce Reuse

reusing a nonce with the same key in two CCM encryptions is a real problem 😬 it undermines the security of the messages processed in those two calls. the big one is that confidentiality breaks, because an adversary can reconstruct the bitwise exclusive-or of the two plaintexts 💔

5.4. AEAD_AES_256_CCM 💜

same energy as AEAD_AES_128_CCM, with these changes:

  • K_LEN is 32 octets, instead of 16, and
  • AES-256 CCM is used instead of AES-128 CCM.

6. IANA Considerations 🌸

okay so IANA has set up the "AEAD Registry" ✨ an algorithm designer MAY register an algorithm to make it easier to use 🦋 adding something to the registry needs a specification that's written down in an RFC or another permanent, easy-to-find reference, with enough detail that independent implementations can actually interoperate 🧩 every entry has three bits:

  • a short name, such as "AEAD_AES_128_GCM", that starts with the string "AEAD",
  • a positive number, and
  • a reference to a specification that completely defines an AEAD algorithm and provides test cases that can be used to verify the correctness of an implementation.

if you're asking for a new entry, your request MUST include the name and the reference 📝 IANA assigns the number itself 🔢 those numbers SHOULD use the smallest available positive number 🥇 submitters SHOULD also get their requests reviewed by the IRTF Crypto Forum Research Group (CFRG) at cfrg@ietf.org 💅 if you're new to IANA processes, you can check out http://www.iana.org 🌐

the numbers from 32,768 (binary 1000000000000000) to 65,535 (binary 1111111111111111), inclusive, are NOT going to be assigned by IANA 🙅 they're reserved for private use, and nobody is going to police whether multiple sites use the same value in different (and incompatible) ways [RFC2434] 😬

IANA has added these entries to the AEAD Registry:

       +------------------+-------------+--------------------+
       | Name             |  Reference  | Numeric Identifier |
       +------------------+-------------+--------------------+
       | AEAD_AES_128_GCM | Section 5.1 |          1         |
       | AEAD_AES_256_GCM | Section 5.2 |          2         |
       | AEAD_AES_128_CCM | Section 5.3 |          3         |
       | AEAD_AES_256_CCM | Section 5.4 |          4         |
       +------------------+-------------+--------------------+

an IANA registration of an AEAD does not constitute an endorsement of that algorithm or its security 🫶 registered does NOT mean endorsed, babe 🙈

7. Other Considerations 🧚

testing a randomized AEAD encryption algorithm with fixed inputs and outputs isn't possible, since encryption is non-deterministic 🎲 but there's a trick 🪄 the authenticated decryption algorithm is deterministic, so you can test it directly. for the encryption side, you encrypt a plaintext, decrypt the result, and compare the original plaintext to the decrypted one. doing both of those covers both the encryption and decryption algorithms ✨

the AEAD algorithms picked here are the ones standards have already adopted 📜 what other AEAD algorithms should get added is still an open question 🤔 there are lots of variations on the basic algorithms, each with its own perks 💖 it's desirable to admit any algorithm that turns out to be useful in practice, but it's also desirable to keep the total number of registered algorithms limited ⚖️ right now, a registered algorithm has to come with a complete specification and a set of validation data, and the hope is that those prerequisites set the admission criteria appropriately 🌸

it might be good to define an AEAD algorithm that uses generic composition with the encrypt-then-MAC method [BN00] 🔗 that would combine a common encryption algorithm, like CBC [MODES], with a common message authentication code, like HMAC-SHA1 [RFC2104] or AES CMAC [CMAC] 🧁 an algorithm like that would reflect current best practice, and it might be easier to support on crypto modules that don't support other AEAD algorithms 🦋

8. Security Considerations 💀

this document describes authenticated encryption algorithms and gives guidance on using them 🔐 these algorithms make it easier, in some ways, to design a cryptographic application, but strong cryptographic security is still really hard to achieve 😤 AEAD algorithms are super useful, but they do nothing to address key generation [RFC4086] or key management [RFC4107] 🗝️

⚠️ AEAD algorithms that rely on distinct nonces may be inappropriate for some applications or for some scenarios. application designers should understand the requirements outlined in Section 3.1. no skipping this one, bestie 💀

a software implementation of the AEAD encryption operation in a Virtual Machine (VM) environment could accidentally reuse a nonce because of a "rollback" of the VM to an earlier state [GR05] 😱 applications are encouraged to document potential issues so users of the application and the VM can avoid unintentional mistakes like this 📝 it's possible an attacker can cause a VM rollback, and threats and mitigations in that scenario are an area of active research 🔬 for perspective, an attacker who can trigger such a rollback may have already succeeded in subverting the security of the system, e.g., by causing an accounting error 🙃

🚨 an IANA registration of an AEAD algorithm MUST NOT be regarded as an endorsement of its security. furthermore, the perceived security level of an algorithm can degrade over time, due to cryptanalytic advances or to "Moore's Law", that is, the diminishing cost of computational resources over time 📉 the security level can slip even when nothing looks broken yet 💔

9. Acknowledgments 🫶

many reviewers left valuable comments on earlier drafts of this document 💖 some fruitful discussions happened on the email list of the Crypto Forum Research Group in 2006 📬

10. References 📚

10.1. Normative References

🌈 that's the end of this batch, the rest is coming in the next part ✨

10.2. Informative References 📚✨

okay so these are the background reads, the "wait, what's the history here?" stuff that helps you understand the design without being required to implement it 🤓💅

  • [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: Relations among notions and analysis of the generic composition paradigm", Proceedings of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531-545, 2002. 🔐
  • [BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication and Key Establishment", Springer 2003. 📖
  • [CMAC] "NIST Special Publication 800-38B", <http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf>. 🧮
  • [EEM04] Bellare, M., Namprempre, C., and T. Kohno, "Breaking and provably repairing the SSH authenticated encryption scheme: A case study of the Encode-then-Encrypt-and-MAC paradigm", ACM Transactions on Information and System Security, <http://www-cse.ucsd.edu/users/tkohno/papers/TISSEC04/>. 🫣
  • [GR05] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder than Real: Security Challenges in Virtual Machine Based Computing Environments", Proceedings of the 10th Workshop on Hot Topics in Operating Systems, <http://www.stanford.edu/~talg/papers/HOTOS05/virtual-harder-hotos05.pdf>. 💻
  • [J02] Jonsson, J., "On the Security of CTR + CBC-MAC", Proceedings of the 9th Annual Workshop on Selected Areas on Cryptography, 2002, <http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ccm/ccm-ad1.pdf>. 🧠
  • [MODES] Dworkin, M., "NIST Special Publication 800-38: Recommendation for Block Cipher Modes of Operation", U.S. National Institute of Standards and Technology, <http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf>. 🎀
  • [MV04] McGrew, D. and J. Viega, "The Security and Performance of the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT '04, December 2004, <http://eprint.iacr.org/2004/193>. 🌸
  • [R02] Rogaway, P., "Authenticated encryption with Associated-Data", ACM Conference on Computer and Communication Security (CCS'02), pp. 98-107, ACM Press, 2002, <http://www.cs.ucdavis.edu/~rogaway/papers/ad.html>. 🦋
  • [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. 🔑
  • [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 📋
  • [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. 🎲
  • [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005. 🛡️
  • [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. 🗝️
  • [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. 📦
  • [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005. 💜

Author's Address 🧑‍💻

this is who wrote it, so you know exactly who to thank (or question) 🫶

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

okay the legal part, but make it cute 🎀

Copyright (C) The IETF Trust (2008).

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 is being careful here, and honestly respect 🙏

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. 🫶✨

📦 where this page comes from