draft-ietf-curdle-cms-chacha20-poly1305-02.txt   draft-ietf-curdle-cms-chacha20-poly1305-03.txt 
Internet-Draft R. Housley Internet-Draft R. Housley
Intended status: Standards Track Vigil Security Intended status: Standards Track Vigil Security
Expires: 22 March 2017 22 September 2016 Expires: 28 April 2017 28 October 2016
Using ChaCha20-Poly1305 Authenticated Encryption Using ChaCha20-Poly1305 Authenticated Encryption
in the Cryptographic Message Syntax (CMS) in the Cryptographic Message Syntax (CMS)
<draft-ietf-curdle-cms-chacha20-poly1305-02.txt> <draft-ietf-curdle-cms-chacha20-poly1305-03.txt>
Abstract Abstract
This document describes the conventions for using ChaCha20-Poly1305 This document describes the conventions for using ChaCha20-Poly1305
Authenticated Encryption in the Cryptographic Message Syntax (CMS). Authenticated Encryption in the Cryptographic Message Syntax (CMS).
ChaCha20-Poly1305 is an authenticated encryption algorithm ChaCha20-Poly1305 is an authenticated encryption algorithm
constructed of the ChaCha stream cipher and Poly1305 authenticator. constructed of the ChaCha stream cipher and Poly1305 authenticator.
Status of This Memo Status of This Memo
skipping to change at page 2, line 36 skipping to change at page 2, line 36
software implementations. They can typically be implemented with few software implementations. They can typically be implemented with few
resources and inexpensive operations, making them suitable on a wide resources and inexpensive operations, making them suitable on a wide
range of systems. They have also been designed to minimize leakage range of systems. They have also been designed to minimize leakage
of information through side channels. of information through side channels.
1.1. The ChaCha20 and Poly1305 AEAD Construction 1.1. The ChaCha20 and Poly1305 AEAD Construction
ChaCha20 and Poly1305 have been combined to create an Authenticated ChaCha20 and Poly1305 have been combined to create an Authenticated
Encryption with Associated Data (AEAD) algorithm [AEAD]. This AEAD Encryption with Associated Data (AEAD) algorithm [AEAD]. This AEAD
algorithm is often referred to as AEAD_CHACHA20_POLY1305, and it is algorithm is often referred to as AEAD_CHACHA20_POLY1305, and it is
described in [FORIETF]. described [FORIETF].
AEAD_CHACHA20_POLY1305 accepts four inputs: a 256-bit key, a 96-bit AEAD_CHACHA20_POLY1305 accepts four inputs: a 256-bit key, a 96-bit
nonce, an arbitrary length plaintext, and an arbitrary length nonce, an arbitrary length plaintext, and an arbitrary length
additional authenticated data (AAD). As the name implies, a nonce additional authenticated data (AAD). As the name implies, a nonce
value cannot be used securely more than once with the same key. value cannot be used securely more than once with the same key.
A high-level summary of AEAD_CHACHA20_POLY1305 authenticated A high-level summary of AEAD_CHACHA20_POLY1305 authenticated
encryption processing is: encryption processing is:
1) A Poly1305 one-time key is generated from the 256-bit key and 1) A 256-bit Poly1305 one-time key is generated from the input
and nonce using the procedure described in Section 2.6 of 256-bit key and nonce using the procedure described in
[FORIETF]. Section 2.6 of [FORIETF].
2) The ChaCha20 encryption function is used to encrypt the 2) The ChaCha20 encryption function is used to encrypt the
plaintext, using the same key and nonce, and with the initial plaintext, using the same 256-bit key and nonce, and with the
counter set to 1. initial counter set to 1.
3) The Poly1305 function is used with the Poly1305 key from 3) The Poly1305 function is used with the Poly1305 key from
step 1, and a buffer constructed as a concatenation of the AAD, step 1, and a buffer constructed as a concatenation of the AAD,
padding1, the ciphertext, padding2, the length of the AAD in padding1, the ciphertext, padding2, the length of the AAD in
octets, and the length of the ciphertext in octets. The octets, and the length of the ciphertext in octets. The
padding fields contain up to 15 octets, with all bits set to padding fields contain up to 15 octets, with all bits set to
zero, and the padding brings the total length of the buffer so zero, and the padding brings the total length of the buffer so
far to an integral multiple of 16. If the buffer length was far to an integral multiple of 16. If the buffer length was
already an integral multiple of 16 octets, then the padding already an integral multiple of 16 octets, then the padding
field is zero octets. The length fields contain 64-bit little- field is zero octets. The length fields contain 64-bit little-
skipping to change at page 3, line 43 skipping to change at page 3, line 43
1.3. ASN.1 1.3. ASN.1
CMS values are generated using ASN.1 [X680], which uses the Basic CMS values are generated using ASN.1 [X680], which uses the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
[X690]. [X690].
2. Automated Key Management 2. Automated Key Management
The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key
destroys the security guarantees. As a result, it can be extremely destroys the security guarantees. I can be extremely difficult to
difficult to use AEAD_CHACHA20_POLY1305 securely when using use a statically configured AEAD_CHACHA20_POLY1305 key and never
statically configured keys. For safety's sake, implementations MUST repeat a nonce value. For safety's sake, implementations MUST use an
use an automated key management system [KEYMGMT]. automated key management system [KEYMGMT].
The CMS authenticated-enveloped-data content type supports four The CMS authenticated-enveloped-data content type supports four
general key management techniques: general key management techniques:
Key Transport: the content-authenticated-encryption key is Key Transport: the content-authenticated-encryption key is
encrypted in the recipient's public key; encrypted in the recipient's public key;
Key Agreement: the recipient's public key and the sender's Key Agreement: the recipient's public key and the sender's
private key are used to generate a pairwise symmetric key, then private key are used to generate a pairwise symmetric key, then
the content-authenticated-encryption key is encrypted in the the content-authenticated-encryption key is encrypted in the
skipping to change at page 6, line 40 skipping to change at page 6, line 40
generators (PRNGs) to generate cryptographic keys can result in generators (PRNGs) to generate cryptographic keys can result in
little or no security. An attacker may find it much easier to little or no security. An attacker may find it much easier to
reproduce the PRNG environment that produced the keys, searching the reproduce the PRNG environment that produced the keys, searching the
resulting small set of possibilities, rather than brute force resulting small set of possibilities, rather than brute force
searching the whole key space. The generation of quality random searching the whole key space. The generation of quality random
numbers is difficult. RFC 4086 [RANDOM] offers important guidance in numbers is difficult. RFC 4086 [RANDOM] offers important guidance in
this area. this area.
7. Acknowledgements 7. Acknowledgements
Thanks to Jim Schaad for his review and insightful comments. Thanks to Jim Schaad and Daniel Migault for their review and
insightful comments.
8. Normative References 8. Normative References
[AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) [AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083, Authenticated-Enveloped-Data Content Type", RFC 5083,
November 2007. November 2007.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
5652, September 2009. 5652, September 2009.
 End of changes. 7 change blocks. 
13 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/