An Interface and Algorithms for Authenticated Encryption
Extracted elements (28)
A single AEAD algorithm identifier replaces the separate cipher+MAC pair, eliminating the need for application designers to reason about the relative order of authentication and encryption, the security of cipher/MAC combinations, or the potential confidentiality loss through the MAC. This abstraction allows security analysis independent of application context.
The ciphertext length-to-plaintext relationship MUST NOT depend on external parameters such as authentication tag length, because such dependence would mean the AEAD registry alone is insufficient to ensure interoperability between implementations.
The partially implicit nonce format (Fixed-Common implicit, Fixed-Distinct and Counter explicit) is used by GCM ESP and CCM ESP, incorporating the Salt value in the Fixed field. This format ensures nonce reconstructibility from explicit data and supports multi-device key sharing.
An implementation MAY accept additional inputs beyond the standard four (K, N, P, A), but such extensions MUST NOT affect interoperability with other implementations. Each algorithm SHOULD accept 12-octet nonces to aid cross-implementation compatibility.
Applications MUST NOT assume any particular structure or formatting of the ciphertext output.
Each AEAD algorithm MUST only accept keys with a fixed key length K_LEN and MUST NOT require any particular data format for the keys. Each algorithm MUST accept plaintext lengths between zero and P_MAX (which MUST be larger than zero and SHOULD be at least 65,536 octets).
Each AEAD algorithm SHOULD accept a nonce with a length of twelve (12) octets. Each AEAD algorithm SHOULD describe the security degradation that would result from inadvertent nonce reuse.
Each AEAD algorithm specification MUST include the values K_LEN, P_MAX, A_MAX, N_MIN, N_MAX, and C_MAX. The relationship between plaintext and ciphertext lengths MUST NOT depend on external parameters such as authentication tag length.
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. The number of octets in the nonce SHOULD be twelve (12).
If a particular implementation is requested to process an input outside the range of admissible lengths, it MUST return an error code and MUST NOT output any other information. Partially encrypted or partially decrypted data MUST NOT be returned.
If an application is unable to meet the uniqueness requirement on nonce generation, then it MUST use a zero-length nonce. Otherwise, an application SHOULD use nonces with a length of twelve octets.
If the AD input is constructed from multiple data elements, it MUST be unambiguously parseable into its constituent elements without using unauthenticated data in the parsing process (i.e., the AD must be an injective function of the data elements).
Requests to add an entry to the AEAD Registry MUST include the name and reference. Submitters SHOULD have their requests reviewed by the IRTF Crypto Forum Research Group (CFRG). Number assignments SHOULD use the smallest available positive number.
The Fixed field of the nonce MUST remain constant for all nonces generated for a given encryption device. If different devices share a single key, each distinct device MUST use a distinct Fixed field to ensure nonce uniqueness.
The secret key K MUST be generated in a way that is uniformly random or pseudorandom. The key length for each AEAD algorithm MUST be fixed.
The secret key K MUST NOT be included in any of the other inputs (N, P, and A). This means the key must not be explicitly copied into those inputs.
AEAD_AES_128_CCM uses AES-128 in CCM mode with nonce length n=12, tag length t=16, and q=3. Parameters: K_LEN=16 octets, P_MAX=2^24-1 octets, A_MAX=2^64-1 octets, N_MIN=N_MAX=12 octets, C_MAX=2^24+15 octets. Ciphertext is exactly 16 octets longer than plaintext.
AEAD_AES_128_GCM uses AES-128 in GCM mode with a 16-octet (128-bit) authentication tag appended to the ciphertext. Parameters: K_LEN=16 octets, P_MAX=2^36-31 octets, A_MAX=2^61-1 octets, N_MIN=N_MAX=12 octets, C_MAX=2^36-15 octets. Ciphertext is exactly 16 octets longer than plaintext.
AEAD_AES_256_CCM is identical to AEAD_AES_128_CCM except K_LEN is 32 octets and AES-256 CCM is used instead of AES-128 CCM.
AEAD_AES_256_GCM is identical to AEAD_AES_128_GCM except K_LEN is 32 octets and AES-256 GCM is used instead of AES-128 GCM.
The AEAD interface defines two operations: authenticated encryption (inputs K, N, P, A; output C) and authenticated decryption (inputs K, N, A, C; output P or FAIL). Both confidentiality and message authentication are provided on plaintext P, while associated data A is authenticated but not encrypted.
IANA has defined the 'AEAD Registry' for AEAD algorithms. Each entry contains a short name (starting with 'AEAD'), a positive number assigned by IANA, and a reference to a complete specification with test cases. Numbers 32,768–65,535 are reserved for private use. Initial entries: AEAD_AES_128_GCM (1), AEAD_AES_256_GCM (2), AEAD_AES_128_CCM (3), AEAD_AES_256_CCM (4).
A software implementation of AEAD encryption in a Virtual Machine environment could inadvertently reuse a nonce due to a VM rollback to an earlier state. Applications are encouraged to document this risk; an attacker who can trigger such a rollback may have already subverted system security.
AEAD algorithms address confidentiality and authentication but do nothing to address key generation or key management. AEAD algorithms that rely on distinct nonces may be inappropriate for some applications or scenarios where nonce uniqueness cannot be guaranteed.
An IANA registration of an AEAD algorithm MUST NOT be regarded as an endorsement of its security. The perceived security level of an algorithm can degrade over time due to cryptanalytic advances or Moore's Law.
GCM nonce reuse with the same key but distinct plaintexts undermines both confidentiality (attacker can XOR the two plaintexts) and all authenticity/integrity protection (attacker recovers the internal hash key, enabling trivial subsequent forgeries). GCM should only be used when nonce uniqueness can be assured.
The partially implicit nonce format (Figure 2) divides the Fixed field into Fixed-Common (may be implicit) and Fixed-Distinct (must be explicit) sub-fields, followed by a Counter field. The Fixed-Distinct field and Counter field MUST be in the explicit part of the nonce.
The recommended nonce format consists of a Fixed field followed by a Counter field (Figure 1). The Counter field forms a monotonically increasing unsigned integer sequence in network byte order. Implementations SHOULD support 12-octet nonces with a 4-octet Counter field.