< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/