Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)
Extracted elements (20)
A statically configured AEAD_CHACHA20_POLY1305 key is considered impractical because reliably avoiding nonce reuse is extremely difficult. The CMS AuthEnvelopedData content type is used instead because it supports key management techniques that provide a fresh key for each protected content item.
ChaCha20 and Poly1305 were chosen because they are designed for high-performance software implementations, require few resources and inexpensive operations, and are suitable across a wide range of systems. They were also designed to minimize information leakage through side channels.
CMS values are generated using ASN.1 with Basic Encoding Rules (BER) and Distinguished Encoding Rules (DER) per X.680 and X.690. Authenticated attributes are DER encoded specifically when used as the AAD input to AEAD_CHACHA20_POLY1305.
Compliant software MAY include the SMIMECapabilities signed attribute in a CMS signed-data content type to announce support for AEAD_CHACHA20_POLY1305.
Designers and implementers MUST perform their own analysis if key management techniques beyond the four defined ones (Key Transport, Key Agreement, Symmetric KEK, Passwords) are used, since their properties with respect to fresh key generation are unknown.
The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain an AEADChaCha20Poly1305Nonce when using AEAD_CHACHA20_POLY1305 in CMS.
When including SMIMECapabilities for AEAD_CHACHA20_POLY1305, the SMIMECapability SEQUENCE MUST include the id-alg-AEADChaCha20Poly1305 OID in capabilityID and MUST omit the parameters field.
Within the scope of any content-authenticated-encryption key, the nonce value MUST be unique. That is, the set of nonce values used with any given key MUST NOT contain any duplicate values.
AEAD_CHACHA20_POLY1305 accepts four inputs: a 256-bit key, a 96-bit nonce, an arbitrary-length plaintext, and an arbitrary-length additional authenticated data (AAD). It produces two outputs: ciphertext of the same length as the plaintext and a 128-bit authentication tag.
AEAD_CHACHA20_POLY1305 serves three roles in AuthEnvelopedData: (1) authenticates authAttrs (used as DER-encoded AAD), (2) enciphers the content in encryptedContent, and (3) provides the MAC stored in the mac field. No padding of plaintext or AAD is required.
CMS supports four key management techniques for delivering a fresh content-authenticated-encryption key: Key Transport (encrypted in recipient's public key), Key Agreement (pairwise symmetric KEK), Symmetric Key-Encryption Keys (pre-distributed KEK), and Passwords (KDF from shared secret).
The AEAD_CHACHA20_POLY1305 algorithm identifier is id-alg-AEADChaCha20Poly1305 with OID { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 18 }. It is placed in the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field.
IANA added entry 18 (id-alg-AEADChaCha20Poly1305) to the 'SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)' registry, referencing RFC 8103.
IANA added entry 66 (id-mod-CMS-AEADChaCha20Poly1305) to the 'SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)' registry, referencing RFC 8103.
AEAD_CHACHA20_POLY1305 does not hide plaintext length; the ciphertext is always the same size as the plaintext. A separate mechanism must be used if disclosure of plaintext size is a concern.
Implementations must randomly generate content-authenticated-encryption keys using a cryptographically strong PRNG. Use of inadequate PRNGs can reduce effective key space to a searchable set, defeating the security of the algorithm. RFC 4086 provides guidance.
Nonce reuse under the same key is catastrophic: it reveals both the one-time Poly1305 key and the keystream, exposing the XOR of the plaintexts (since XOR of ciphertexts equals XOR of plaintexts). CMS AuthEnvelopedData's key management mechanisms are designed to avoid this by providing a fresh key per message.
The maximum plaintext size for a single AEAD_CHACHA20_POLY1305 invocation is (2^32 - 1) × 64 octets ≈ 247.9 GB, limited by the ChaCha20 block counter field size. This is sufficient for any anticipated CMS content type.
The AlgorithmIdentifier parameters field contains an AEADChaCha20Poly1305Nonce, defined as OCTET STRING (SIZE(12)), carrying the 12-octet (96-bit) nonce value used by ChaCha20.
The DER encoding of the SMIMECapability SEQUENCE for AEAD_CHACHA20_POLY1305 (in hex) is: 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 12. This is a 15-byte sequence.