RFC 8103

Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)

📅 published February 2017, from ietf

RFC 8103: Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) 💖

Okay bestie, the header facts first 🎀. This one is RFC 8103, written by R. Housley of Vigil Security 🧑‍💻. It's a Standards Track document, which means it's the real deal, and it's dated February 2017 📅. It comes from the Internet Engineering Task Force (IETF) 🌸 and has ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

Abstract ✨

Okay so this doc explains how to use ChaCha20-Poly1305 Authenticated Encryption inside the Cryptographic Message Syntax (CMS) 🔐. ChaCha20-Poly1305 is an authenticated encryption algorithm built from the ChaCha stream cipher and the Poly1305 authenticator. It's giving secure and efficient 💅.

Status of This Memo 🧾

This is an Internet Standards Track document 🏆.

This one is a product of the IETF, so it basically represents the consensus of the whole IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841 📚.

Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc8103 📬.

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 🧐. Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚠️.

Table of Contents 🗂️

1. Introduction ....................................................2
   1.1. The ChaCha20 and Poly1305 AEAD Construction ................3
   1.2. ASN.1 ......................................................3
   1.3. Terminology ................................................3
2. Key Management ..................................................4
3. Using the AEAD_CHACHA20_POLY1305 Algorithm with
   AuthEnvelopedData ...............................................4
4. S/MIME Capabilities Attribute ...................................5
5. IANA Considerations .............................................6
6. Security Considerations .........................................6
7. References ......................................................7
   7.1. Normative References .......................................7
   7.2. Informative References .....................................8
Appendix A. ASN.1 Module ...........................................9
Acknowledgements ...................................................9
Author's Address ...................................................9

1. Introduction ✨

Okay so this doc is the rulebook for using ChaCha20-Poly1305 Authenticated Encryption with the Cryptographic Message Syntax (CMS) [CMS] authenticated-enveloped-data content type [AUTHENV] 💖.

ChaCha [CHACHA] is a stream cipher that D. J. Bernstein developed in 2008 🦋. It's a refinement of Salsa20, which is one of the ciphers in the eSTREAM portfolio [ESTREAM] 🧚.

ChaCha20 is the 20-round version of ChaCha. It needs a 256-bit key and a 96-bit nonce 🔑. [FORIETF] gives a detailed algorithm description, examples, and test vectors for ChaCha20 📝.

Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator that D. J. Bernstein designed 🌸. It makes a 16-byte authentication tag and needs a 256-bit key that gets used once. [FORIETF] also has the detailed algorithm description, examples, and test vectors for Poly1305 💜.

ChaCha20 and Poly1305 were both designed to be fast in software. They can usually run with few resources and cheap operations, so they fit all kinds of systems 🍓. They were also designed to keep information from leaking through side channels 🙈.

1.1. The ChaCha20 and Poly1305 AEAD Construction

ChaCha20 and Poly1305 got combined into an Authenticated Encryption with Associated Data (AEAD) algorithm [AEAD] 🎀. People often call this AEAD algorithm AEAD_CHACHA20_POLY1305, and [FORIETF] describes it 💅.

AEAD_CHACHA20_POLY1305 takes four inputs: a 256-bit key, a 96-bit nonce, a plaintext of any length, and additional authenticated data (AAD) of any length. As the name says, a nonce value cannot be used securely more than once with the same key 🚫🔁.

AEAD_CHACHA20_POLY1305 makes two outputs: ciphertext the same length as the plaintext, and a 128-bit authentication tag 🔐.

Decryption with AEAD_CHACHA20_POLY1305 looks a lot like encryption, just flipped 🪞. The ciphertext and plaintext swap roles, so the ChaCha20 encryption function runs on the ciphertext to get the plaintext back. The Poly1305 function runs over the AAD and the ciphertext, not the plaintext. Then the resulting authentication tag gets bitwise compared to the received one. The message is authenticated if and only if the calculated and received tags match ✅.

1.2. ASN.1

CMS values get generated using ASN.1 [X680], which uses the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X690] 🧩.

1.3. Terminology

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 [STDWORDS] 📖.

2. Key Management 🔑

Reusing an AEAD_CHACHA20_POLY1305 nonce value with the same key destroys the security guarantees 💀. It can be extremely hard to use a statically configured AEAD_CHACHA20_POLY1305 key and never repeat a nonce value 😭. That's why the CMS authenticated-enveloped-data content type supports four key management techniques that let a fresh AEAD_CHACHA20_POLY1305 key be used as the content-authenticated-encryption key for a single protected content 👑:

  • Key Transport: the fresh content-authenticated-encryption key is encrypted in the recipient's public key.
  • Key Agreement: the recipient's public key and the sender's private key are used to generate a pairwise symmetric key-encryption key, and then the fresh content-authenticated-encryption key is encrypted in the pairwise symmetric key.
  • Symmetric Key-Encryption Keys: the fresh content-authenticated-encryption key is encrypted in a previously distributed symmetric key-encryption key.
  • Passwords: the fresh content-authenticated-encryption key is encrypted in a key-encryption key that is derived from a password or other shared secret value.

Besides these four general techniques, CMS supports other key management techniques too. See Section 6.2.5 of [CMS] 🔍. Since the properties of these other techniques are unknown, no statement can be made about whether they support fresh content-authenticated-encryption keys 🤷‍♀️. If one of these other key management techniques is supported, designers and implementers must do their own analysis. 🧠

3. Using the AEAD_CHACHA20_POLY1305 Algorithm with AuthEnvelopedData 🎁

This section lays out the conventions that CMS implementations follow when they support the authenticated-enveloped-data content type and the AEAD_CHACHA20_POLY1305 algorithm 🌟.

The AEAD_CHACHA20_POLY1305 algorithm identifier lives in the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm field 📍.

The AEAD_CHACHA20_POLY1305 algorithm does three jobs: (1) it authenticates the attributes in the AuthEnvelopedData authAttrs field, if any are present, (2) it enciphers the content in the AuthEnvelopedData EncryptedContentInfo encryptedContent field, and (3) it provides the message authentication code (MAC) in the AuthEnvelopedData mac field 🛡️. The authenticated attributes get DER encoded to make the AAD input value for the AEAD_CHACHA20_POLY1305 algorithm. The ciphertext and the MAC are the two outputs of the algorithm. The MAC, which [FORIETF] calls the authentication tag, protects the integrity of both the AuthEnvelopedData authAttrs and the AuthEnvelopedData EncryptedContentInfo encryptedContent 💖.

Neither the plaintext content nor the optional AAD inputs need padding before the AEAD_CHACHA20_POLY1305 algorithm runs 🙌.

There's one algorithm identifier for the AEAD_CHACHA20_POLY1305 algorithm 🪪:

id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs9(9) smime(16) alg(3) 18 }

The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain an AEADChaCha20Poly1305Nonce 🎯:

AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))

The AEADChaCha20Poly1305Nonce holds a 12-octet nonce 🔢. With CMS, the content-authenticated-encryption key is normally used for a single content 🔐. 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 🚨.

Part 1 of 2. Part 2 picks up with Section 4, the S/MIME Capabilities Attribute. 🎀

6. Security Considerations 🔐✨

Okay bestie, this is the serious part, so listen up 👂💅. CMS AuthEnvelopedData gives you every tool you need to avoid reusing the same nonce value under the same key. Check out Section 2 of this document for the details 🎀. RFC 7539 [FORIETF] explains what happens when you repeat a nonce, and it is not cute 💀:

Consequences of repeating a nonce: If a nonce is repeated, then both the one-time Poly1305 key and the keystream are identical between the messages. This reveals the XOR of the plaintexts, because the XOR of the plaintexts is equal to the XOR of the ciphertexts.

So yeah, never reuse a nonce. Ever. 🙅‍♀️

Here's another thing to keep in mind 🧐. When you use AEAD_CHACHA20_POLY1305, the ciphertext is always the same size as the original plaintext. So if hiding how big your message is matters to you, you'll need some other mechanism working alongside AEAD_CHACHA20_POLY1305 to cover that 🙈.

Now for the limits 📏. A single invocation of AEAD_CHACHA20_POLY1305 can handle 2^32-1 blocks of 64 octets each, and that comes from the size of the block counter field in the ChaCha20 block function. That works out to a total of 247,877,906,880 octets, which is very likely enough for any CMS content type 🌈. The ciphertext length field in the authentication buffer can hold 2^64 octets, which is way more than anyone needs, but hey, go big or go home 💜.

The AEAD_CHACHA20_POLY1305 construction is a brand new combo of ChaCha20 and Poly1305 🧪. You can read the security analysis of this composition in [PROCTER] 📖.

Last but definitely not least: implementations must randomly generate content-authenticated-encryption keys 🔑. If you use a bad pseudorandom number generator (PRNG) to make your keys, you can end up with little or no security at all 😭. An attacker might be able to recreate the PRNG environment that produced your keys, then search through that small pile of possibilities instead of brute forcing the whole key space. Generating good random numbers is genuinely hard, so RFC 4086 [RANDOM] has some super important guidance on this, and you should absolutely read it 🫶.

7. References 📚

7.1. Normative References

7.2. Informative References

Appendix A. ASN.1 Module 🧩

Here's the ASN.1 module, copied exactly so your parser stays happy 💖:

CMS-AEADChaCha20Poly1305
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) modules(0) 66 }

DEFINITIONS IMPLICIT TAGS ::= BEGIN

IMPORTS
   CONTENT-ENCRYPTION
   FROM AlgorithmInformation-2009
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-algorithmInformation-02(58) };

-- EXPORTS All

AEADContentEncryptionAlgs CONTENT-ENCRYPTION ::=
    { cea-AEADChaCha20Poly1305, ... }

cea-AEADChaCha20Poly1305 CONTENT-ENCRYPTION ::= {
    IDENTIFIER id-alg-AEADChaCha20Poly1305
    PARAMS TYPE AEADChaCha20Poly1305Nonce ARE required
    SMIME-CAPS { IDENTIFIED BY id-alg-AEADChaCha20Poly1305 } }

id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs9(9) smime(16) alg(3) 18 }

AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))

END

Acknowledgements 🫶

Huge thanks to Jim Schaad, Daniel Migault, Stephen Farrell, Yoav Nir, and Niclas Comstedt for their review and insightful comments 🌸. You all are iconic 👑.

Author's Address 🖋️

Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA  20170
United States of America

Email: housley@vigilsec.com
📦 where this page comes from