< draft-nir-cfrg-chacha20-poly1305-04.txt		draft-nir-cfrg-chacha20-poly1305-05.txt >
	Network Working Group Y. Nir		Network Working Group Y. Nir
	Internet-Draft Check Point		Internet-Draft Check Point
	Intended status: Informational A. Langley		Intended status: Informational A. Langley
	Expires: November 22, 2014 Google Inc		Expires: December 21, 2014 Google Inc
	May 21, 2014		June 19, 2014
	ChaCha20 and Poly1305 for IETF protocols		ChaCha20 and Poly1305 for IETF protocols
	draft-nir-cfrg-chacha20-poly1305-04		draft-nir-cfrg-chacha20-poly1305-05
	Abstract		Abstract
	This document defines the ChaCha20 stream cipher, as well as the use		This document defines the ChaCha20 stream cipher, as well as the use
	of the Poly1305 authenticator, both as stand-alone algorithms, and as		of the Poly1305 authenticator, both as stand-alone algorithms, and as
	a "combined mode", or Authenticated Encryption with Additional Data		a "combined mode", or Authenticated Encryption with Additional Data
	(AEAD) algorithm.		(AEAD) algorithm.
	This document does not introduce any new crypto, but is meant to		This document does not introduce any new crypto, but is meant to
	serve as a stable reference and an implementation guide.		serve as a stable reference and an implementation guide.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 22, 2014.		This Internet-Draft will expire on December 21, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 24 ¶		skipping to change at page 3, line 24 ¶
	The problem is that if future advances in cryptanalysis reveal a		The problem is that if future advances in cryptanalysis reveal a
	weakness in AES, users will be in an unenviable position. With the		weakness in AES, users will be in an unenviable position. With the
	only other widely supported cipher being the much slower 3DES, it is		only other widely supported cipher being the much slower 3DES, it is
	not feasible to re-configure implementations to use 3DES.		not feasible to re-configure implementations to use 3DES.
	[standby-cipher] describes this issue and the need for a standby		[standby-cipher] describes this issue and the need for a standby
	cipher in greater detail.		cipher in greater detail.
	This document defines such a standby cipher. We use ChaCha20		This document defines such a standby cipher. We use ChaCha20
	([chacha]) with or without the Poly1305 ([poly1305]) authenticator.		([chacha]) with or without the Poly1305 ([poly1305]) authenticator.
	These algorithms are not just fast and secure. They are fast even in		These algorithms are not just fast. They are fast even in software-
	software-only C-language implementations, allowing for much quicker		only C-language implementations, allowing for much quicker deployment
	deployment when compared with algorithms such as AES that are		when compared with algorithms such as AES that are significantly
	significantly accelerated by hardware implementations.		accelerated by hardware implementations.
	These document does not introduce these new algorithms. They have		This document does not introduce these new algorithms. They have
	been defined in scientific papers by D. J. Bernstein, which are		been defined in scientific papers by D. J. Bernstein, which are
	referenced by this document. The purpose of this document is to		referenced by this document. The purpose of this document is to
	serve as a stable reference for IETF documents making use of these		serve as a stable reference for IETF documents making use of these
	algorithms.		algorithms.
			These algorithms have undergone rigorous analysis. Several papers
			discuss the security of Salsa and ChaCha ([LatinDances],
			[Zhenqing2012]).
	1.1. Conventions Used in This Document		1.1. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	The description of the ChaCha algorithm will at various time refer to		The description of the ChaCha algorithm will at various time refer to
	the ChaCha state as a "vector" or as a "matrix". This follows the		the ChaCha state as a "vector" or as a "matrix". This follows the
	use of these terms in DJB's paper. The matrix notation is more		use of these terms in DJB's paper. The matrix notation is more
	visually convenient, and gives a better notion as to why some rounds		visually convenient, and gives a better notion as to why some rounds
	are called "column rounds" while others are called "diagonal rounds".		are called "column rounds" while others are called "diagonal rounds".
	Here's a diagram of how to martices relate to vectors (using the C		Here's a diagram of how to matrices relate to vectors (using the C
	language convention of zero being the index origin).		language convention of zero being the index origin).
	0 1 2 3		0 1 2 3
	4 5 6 7		4 5 6 7
	8 9 10 11		8 9 10 11
	12 13 14 15		12 13 14 15
	The elements in this vector or matrix are 32-bit unsigned integers.		The elements in this vector or matrix are 32-bit unsigned integers.
	The algorithm name is "ChaCha". "ChaCha20" is a specific instance		The algorithm name is "ChaCha". "ChaCha20" is a specific instance
	skipping to change at page 7, line 30 ¶		skipping to change at page 7, line 30 ¶
	of a "diagonal" round:		of a "diagonal" round:
	1. QUARTERROUND ( 0, 4, 8,12)		1. QUARTERROUND ( 0, 4, 8,12)
	2. QUARTERROUND ( 1, 5, 9,13)		2. QUARTERROUND ( 1, 5, 9,13)
	3. QUARTERROUND ( 2, 6,10,14)		3. QUARTERROUND ( 2, 6,10,14)
	4. QUARTERROUND ( 3, 7,11,15)		4. QUARTERROUND ( 3, 7,11,15)
	5. QUARTERROUND ( 0, 5,10,15)		5. QUARTERROUND ( 0, 5,10,15)
	6. QUARTERROUND ( 1, 6,11,12)		6. QUARTERROUND ( 1, 6,11,12)
	7. QUARTERROUND ( 2, 7, 8,13)		7. QUARTERROUND ( 2, 7, 8,13)
	8. QUARTERROUND ( 3, 4, 9,14)		8. QUARTERROUND ( 3, 4, 9,14)
	At the end of 20 rounds, the original input words are added to the		At the end of 20 rounds, we arithmetically add the original input
	output words, and the result is serialized by sequencing the words		words to the output words, and serialize the result by sequencing the
	one-by-one in little-endian order.		words one-by-one in little-endian order.
	2.3.1. Test Vector for the ChaCha20 Block Function		2.3.1. Test Vector for the ChaCha20 Block Function
	For a test vector, we will use the following inputs to the ChaCha20		For a test vector, we will use the following inputs to the ChaCha20
	block function:		block function:
	o Key = 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f:10:11:12:13:		o Key = 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f:10:11:12:13:
	14:15:16:17:18:19:1a:1b:1c:1d:1e:1f. The key is a sequence of		14:15:16:17:18:19:1a:1b:1c:1d:1e:1f. The key is a sequence of
	octets with no particular structure before we copy it into the		octets with no particular structure before we copy it into the
	ChaCha state.		ChaCha state.
	o Nonce = (00:00:00:09:00:00:00:4a:00:00:00:00)		o Nonce = (00:00:00:09:00:00:00:4a:00:00:00:00)
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	032 d2 82 64 46 07 9f aa 09 14 c2 d7 05 d9 8b 02 a2 ..dF............		032 d2 82 64 46 07 9f aa 09 14 c2 d7 05 d9 8b 02 a2 ..dF............
	048 b5 12 9c d1 de 16 4e b9 cb d0 83 e8 a2 50 3c 4e ......N......P<N		048 b5 12 9c d1 de 16 4e b9 cb d0 83 e8 a2 50 3c 4e ......N......P<N
	2.4. The ChaCha20 encryption algorithm		2.4. The ChaCha20 encryption algorithm
	ChaCha20 is a stream cipher designed by D. J. Bernstein. It is a		ChaCha20 is a stream cipher designed by D. J. Bernstein. It is a
	refinement of the Salsa20 algorithm, and uses a 256-bit key.		refinement of the Salsa20 algorithm, and uses a 256-bit key.
	ChaCha20 successively calls the ChaCha20 block function, with the		ChaCha20 successively calls the ChaCha20 block function, with the
	same key and nonce, and with successively increasing block counter		same key and nonce, and with successively increasing block counter
	parameters. The resulting state is then serialized by writing the		parameters. ChaCha20 then serializes the resulting state by writing
	numbers in little-endian order, creating a key-stream block.		the numbers in little-endian order, creating a key-stream block.
	Concatenating the key-stream blocks from the successive blocks forms		Concatenating the key-stream blocks from the successive blocks forms
	a key stream, which is then XOR-ed with the plaintext.		a key stream, which is then XOR-ed with the plaintext.
	Alternatively, each key-stream block can be XOR-ed with a plaintext		Alternatively, each key-stream block can be XOR-ed with a plaintext
	block before proceeding to create the next block, saving some memory.		block before proceeding to create the next block, saving some memory.
	There is no requirement for the plaintext to be an integral multiple		There is no requirement for the plaintext to be an integral multiple
	of 512-bits. If there is extra keystream from the last block, it is		of 512-bits. If there is extra keystream from the last block, it is
	discarded. Specific protocols MAY require that the plaintext and		discarded. Specific protocols MAY require that the plaintext and
	ciphertext have certain length. Such protocols need to specify how		ciphertext have certain length. Such protocols need to specify how
	the plaintext is padded, and how much padding it receives.		the plaintext is padded, and how much padding it receives.
	The inputs to ChaCha20 are:		The inputs to ChaCha20 are:
	o A 256-bit key		o A 256-bit key
	o A 32-bit initial counter. This can be set to any number, but will		o A 32-bit initial counter. This can be set to any number, but will
	usually be zero or one. It makes sense to use 1 if we use the		usually be zero or one. It makes sense to use 1 if we use the
	zero block for something else, such as generating a one-time		zero block for something else, such as generating a one-time
	authenticator key as part of an AEAD algorithm.		authenticator key as part of an AEAD algorithm.
	o A 96-bit nonce. In some protocols, this is known as the		o A 96-bit nonce. In some protocols, this is known as the
	Initialization Vector.		Initialization Vector.
	o an arbitrary-length plaintext		o An arbitrary-length plaintext
	The output is an encrypted message of the same length.		The output is an encrypted message of the same length.
	Decryption is done in the same way. The ChaCha20 block function is		Decryption is done in the same way. The ChaCha20 block function is
	used to expand the key into a key stream, which is XOR-ed with the		used to expand the key into a key stream, which is XOR-ed with the
	ciphertext giving back the plaintext.		ciphertext giving back the plaintext.
	2.4.1. Example and Test Vector for the ChaCha20 Cipher		2.4.1. Example and Test Vector for the ChaCha20 Cipher
	For a test vector, we will use the following inputs to the ChaCha20		For a test vector, we will use the following inputs to the ChaCha20
	skipping to change at page 11, line 18 ¶		skipping to change at page 11, line 18 ¶
	Poly1305 takes a 32-byte one-time key and a message and produces a		Poly1305 takes a 32-byte one-time key and a message and produces a
	16-byte tag.		16-byte tag.
	The original article ([poly1305]) is entitled "The Poly1305-AES		The original article ([poly1305]) is entitled "The Poly1305-AES
	message-authentication code", and the MAC function there requires a		message-authentication code", and the MAC function there requires a
	128-bit AES key, a 128-bit "additional key", and a 128-bit (non-		128-bit AES key, a 128-bit "additional key", and a 128-bit (non-
	secret) nonce. AES is used there for encrypting the nonce, so as to		secret) nonce. AES is used there for encrypting the nonce, so as to
	get a unique (and secret) 128-bit string, but as the paper states,		get a unique (and secret) 128-bit string, but as the paper states,
	"There is nothing special about AES here. One can replace AES with		"There is nothing special about AES here. One can replace AES with
	an arbitrary keyed function from an arbitrary set of nonces to 16-		an arbitrary keyed function from an arbitrary set of nonces to 16-
	byte strings.".		byte strings."
	Regardless of how the key is generated, the key is partitioned into		Regardless of how the key is generated, the key is partitioned into
	two parts, called "r" and "s". The pair (r,s) should be unique, and		two parts, called "r" and "s". The pair (r,s) should be unique, and
	MUST be unpredictable for each invocation (that is why it was		MUST be unpredictable for each invocation (that is why it was
	originally obtained by encrypting a nonce), while "r" MAY be		originally obtained by encrypting a nonce), while "r" MAY be
	constant, but needs to be modified as follows before being used: ("r"		constant, but needs to be modified as follows before being used: ("r"
	is treated as a 16-octet little-endian number):		is treated as a 16-octet little-endian number):
	o r[3], r[7], r[11], and r[15] are required to have their top four		o r[3], r[7], r[11], and r[15] are required to have their top four
	bits clear (be smaller than 16)		bits clear (be smaller than 16)
	o r[4], r[8], and r[12] are required to have their bottom two bits		o r[4], r[8], and r[12] are required to have their bottom two bits
	skipping to change at page 14, line 30 ¶		skipping to change at page 14, line 30 ¶
	parameters:		parameters:
	o The 256-bit session integrity key is used as the ChaCha20 key.		o The 256-bit session integrity key is used as the ChaCha20 key.
	o The block counter is set to zero.		o The block counter is set to zero.
	o The protocol will specify a 96-bit or 64-bit nonce. This MUST be		o The protocol will specify a 96-bit or 64-bit nonce. This MUST be
	unique per invocation with the same key, so it MUST NOT be		unique per invocation with the same key, so it MUST NOT be
	randomly generated. A counter is a good way to implement this,		randomly generated. A counter is a good way to implement this,
	but other methods, such as an LFSR are also acceptable. ChaCha20		but other methods, such as an LFSR are also acceptable. ChaCha20
	as specified here requires a 96-bit nonce. So if the provided		as specified here requires a 96-bit nonce. So if the provided
	nonce is only 64-bit, then the first 32 bits of the nonce will be		nonce is only 64-bit, then the first 32 bits of the nonce will be
	set to a constant number. This will usually be zero, but for		set to a constant number. This will usually be zero, but for
	protocols with multiple sender, it may be different for each		protocols with multiple senders it may be different for each
	sender, but should be the same for all invocations of the function		sender, but should be the same for all invocations of the function
	with the same key by a particular sender.		with the same key by a particular sender.
	After running the block function, we have a 512-bit state. We take		After running the block function, we have a 512-bit state. We take
	the first 256 bits or the serialized state, and use those as the one-		the first 256 bits or the serialized state, and use those as the one-
	time Poly1305 key: The first 128 bits are clamped, and form "r",		time Poly1305 key: The first 128 bits are clamped, and form "r",
	while the next 128 bits become "s". The other 256 bits are		while the next 128 bits become "s". The other 256 bits are
	discarded.		discarded.
	Note that while many protocols have provisions for a nonce for		Note that while many protocols have provisions for a nonce for
	skipping to change at page 15, line 37 ¶		skipping to change at page 15, line 37 ¶
	Some protocols such as IKEv2([RFC5996]) require a Pseudo-Random		Some protocols such as IKEv2([RFC5996]) require a Pseudo-Random
	Function (PRF), mostly for key derivation. In the IKEv2 definition,		Function (PRF), mostly for key derivation. In the IKEv2 definition,
	a PRF is a function that accepts a variable-length key and a		a PRF is a function that accepts a variable-length key and a
	variable-length input, and returns a fixed-length output. This		variable-length input, and returns a fixed-length output. This
	section does not specify such a function.		section does not specify such a function.
	Poly-1305 is an obvious choice, because MAC functions are often used		Poly-1305 is an obvious choice, because MAC functions are often used
	as PRFs. However, Poly-1305 prohibits using the same key twice,		as PRFs. However, Poly-1305 prohibits using the same key twice,
	whereas the PRF in IKEv2 is used multiple times with the same key.		whereas the PRF in IKEv2 is used multiple times with the same key.
	This issue can be solved by adding a nonce or a counter to Poly-1305,		Adding a nonce or a counter to Poly-1305 can solve this issue, much
	much as we do when using this function as a MAC, but that would		as we do when using this function as a MAC, but that would require
	require changing the interface for the PRF function.		changing the interface for the PRF function.
	Chacha20 could be used as a key-derivation function, by generating an		Chacha20 could be used as a key-derivation function, by generating an
	arbitrarily long keystream. However, that is not what protocols such		arbitrarily long keystream. However, that is not what protocols such
	as IKEv2 require.		as IKEv2 require.
	For this reason, this document does not specify a PRF, and recommends		For this reason, this document does not specify a PRF, and recommends
	that crypto suites use some other PRF such as PRF_HMAC_SHA2_256		that crypto suites use some other PRF such as PRF_HMAC_SHA2_256
	(section 2.1.2 of [RFC4868])		(section 2.1.2 of [RFC4868])
	2.8. AEAD Construction		2.8. AEAD Construction
	skipping to change at page 16, line 33 ¶		skipping to change at page 16, line 33 ¶
	o The ChaCha20 encryption function is called to encrypt the		o The ChaCha20 encryption function is called to encrypt the
	plaintext, using the same key and nonce, and with the initial		plaintext, using the same key and nonce, and with the initial
	counter set to 1.		counter set to 1.
	o The Poly1305 function is called with the Poly1305 key calculated		o The Poly1305 function is called with the Poly1305 key calculated
	above, and a message constructed as a concatenation of the		above, and a message constructed as a concatenation of the
	following:		following:
	* The AAD		* The AAD
	* padding1 - the padding is up to 15 zero bytes, and it brings		* padding1 - the padding is up to 15 zero bytes, and it brings
	the total length so far to an integral multiple of 16. If the		the total length so far to an integral multiple of 16. If the
	length of the AAD was already an integral multiple of 16 bytes,		length of the AAD was already an integral multiple of 16 bytes,
	this field is zero-length,		this field is zero-length.
	* The ciphertext		* The ciphertext
	* padding2 - the padding is up to 15 zero bytes, and it brings		* padding2 - the padding is up to 15 zero bytes, and it brings
	the total length so far to an integral multiple of 16. If the		the total length so far to an integral multiple of 16. If the
	length of the ciphertext was already an integral multiple of 16		length of the ciphertext was already an integral multiple of 16
	bytes, this field is zero-length,		bytes, this field is zero-length.
	* The length of the additional data in octets (as a 64-bit		* The length of the additional data in octets (as a 64-bit
	little-endian integer). TBD: bit count rather than octets?		little-endian integer).
	network order?
	* The length of the ciphertext in octets (as a 64-bit little-		* The length of the ciphertext in octets (as a 64-bit little-
	endian integer). TBD: bit count rather than octets? network		endian integer).
	order?
	Decryption is pretty much the same thing.		Decryption is pretty much the same thing.
	The output from the AEAD is twofold:		The output from the AEAD is twofold:
	o A ciphertext of the same length as the plaintext.		o A ciphertext of the same length as the plaintext.
	o A 128-bit tag, which is the output of the Poly1305 function.		o A 128-bit tag, which is the output of the Poly1305 function.
	A few notes about this design:		A few notes about this design:
	1. The amount of encrypted data possible in a single invocation is		1. The amount of encrypted data possible in a single invocation is
	skipping to change at page 19, line 29 ¶		skipping to change at page 19, line 29 ¶
	Tag:		Tag:
	1a:e1:0b:59:4f:09:e2:6a:7e:90:2e:cb:d0:60:06:91		1a:e1:0b:59:4f:09:e2:6a:7e:90:2e:cb:d0:60:06:91
	3. Implementation Advice		3. Implementation Advice
	Each block of ChaCha20 involves 16 move operations and one increment		Each block of ChaCha20 involves 16 move operations and one increment
	operation for loading the state, 80 each of XOR, addition and Roll		operation for loading the state, 80 each of XOR, addition and Roll
	operations for the rounds, 16 more add operations and 16 XOR		operations for the rounds, 16 more add operations and 16 XOR
	operations for protecting the plaintext. Section 2.3 describes the		operations for protecting the plaintext. Section 2.3 describes the
	ChaCha block function as "adding the original input words". This		ChaCha block function as "adding the original input words". This
	implies that before starting the rounds on the ChaCha state, it is		implies that before starting the rounds on the ChaCha state, it we
	copied aside only to be added in later. This would be correct, but		copy it aside, only to be added in later. This behaves correctly,
	it saves a few operations to instead copy the state and do the work		but it saves a few operations to instead copy the state and do the
	on the copy. This way, for the next block you don't need to recreate		work on the copy. This way, for the next block you don't need to
	the state, but only to increment the block counter. This saves		recreate the state, but only to increment the block counter. This
	approximately 5.5% of the cycles.		saves approximately 5.5% of the cycles.
	It is NOT RECOMMENDED to use a generic big number library such as the		It is not recommended to use a generic big number library such as the
	one in OpenSSL for the arithmetic operations in Poly1305. Such		one in OpenSSL for the arithmetic operations in Poly1305. Such
	libraries use dynamic allocation to be able to handle any-sized		libraries use dynamic allocation to be able to handle any-sized
	integer, but that flexibility comes at the expense of performance as		integer, but that flexibility comes at the expense of performance as
	well as side-channel security. More efficient implementations that		well as side-channel security. More efficient implementations that
	run in constant time are available, one of them in DJB's own library,		run in constant time are available, one of them in DJB's own library,
	NaCl ([NaCl]). A constant-time but not optimal approach would be to		NaCl ([NaCl]). A constant-time but not optimal approach would be to
	naively implement the arithmetic operations for a 288-bit integers,		naively implement the arithmetic operations for a 288-bit integers,
	because even a naive implementation will not exceed 2^288 in the		because even a naive implementation will not exceed 2^288 in the
	multiplication of (acc+block) and r. An efficient constant-time		multiplication of (acc+block) and r. An efficient constant-time
	implementation can be found in the public domain library poly1305-		implementation can be found in the public domain library poly1305-
	skipping to change at page 21, line 16 ¶		skipping to change at page 21, line 16 ¶
	There are no IANA considerations for this document.		There are no IANA considerations for this document.
	6. Acknowledgements		6. Acknowledgements
	ChaCha20 and Poly1305 were invented by Daniel J. Bernstein. The AEAD		ChaCha20 and Poly1305 were invented by Daniel J. Bernstein. The AEAD
	construction and the method of creating the one-time poly1305 key		construction and the method of creating the one-time poly1305 key
	were invented by Adam Langley.		were invented by Adam Langley.
	Thanks to Robert Ransom and Ilari Liusvaara for their helpful		Thanks to Robert Ransom and Ilari Liusvaara for their helpful
	comments and explanations. Thanks to Niels Moeller for suggesting a		comments and explanations. Thanks to Niels Moeller for suggesting
	more efficient AEAD construction.		the more efficient AEAD construction in this document.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[chacha] Bernstein, D., "ChaCha, a variant of Salsa20", Jan 2008.		[chacha] Bernstein, D., "ChaCha, a variant of Salsa20", Jan 2008.
	skipping to change at page 21, line 47 ¶		skipping to change at page 21, line 47 ¶
	<http://cseweb.ucsd.edu/~mihir/papers/oem.html>.		<http://cseweb.ucsd.edu/~mihir/papers/oem.html>.
	[FIPS-197]		[FIPS-197]
	National Institute of Standards and Technology, "Advanced		National Institute of Standards and Technology, "Advanced
	Encryption Standard (AES)", FIPS PUB 197, November 2001.		Encryption Standard (AES)", FIPS PUB 197, November 2001.
	[FIPS-46] National Institute of Standards and Technology, "Data		[FIPS-46] National Institute of Standards and Technology, "Data
	Encryption Standard", FIPS PUB 46-2, December 1993,		Encryption Standard", FIPS PUB 46-2, December 1993,
	<http://www.itl.nist.gov/fipspubs/fip46-2.htm>.		<http://www.itl.nist.gov/fipspubs/fip46-2.htm>.
			[LatinDances]
			Aumasson, J., Fischer, S., Khazaei, S., Meier, W., and C.
			Rechberger, "New Features of Latin Dances: Analysis of
			Salsa, ChaCha, and Rumba", Dec 2007.
	[NaCl] Bernstein, D., Lange, T., and P. Schwabe, "NaCl:		[NaCl] Bernstein, D., Lange, T., and P. Schwabe, "NaCl:
	Networking and Cryptography library",		Networking and Cryptography library",
	<http://nacl.cace-project.eu/index.html>.		<http://nacl.cace-project.eu/index.html>.
	[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-		[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
	384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.		384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
	[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated		[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
	Encryption", RFC 5116, January 2008.		Encryption", RFC 5116, January 2008.
	[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,		[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
	"Internet Key Exchange Protocol Version 2 (IKEv2)",		"Internet Key Exchange Protocol Version 2 (IKEv2)",
	RFC 5996, September 2010.		RFC 5996, September 2010.
			[Zhenqing2012]
			Zhenqing, S., Bin, Z., Dengguo, F., and W. Wenling,
			"Improved key recovery attacks on reduced-round salsa20
			and chacha", 2012.
	[poly1305_donna]		[poly1305_donna]
	Floodyberry, A., "Poly1305-donna",		Floodyberry, A., "Poly1305-donna",
	<https://github.com/floodyberry/poly1305-donna>.		<https://github.com/floodyberry/poly1305-donna>.
	[standby-cipher]		[standby-cipher]
	McGrew, D., Grieco, A., and Y. Sheffer, "Selection of		McGrew, D., Grieco, A., and Y. Sheffer, "Selection of
	Future Cryptographic Standards",		Future Cryptographic Standards",
	draft-mcgrew-standby-cipher (work in progress).		draft-mcgrew-standby-cipher (work in progress).
	Appendix A. Additional Test Vectors		Appendix A. Additional Test Vectors
End of changes. 22 change blocks.
	36 lines changed or deleted		48 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/