< draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt		draft-mcgrew-aead-aes-cbc-hmac-sha2-01.txt >
	Network Working Group D. McGrew		Network Working Group D. McGrew
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Intended status: Standards Track K. Paterson		Intended status: Standards Track K. Paterson
	Expires: December 13, 2012 Royal Holloway, University of		Expires: April 25, 2013 Royal Holloway, University of
	London		London
	June 11, 2012		October 22, 2012
	Authenticated Encryption with AES-CBC and HMAC-SHA		Authenticated Encryption with AES-CBC and HMAC-SHA
	draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt		draft-mcgrew-aead-aes-cbc-hmac-sha2-01.txt
	Abstract		Abstract
	This document specifies algorithms for authenticated encryption with		This document specifies algorithms for authenticated encryption with
	associated data (AEAD) that are based on the composition of the		associated data (AEAD) that are based on the composition of the
	Advanced Encryption Standard (AES) in the Cipher Block Chaining (CBC)		Advanced Encryption Standard (AES) in the Cipher Block Chaining (CBC)
	mode of operation for encryption, and the HMAC-SHA message		mode of operation for encryption, and the HMAC-SHA message
	authentication code (MAC).		authentication code (MAC).
	These are randomized encryption algorithms, and thus are suitable for		These are randomized encryption algorithms, and thus are suitable for
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 December 13, 2012.		This Internet-Draft will expire on April 25, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Conventions Used In This Document . . . . . . . . . . . . 3		1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. CBC-HMAC algorithms . . . . . . . . . . . . . . . . . . . . . 4		1.2. Conventions Used In This Document . . . . . . . . . . . . 4
	2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 4		2. CBC-HMAC algorithms . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Length . . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.2. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.4. AEAD_AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . 7		2.3. Length . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.5. AEAD_AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 8		2.4. AEAD_AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . 8
	2.6. AEAD_AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . 8		2.5. AEAD_AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 9
	2.7. AEAD_AES_128_CBC_HMAC_SHA1 . . . . . . . . . . . . . . . . 9		2.6. AEAD_AES_256_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 9
	2.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9		2.7. AEAD_AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . 10
	3. Randomness Requirements . . . . . . . . . . . . . . . . . . . 10		2.8. AEAD_AES_128_CBC_HMAC_SHA1 . . . . . . . . . . . . . . . . 10
	4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 11		2.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 13		3. Randomness Requirements . . . . . . . . . . . . . . . . . . . 12
	5.1. AEAD_AES_128_CBC_HMAC_SHA1 . . . . . . . . . . . . . . . . 13		4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.2. AEAD_AES_128_CBC_HMAC_SHA256 . . . . . . . . . . . . . . . 14		5. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.3. AEAD_AES_192_CBC_HMAC_SHA384 . . . . . . . . . . . . . . . 15		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	5.4. AEAD_AES_256_CBC_HMAC_SHA512 . . . . . . . . . . . . . . . 16		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		8.2. Informative References . . . . . . . . . . . . . . . . . . 18
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 19		Appendix A. CBC Encryption and Decryption . . . . . . . . . . . . 21
	8.2. Informative References . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
	Appendix A. CBC Encryption and Decryption . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	Authenticated Encryption (AE) [BN00] is a form of encryption that, in		Authenticated Encryption (AE) [BN00] is a form of encryption that, in
	addition to providing confidentiality for the plaintext that is		addition to providing confidentiality for the plaintext that is
	encrypted, provides a way to check its integrity and authenticity.		encrypted, provides a way to check its integrity and authenticity.
	This combination of features can, when properly implemented, provide		This combination of features can, when properly implemented, provide
	security against adversaries who have access to full decryption		security against adversaries who have access to full decryption
	capabilities for ciphertexts of their choice, and access to full		capabilities for ciphertexts of their choice, and access to full
	encryption capabilities for plaintexts of their choice. The strong		encryption capabilities for plaintexts of their choice. The strong
	form of security provided by AE is known to robust against a large		form of security provided by AE is known to robust against a large
	class of adversaries for general purpose applications of AE,		class of adversaries for general purpose applications of AE,
	including applications such as securing network communications over		including applications such as securing network communications over
	untrusted networks. The strong security properties of AE stand in		untrusted networks. The strong security properties of AE stand in
	contrast to the known weaknesses of "encryption only" forms of		contrast to the known weaknesses of "encryption only" forms of
	encryption, see [B96][YHR04][DP09] for examples.		encryption, see [B96][YHR04] [DP07] for examples.
	Authenticated encryption with Associated Data, or AEAD [R02], adds		Authenticated encryption with Associated Data, or AEAD [R02], adds
	the ability to check the integrity and authenticity of some		the ability to check the integrity and authenticity of some
	associated data (sometimes called "additional authenticated data")		associated data (sometimes called "additional authenticated data")
	for which confidentiality is not required (or is not desirable).		for which confidentiality is not required (or is not desirable).
	While many approaches to building AEAD schemes are known, a		While many approaches to building AEAD schemes are known, a
	particularly simple, well-understood, and cryptographically strong		particularly simple, well-understood, and cryptographically strong
	method is to employ an "Encrypt-then-MAC" construction. This		method is to employ an "Encrypt-then-MAC" construction. This
	document defines new AEAD algorithms of this general type, using the		document defines new AEAD algorithms of this general type, using the
	interface defined in [RFC5116], based on the Advanced Encryption		interface defined in [RFC5116], based on the Advanced Encryption
	Standard (AES) [FIPS197] in the Cipher Block Chaining (CBC) mode of		Standard (AES) [FIPS197] in the Cipher Block Chaining (CBC) mode of
	operation [SP800-38] and HMAC using the Secure Hash Algorithm (SHA)		operation [SP800-38] and HMAC using the Secure Hash Algorithm (SHA)
	[FIPS186-2], with security levels of 128, 192, and 256 bits.		[FIPS186-2], with security levels of 128, 192, and 256 bits.
	1.1. Conventions Used In This Document		1.1. History
			This subsection describes the revision history of this Internet
			Draft. It should be removed by the RFC Editor before publication as
			an RFC.
			The changes of version 01 from version 00 are:
			MIN_LEN_A and associated logic was eliminated.
			Padding String (PS) typo corrected in Section 2.1.
			Decryption Step 3 refers to the appropriate step in the encryption
			process.
			Random IV min-entropy clarified in Section 3.
			HMAC keys are now the same size as the truncated output (128 or
			256 bits). Previously, the HMAC keys were the same size as the
			full hash output (256, 384, or 512 bits).
			An algorithm based on the combination of AES-256 and HMAC-SHA-384
			has been added, for compatibility with
			draft-burgin-kerberos-aes-cbc-hmac-sha2.
			The test cases in the previous version are no longer valid, and
			thus have been removed. New test cases have been computed (and
			the authors thank John Foley for this contribution) but have not
			been included, pending confirmation from a second, independent
			implementation.
			1.2. Conventions Used In This Document
	We use the following notational conventions.		We use the following notational conventions.
	CBC-ENC(X,P) denotes the CBC encryption of P using the cipher with		CBC-ENC(X,P) denotes the CBC encryption of P using the cipher with
	the key X		the key X
	MAC(Y, M) denotes the application of the Message Authentication		MAC(Y, M) denotes the application of the Message Authentication
	Code (MAC) to the message M, using the key Y		Code (MAC) to the message M, using the key Y
	The concatenation of two octet strings A and B is denoted as		The concatenation of two octet strings A and B is denoted as
	skipping to change at page 4, line 15 ¶		skipping to change at page 5, line 15 ¶
	2. CBC-HMAC algorithms		2. CBC-HMAC algorithms
	This section defines CBC-HMAC, an algorithm based on the the encrypt-		This section defines CBC-HMAC, an algorithm based on the the encrypt-
	then-MAC method defined in Section 4.3 of [BN00]. That method		then-MAC method defined in Section 4.3 of [BN00]. That method
	constructs a randomized AEAD algorithm out of a randomized cipher,		constructs a randomized AEAD algorithm out of a randomized cipher,
	such as a block cipher mode of operation that uses a random		such as a block cipher mode of operation that uses a random
	initialization vector, and a MAC.		initialization vector, and a MAC.
	Section 2.1 and Section 2.2 define the CBC-HMAC encryption and		Section 2.1 and Section 2.2 define the CBC-HMAC encryption and
	decryption algorithms, without specifying the particular block cipher		decryption algorithms, without specifying the particular block cipher
	or hash function to be used. Section 2.4, Section 2.5, Section 2.6,		or hash function to be used. Section 2.4, Section 2.5, Section 2.7,
	and Section 2.7, define instances of CBC-HMAC that specify those		and Section 2.8, define instances of CBC-HMAC that specify those
	details.		details.
	2.1. Encryption		2.1. Encryption
	We briefly recall the encryption interface defined in Section 2 of		We briefly recall the encryption interface defined in Section 2 of
	[RFC5116]. The AEAD encryption algorithm takes as input four octet		[RFC5116]. The AEAD encryption algorithm takes as input four octet
	strings: a secret key K, a plaintext P, associated data A, and a		strings: a secret key K, a plaintext P, associated data A, and a
	nonce N. An authenticated ciphertext value is provided as output.		nonce N. An authenticated ciphertext value is provided as output.
	The data in the plaintext are encrypted and authenticated, and the		The data in the plaintext are encrypted and authenticated, and the
	associated data are authenticated, but not encrypted.		associated data are authenticated, but not encrypted.
	In CBC-HMAC, the nonce MUST be a zero-length string; a nonce is not		In CBC-HMAC, the nonce MUST be a zero-length string; a nonce is not
	needed and is not used (see Section 4 for further background). CBC-		needed and is not used (see Section 4 for further background).
	HMAC also has an additional parameter MIN_LEN_A, which is a
	nonnegative integer that indicates the smallest value of A that will
	be used with the particular key K. The value of MIN_LEN_A SHOULD be
	provided when a key is initialized, and the value MUST be unchanging
	across the life of the key. If the value of MIN_LEN_A is not
	provided, then it MUST be assumed to be zero.
	The CBC-HMAC encryption process is as follows, or uses an equivalent		The CBC-HMAC encryption process is as follows, or uses an equivalent
	set of steps:		set of steps:
	1. The secondary keys MAC_KEY and ENC_KEY are generated from the		1. The secondary keys MAC_KEY and ENC_KEY are generated from the
	input key K as follows. Each of these two keys is an octet		input key K as follows. Each of these two keys is an octet
	string.		string.
	MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in		MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in
	order.		order.
	skipping to change at page 5, line 17 ¶		skipping to change at page 6, line 13 ¶
	and ENC_KEY MUST NOT overlap.		and ENC_KEY MUST NOT overlap.
	2. An Initialization Vector (IV) is generated randomly or		2. An Initialization Vector (IV) is generated randomly or
	pseudorandomly, as described in Section 3, for use in the cipher.		pseudorandomly, as described in Section 3, for use in the cipher.
	3. Prior to CBC encryption, the plaintext P is padded by appending a		3. Prior to CBC encryption, the plaintext P is padded by appending a
	padding string PS to that data, to ensure that len(P || PS) is a		padding string PS to that data, to ensure that len(P || PS) is a
	multiple of 128, as is needed for the CBC operation. The value		multiple of 128, as is needed for the CBC operation. The value
	of PS is as follows:		of PS is as follows:
	PS = 01, if len(P) mod 128 = 120,		PS = 01 if len(P) mod 128 = 120,
	PS = 0202, if len(P) mod 128 = 112,		PS = 0202 if len(P) mod 128 = 112,
	PS = 030303, if len(P) mod 128 = 104,		PS = 030303 if len(P) mod 128 = 104,
	...		PS = 04040404 if len(P) mod 128 = 96,
	PS = 0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F, if len(P) mod 128 = 0.		PS = 0505050505 if len(P) mod 128 = 88,
			PS = 060606060606 if len(P) mod 128 = 80,
			PS = 07070707070707 if len(P) mod 128 = 72,
			PS = 0808080808080808 if len(P) mod 128 = 64,
			PS = 090909090909090909 if len(P) mod 128 = 56,
			PS = 0A0A0A0A0A0A0A0A0A0A if len(P) mod 128 = 48,
			PS = 0B0B0B0B0B0B0B0B0B0B0B if len(P) mod 128 = 40,
			PS = 0C0C0C0C0C0C0C0C0C0C0C0C if len(P) mod 128 = 32,
			PS = 0D0D0D0D0D0D0D0D0D0D0D0D0D if len(P) mod 128 = 24,
			PS = 0E0E0E0E0E0E0E0E0E0E0E0E0E0E if len(P) mod 128 = 16,
			PS = 0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F if len(P) mod 128 = 8,
			PS = 10101010101010101010101010101010 if len(P) mod 128 = 0.
	Note that padding MUST be added to the plaintext; if the number		Note that padding MUST be added to the plaintext; if the number
	of bits in P is a multiple of 128, then 128 bits of padding will		of bits in P is a multiple of 128, then 128 bits of padding will
	be added.		be added.
	4. The plaintext and appended padding P || PS is CBC encrypted using		4. The plaintext and appended padding P || PS is CBC encrypted using
	ENC_KEY as the key, and the IV generated in the previous step.		ENC_KEY as the key, and the IV generated in the previous step.
	We denote the ciphertext output from this step as S, and it MUST		We denote the ciphertext output from this step as S, and it MUST
	include the IV as its prefix.		include the IV as its prefix.
	5. The octet string AL is computed as follows. If len(A) =		5. The octet string AL is equal to the number of bits in A expressed
	MIN_LEN_A, then AL is the zero-length string. Otherwise, it is		as a 64-bit unsigned integer in network byte order.
	equal to the number of bits in A expressed as a 64-bit unsigned
	integer in network byte order.
	6. A message authentication tag T is computed by applying HMAC		6. A message authentication tag T is computed by applying HMAC
	[RFC2104] to the following data, in order:		[RFC2104] to the following data, in order:
	the associated data A,		the associated data A,
	the ciphertext S computed in the previous step, and		the ciphertext S computed in the previous step, and
	the octet string AL defined above.		the octet string AL defined above.
	skipping to change at page 6, line 36 ¶		skipping to change at page 7, line 40 ¶
	1. The secondary keys MAC_KEY and ENC_KEY are generated from the		1. The secondary keys MAC_KEY and ENC_KEY are generated from the
	input key K as in Step 1 of Section 2.1.		input key K as in Step 1 of Section 2.1.
	2. The final T_LEN octets are stripped from C. Here T_LEN denotes		2. The final T_LEN octets are stripped from C. Here T_LEN denotes
	the number of octets in the MAC, which is a fixed parameter of		the number of octets in the MAC, which is a fixed parameter of
	the AEAD algorithm. We denote the initial octets of C as S, and		the AEAD algorithm. We denote the initial octets of C as S, and
	denote the final T_LEN octets as T.		denote the final T_LEN octets as T.
	3. The integrity and authenticity of A and C are checked by		3. The integrity and authenticity of A and C are checked by
	computing HMAC with the inputs as in Step 5 of the Section 2.1.		computing HMAC with the inputs as in Step 6 of Section 2.1. The
	The value T, from the previous step, is compared to the HMAC		value T, from the previous step, is compared to the HMAC output.
	output. If those values are identical, then A and C are		If those values are identical, then A and C are considered valid,
	considered valid, and processing is continued. Otherwise, all of		and processing is continued. Otherwise, all of the data used in
	the data used in the MAC validation are discarded, and the AEAD		the MAC validation are discarded, and the AEAD decryption
	decryption operation returns an indication that it failed, and		operation returns an indication that it failed, and the operation
	the operation halts.		halts.
	4. The value S is decrypted, using the initial 16 octets of the		4. The value S is decrypted, using the initial 16 octets of the
	ciphertext as the IV. The value ENC_KEY is used as the		ciphertext as the IV. The value ENC_KEY is used as the
	decryption key.		decryption key.
	5. The padding string is removed. Note that the length of PS can be		5. The padding string is removed. Note that the length of PS can be
	inferred from the value of the final octet of P || PS, if that		inferred from the value of the final octet of P || PS, if that
	value is between 00 and 0F (hexadecimal). If the final octet has		value is between 00 and 0F (hexadecimal). If the final octet has
	a value outside that range, then all of the data used in the		a value outside that range, then all of the data used in the
	processing of the message is zeroized and discarded, and the AEAD		processing of the message is zeroized and discarded, and the AEAD
	skipping to change at page 7, line 33 ¶		skipping to change at page 8, line 39 ¶
	This algorithm is randomized and stateless. It is based on the CBC-		This algorithm is randomized and stateless. It is based on the CBC-
	HMAC algorithm detailed above. It uses the HMAC message		HMAC algorithm detailed above. It uses the HMAC message
	authentication code [RFC2104] with the SHA-256 hash function		authentication code [RFC2104] with the SHA-256 hash function
	[FIPS186-2] to provide message authentication, with the HMAC output		[FIPS186-2] to provide message authentication, with the HMAC output
	truncated to 128 bits, corresponding to the HMAC-SHA-256-128		truncated to 128 bits, corresponding to the HMAC-SHA-256-128
	algorithm defined in [RFC4868]. For encryption, it uses AES in the		algorithm defined in [RFC4868]. For encryption, it uses AES in the
	cipher block chaining (CBC) mode of operation as defined in Section		cipher block chaining (CBC) mode of operation as defined in Section
	6.2 of [SP800-38], with the padding method used by PEM, PKCS, and		6.2 of [SP800-38], with the padding method used by PEM, PKCS, and
	TLS.		TLS.
	The input key K is 48 octets long.		The input key K is 32 octets long.
	The AES CBC IV is 16 octets long. ENC_KEY_LEN is 16 octets.		The AES CBC IV is 16 octets long. ENC_KEY_LEN is 16 octets.
	The SHA-256 hash algorithm is used in HMAC. MAC_KEY_LEN is 32		The SHA-256 hash algorithm is used in HMAC. MAC_KEY_LEN is 16
	octets. The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by		octets. The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by
	stripping off the final 16 octets. Test cases for HMAC-SHA-256 are		stripping off the final 16 octets. Test cases for HMAC-SHA-256 are
	provided in [RFC4231].		provided in [RFC4231].
	The lengths of the inputs are restricted as follows:		The lengths of the inputs are restricted as follows:
	K_LEN is 48 octets,		K_LEN is 48 octets,
	P_MAX is 2^64 - 1 octets,		P_MAX is 2^64 - 1 octets,
	A_MAX is 2^64 - 1 octets,		A_MAX is 2^64 - 1 octets,
	N_MIN is zero octets,		N_MIN is zero octets,
	N_MAX is 2^64 octets, and		N_MAX is 2^64 octets, and
	C_MAX is 2^64 + 47 octets.		C_MAX is 2^64 + 47 octets.
	2.5. AEAD_AES_192_CBC_HMAC_SHA_384		2.5. AEAD_AES_192_CBC_HMAC_SHA_384
	AEAD_AES_192_CBC_HMAC_SHA_384 is based on		AEAD_AES_192_CBC_HMAC_SHA_384 is based on
	AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences:		AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences:
	AES-192 is used instead of AES-128.		AES-192 is used instead of AES-128.
	SHA-384 is used in HMAC instead of SHA-256.		SHA-384 is used in HMAC instead of SHA-256.
	ENC_KEY_LEN is 24 octets.		ENC_KEY_LEN is 24 octets.
	MAC_KEY_LEN is 48 octets.		MAC_KEY_LEN is 24 octets.
	The length of the input key K is 72 octets.		The length of the input key K is 48 octets.
	The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of		The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of
	16 octets.		16 octets.
	The input length restrictions are as for		The input length restrictions are as for
	AEAD_AES_CBC_128_HMAC_SHA_256.		AEAD_AES_CBC_128_HMAC_SHA_256.
	2.6. AEAD_AES_256_CBC_HMAC_SHA_512		2.6. AEAD_AES_256_CBC_HMAC_SHA_384
			AEAD_AES_256_CBC_HMAC_SHA_384 is based on
			AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences:
			AES-256 is used instead of AES-128.
			SHA-384 is used in HMAC instead of SHA-256.
			ENC_KEY_LEN is 32 octets.
			MAC_KEY_LEN is 24 octets.
			The length of the input key K is 56 octets.
			The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of
			16 octets.
			The input length restrictions are as for
			AEAD_AES_CBC_128_HMAC_SHA_256.
			2.7. AEAD_AES_256_CBC_HMAC_SHA_512
	AEAD_AES_256_CBC_HMAC_SHA_512 is based on		AEAD_AES_256_CBC_HMAC_SHA_512 is based on
	AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences:		AEAD_AES_128_CBC_HMAC_SHA_256, but with the following differences:
	AES-256 is used instead of AES-128.		AES-256 is used instead of AES-128.
	SHA-512 is used in HMAC instead of SHA-256.		SHA-512 is used in HMAC instead of SHA-256.
	ENC_KEY_LEN is 32 octets.		ENC_KEY_LEN is 32 octets.
	MAC_KEY_LEN is 64 octets.		MAC_KEY_LEN is 32 octets.
	The length of the input key K is 96 octets.		The length of the input key K is 64 octets.
	The HMAC-SHA-512 value is truncated to T_LEN=32 octets instead of		The HMAC-SHA-512 value is truncated to T_LEN=32 octets instead of
	16 octets.		16 octets.
	The input length restrictions are as for		The input length restrictions are as for
	AEAD_AES_CBC_128_HMAC_SHA_256.		AEAD_AES_CBC_128_HMAC_SHA_256.
	2.7. AEAD_AES_128_CBC_HMAC_SHA1		2.8. AEAD_AES_128_CBC_HMAC_SHA1
	AEAD_AES_128_CBC_HMAC_SHA1 is based on AEAD_AES_128_CBC_HMAC_SHA_256,		AEAD_AES_128_CBC_HMAC_SHA1 is based on AEAD_AES_128_CBC_HMAC_SHA_256,
	but with the following differences:		but with the following differences:
	HMAC-SHA1 is used instead of HMAC-SHA-256. Test cases for HMAC-		HMAC-SHA1 is used instead of HMAC-SHA-256. Test cases for HMAC-
	SHA1 are provided in [RFC2202].		SHA1 are provided in [RFC2202].
	MAC_KEY_LEN is 20 octets.		MAC_KEY_LEN is 20 octets.
	The length of the input key K is 36 octets.		The length of the input key K is 36 octets.
	The HMAC-SHA-1 value is truncated to T_LEN=12 octets instead of 16		The HMAC-SHA-1 value is truncated to T_LEN=12 octets instead of 16
	octets. (Note that this matches the truncation used in		octets. (Note that this matches the truncation used in
	[RFC2404].)		[RFC2404].)
	The input length restrictions are as for		The input length restrictions are as for
	AEAD_AES_CBC_128_HMAC_SHA_256.		AEAD_AES_CBC_128_HMAC_SHA_256.
	2.8. Summary		2.9. Summary
	The parameters of the CBC-HMAC algorithms are summarized in the		The parameters of the CBC-HMAC algorithms are summarized in the
	following table.		following table.
	+-------------------------------+-------------+-------------+-------+		+-------------------------------+-------------+-------------+-------+
	| algorithm | ENC_KEY_LEN | MAC_KEY_LEN | T_LEN |		| algorithm | ENC_KEY_LEN | MAC_KEY_LEN | T_LEN |
	+-------------------------------+-------------+-------------+-------+		+-------------------------------+-------------+-------------+-------+
	| AEAD_AES_128_CBC_HMAC_SHA_256 | 16 | 32 | 16 |		| AEAD_AES_128_CBC_HMAC_SHA_256 | 16 | 16 | 16 |
	| | | | |		| | | | |
	| AEAD_AES_192_CBC_HMAC_SHA_384 | 24 | 48 | 24 |		| AEAD_AES_192_CBC_HMAC_SHA_384 | 24 | 24 | 24 |
	| | | | |		| | | | |
	| AEAD_AES_256_CBC_HMAC_SHA_512 | 32 | 64 | 32 |		| AEAD_AES_256_CBC_HMAC_SHA_384 | 32 | 24 | 24 |
			| | | | |
			| AEAD_AES_256_CBC_HMAC_SHA_512 | 32 | 32 | 32 |
	| | | | |		| | | | |
	| AEAD_AES_128_CBC_HMAC_SHA1 | 16 | 20 | 12 |		| AEAD_AES_128_CBC_HMAC_SHA1 | 16 | 20 | 12 |
	+-------------------------------+-------------+-------------+-------+		+-------------------------------+-------------+-------------+-------+
	3. Randomness Requirements		3. Randomness Requirements
	Each IV MUST be unpredictable to the adversary. It MAY be chosen		Each IV MUST be unpredictable to the adversary. It MAY be chosen
	uniformly at random, in which case it SHOULD have min-entropy equal		uniformly at random, in which case it SHOULD have min-entropy within
	within one bit of ENC_KEY_LEN. Alternatively, it MAY be generated		one bit of len(IV). Alternatively, it MAY be generated
	pseudorandomly, using any method that provides the same level of		pseudorandomly, using any method that provides the same level of
	security as the block cipher in use. However, if a pseudorandom		security as the block cipher in use. However, if a pseudorandom
	method is used, that method MUST NOT make use of ENC_KEY or MAC_KEY.		method is used, that method MUST NOT make use of ENC_KEY or MAC_KEY.
	SP 800-90 describes suitable pseudorandom generators.		SP 800-90 describes suitable pseudorandom generators.
	4. Rationale		4. Rationale
	The CBC-HMAC AEAD algorithms defined in this note are intended to be		The CBC-HMAC AEAD algorithms defined in this note are intended to be
	useful in the following applications:		useful in the following applications:
	skipping to change at page 11, line 29 ¶		skipping to change at page 13, line 29 ¶
	providing CBC and HMAC through an AEAD interface.		providing CBC and HMAC through an AEAD interface.
	These algorithms are not intended to replace existing uses of AES-CBC		These algorithms are not intended to replace existing uses of AES-CBC
	and HMAC, except in those circumstances where the existing use is not		and HMAC, except in those circumstances where the existing use is not
	sufficiently secure or sufficiently general-purpose.		sufficiently secure or sufficiently general-purpose.
	The length of the associated data input A is included in the HMAC		The length of the associated data input A is included in the HMAC
	input to ensure that the encrypter and the decrypter have the same		input to ensure that the encrypter and the decrypter have the same
	understanding of that length. Because of this, an attacker cannot		understanding of that length. Because of this, an attacker cannot
	trick the receiver into interpreting the initial bytes of C as the		trick the receiver into interpreting the initial bytes of C as the
	final bytes of A, or vice-versa. The MIN_LEN_A parameter is included		final bytes of A, or vice-versa.
	so that it is possible to use CBC-HMAC in a way that corresponds to
	existing uses of CBC and HMAC. Some existing systems (such as ESP or
	IEEE 1619.1) make use of those algorithms, but do not include the
	length of the associated data in the HMAC input. These systems can
	be secure because the length of the associated data is fixed, or can
	be inferred by other means. The MIN_LEN_A parameter allows the AL
	field to be zero-length when both the encrypter and the decrypter
	know the length of the associated data field. This enables
	implementations of CBC-HMAC to be compatible with existing systems
	that do not include the length of A in the HMAC input.
	The padding method used in this note is based on that of Privacy		The padding method used in this note is based on that of Privacy
	Enhanced Mail (PEM) and the Public Key Cryptography Standards (PKCS),		Enhanced Mail (PEM) and the Public Key Cryptography Standards (PKCS),
	because it is implemented in many environments.		because it is implemented in many environments.
	The encrypt-then-MAC method is used because of its better security		The encrypt-then-MAC method is used because of its better security
	properties. It would be possible to define AEAD algorithms based on		properties. It would be possible to define AEAD algorithms based on
	the MAC-encode-encrypt (MEE) method that is used by the Transport		the MAC-encode-encrypt (MEE) method that is used by the Transport
	Layer Security (TLS) protocol [RFC5246]. That alternative would		Layer Security (TLS) protocol [RFC5246]. That alternative would
	provide more code-sharing opportunities for an implementation that is		provide more code-sharing opportunities for an implementation that is
	co-resident with a TLS implementation. It is possible (but tricky)		co-resident with a TLS implementation. It is possible (but tricky)
	to implement MEE in a way that provides good security, as was shown		to implement MEE in a way that provides good security, as was shown
	in [PRS11]. But its negatives outweigh its positives; its security		in [PRS11]. But its negatives outweigh its positives; its security
	is inadequate for some parameter choices, and it has proven to be		is inadequate for some parameter choices, and it has proven to be
	difficult to implement in a way that resists padding oracle and		difficult to implement in a way that resists padding oracle and
	related timing attacks [V02] [CHVV03] [M04] [DP10] [AP12]. For		related timing attacks [V02] [CHVV03] [M04] [DP10] [AP12]. For
	future uses of CBC and HMAC, it is better to use encrypt-then-MAC."		future uses of CBC and HMAC, it is better to use encrypt-then-MAC."
	5. Test Cases		This note uses HMAC-SHA1 because it is widely deployed and is
			adequately secure, and HMAC-SHA-2, because it is used in newer
	5.1. AEAD_AES_128_CBC_HMAC_SHA1		standards and is expected to become widely deployed. It has been
			recently announced that the SHA-3 standard will be based on KECCAK,
	P = 41206369706865722073797374656d206d757374206e6f742062652072657175		but this note does not incorporate that hash function. To do so
	6972656420746f206265207365637265742c20616e64206974206d7573742062		would be to speculate on the final form of the SHA-3 standard. In
	652061626c6520746f2066616c6c20696e746f207468652068616e6473206f66		addition, while the use of KECCAK as a hash function is
	2074686520656e656d7920776974686f757420696e636f6e76656e69656e6365		straightforward, there are multiple options for its use in
			authenticated encryption. The focus of this note is the definition
	K = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f		of AEAD algorithms based on currently used cryptographic mechanisms,
	20212223		so SHA-3 is out of scope.
	MAC_KEY = 000102030405060708090a0b0c0d0e0f10111213
	ENC_KEY = 1415161718191a1b1c1d1e1f20212223
	A = 546865207365636f6e64207072696e6369706c65206f66204175677573746520
	4b6572636b686f666673
	IV = 1af38c2dc2b96ffdd86694092341bc04
	C_0 = 1af38c2dc2b96ffdd86694092341bc04
	P_1 = 41206369706865722073797374656d20
	C_1 = c63aec9963f4ff33a85e564cd05f9240
	P_2 = 6d757374206e6f742062652072657175
	C_2 = 0a71fe98bcb339acc1d78c92b3aa6a32
	P_3 = 6972656420746f206265207365637265
	C_3 = 1460d2aecec43b784b3b08b830be5291
	P_4 = 742c20616e64206974206d7573742062
	C_4 = dc0400b8afc6cd1c8475764632a83605
	P_5 = 652061626c6520746f2066616c6c2069
	C_5 = 01e5319a128127ae4b0eaa9b2f97ea6d
	P_6 = 6e746f207468652068616e6473206f66
	C_6 = f02200d6f68c743b794ed5d6139e84c4
	P_7 = 2074686520656e656d7920776974686f
	C_7 = cb919ebb8d8256098b6385e41476c416
	P_8 = 757420696e636f6e76656e69656e6365
	C_8 = cfc85a46fac40ea450d2b4c0fd7e03dc
	P_9 = 10101010101010101010101010101010
	C_9 = d833c8c3d2135f0d109bd231808bb3fd
	S = 1af38c2dc2b96ffdd86694092341bc04c63aec9963f4ff33a85e564cd05f9240
	0a71fe98bcb339acc1d78c92b3aa6a321460d2aecec43b784b3b08b830be5291
	dc0400b8afc6cd1c8475764632a8360501e5319a128127ae4b0eaa9b2f97ea6d
	f02200d6f68c743b794ed5d6139e84c4cb919ebb8d8256098b6385e41476c416
	cfc85a46fac40ea450d2b4c0fd7e03dcd833c8c3d2135f0d109bd231808bb3fd
	T = 9aed4feb1e6d25070b9a6f07
	C = 1af38c2dc2b96ffdd86694092341bc04c63aec9963f4ff33a85e564cd05f92400
	a71fe98bcb339acc1d78c92b3aa6a321460d2aecec43b784b3b08b830be5291dc
	0400b8afc6cd1c8475764632a8360501e5319a128127ae4b0eaa9b2f97ea6df02
	200d6f68c743b794ed5d6139e84c4cb919ebb8d8256098b6385e41476c416cfc8
	5a46fac40ea450d2b4c0fd7e03dcd833c8c3d2135f0d109bd231808bb3fd9aed4
	feb1e6d25070b9a6f07
	5.2. AEAD_AES_128_CBC_HMAC_SHA256
	K = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
	20212223242526270001020304050607
	P = 41206369706865722073797374656d206d757374206e6f742062652072657175
	6972656420746f206265207365637265742c20616e64206974206d7573742062
	652061626c6520746f2066616c6c20696e746f207468652068616e6473206f66
	2074686520656e656d7920776974686f757420696e636f6e76656e69656e6365
	A = 546865207365636f6e64207072696e6369706c65206f66204175677573746520
	4b6572636b686f666673
	IV = 1af38c2dc2b96ffdd86694092341bc04
	S = 1af38c2dc2b96ffdd86694092341bc04bec9dc25654f7eee633a29d2a14becfe
	79d5b3bfd19b0676584990ee84bb4279197d7ebca389b7e5c101898eed58c34b
	df22b74683a82cf07ae4ddeb4bf5731fc00dd4a98195de6e2e36985161bbe5ec
	13067e3508162da908dede1808a97578dc896d221063c7425679fd6bcfb8ce90
	c197fd05447a2cf7f2fe02a03fdf29c675fa66ecb12e398b7f6fc3c9ae3d03ba
	T = e0f20e4a7d3fa9dd5aadcd3ad982f09e
	C = 1af38c2dc2b96ffdd86694092341bc04bec9dc25654f7eee633a29d2a14becfe
	79d5b3bfd19b0676584990ee84bb4279197d7ebca389b7e5c101898eed58c34b
	df22b74683a82cf07ae4ddeb4bf5731fc00dd4a98195de6e2e36985161bbe5ec
	13067e3508162da908dede1808a97578dc896d221063c7425679fd6bcfb8ce90
	c197fd05447a2cf7f2fe02a03fdf29c675fa66ecb12e398b7f6fc3c9ae3d03ba
	e0f20e4a7d3fa9dd5aadcd3ad982f09e
	5.3. AEAD_AES_192_CBC_HMAC_SHA384
	K = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
	2021222324252627000102030405060708090a0b0c0d0e0f1011121314151617
	18191a1b1c1d1e1f
	P = 41206369706865722073797374656d206d757374206e6f742062652072657175
	6972656420746f206265207365637265742c20616e64206974206d7573742062
	652061626c6520746f2066616c6c20696e746f207468652068616e6473206f66
	2074686520656e656d7920776974686f757420696e636f6e76656e69656e6365
	IV = 1af38c2dc2b96ffdd86694092341bc04
	A = 546865207365636f6e64207072696e6369706c65206f66204175677573746520
	4b6572636b686f666673
	PS = 10101010101010101010101010101010
	AL = 0000000000000150
	S = 1af38c2dc2b96ffdd86694092341bc04ac57bb8225686ff568320b98ad54fa10
	eea70c609d4d11d4c34435e386623d0240e9f6c0f78126678546ae2ba2d3017c
	4e0ef70d7c5ec2724fecf715518bc48e9048e446077db090e135f33710a2c40d
	e0ea744adeca3149a94f9be65fe3e2982ca63e89d026e39319322b417ff9ee5a
	b06b71ea5894d9f0ad5089402e174a90cf65bed15f8835d3134a6302ef6cfd4d
	T = 0b3948b860797cc2ba0f89d3e79d5465ed770cc8e5b8a430
	C = 1af38c2dc2b96ffdd86694092341bc04ac57bb8225686ff568320b98ad54fa10
	eea70c609d4d11d4c34435e386623d0240e9f6c0f78126678546ae2ba2d3017c
	4e0ef70d7c5ec2724fecf715518bc48e9048e446077db090e135f33710a2c40d
	e0ea744adeca3149a94f9be65fe3e2982ca63e89d026e39319322b417ff9ee5a
	b06b71ea5894d9f0ad5089402e174a90cf65bed15f8835d3134a6302ef6cfd4d
	0b3948b860797cc2ba0f89d3e79d5465ed770cc8e5b8a430
	5.4. AEAD_AES_256_CBC_HMAC_SHA512
	K = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
	2021222324252627000102030405060708090a0b0c0d0e0f1011121314151617
	18191a1b1c1d1e1f2021222324252627000102030405060708090a0b0c0d0e0f
	P = 41206369706865722073797374656d206d757374206e6f742062652072657175
	6972656420746f206265207365637265742c20616e64206974206d7573742062
	652061626c6520746f2066616c6c20696e746f207468652068616e6473206f66
	2074686520656e656d7920776974686f757420696e636f6e76656e69656e6365
	IV = 1af38c2dc2b96ffdd86694092341bc04
	A = 546865207365636f6e64207072696e6369706c65206f66204175677573746520
	4b6572636b686f666673
	PS = 10101010101010101010101010101010
	AL = 0000000000000150
	S = 1af38c2dc2b96ffdd86694092341bc04d39c2d2b1248eb14a7f8d1c1e8f3ff17
	309d44cb0cb0dfd38695bf29f37258f74fc9ef1d05b7c71cb3c6fb04bad09105
	bc605e8b9c737008a47453b9415cd7407e7314cc73f5ba432172b6da53c33553
	8ba9614d79f36e393c8178ba8fb2deec0eaa4cf1eda1cf279fabd9799af60542
	04c96e06eacedb231c76c33e38317882eeb55fd9e534c1e73343d8cf00ff283a
	T = 2cf60bc4a50b569f0ae708a7889761b3f867c37537a8bd74c162e9b8ee859b08		5. Test Cases
	C = 1af38c2dc2b96ffdd86694092341bc04d39c2d2b1248eb14a7f8d1c1e8f3ff17		A future version of this note will contain test cases for all of the
	309d44cb0cb0dfd38695bf29f37258f74fc9ef1d05b7c71cb3c6fb04bad09105		AEAD algorithms that it defines.
	bc605e8b9c737008a47453b9415cd7407e7314cc73f5ba432172b6da53c33553
	8ba9614d79f36e393c8178ba8fb2deec0eaa4cf1eda1cf279fabd9799af60542
	04c96e06eacedb231c76c33e38317882eeb55fd9e534c1e73343d8cf00ff283a
	2cf60bc4a50b569f0ae708a7889761b3f867c37537a8bd74c162e9b8ee859b08
	6. Security Considerations		6. Security Considerations
	An earlier version of this document benefitted from some review.		An earlier version of this document benefitted from some review.
	Comments on this version are requested and should be forwarded to the		Comments on this version are requested and should be forwarded to the
	IRTF Crypto Forum Research Group (CFRG).		IRTF Crypto Forum Research Group (CFRG).
	The algorithms defined in this document use the generic composition		The algorithms defined in this document use the generic composition
	of CBC encryption with HMAC authentication, with the encrypt-then-MAC		of CBC encryption with HMAC authentication, with the encrypt-then-MAC
	method defined in Section 4.3 of [BN00]. This method has sound and		method defined in Section 4.3 of [BN00]. This method has sound and
	well-understood security properties; for details, please see that		well-understood security properties; for details, please see that
	reference. Note that HMAC is a good pseudorandom function and is		reference. Note that HMAC is a good pseudorandom function and is
	"strongly unforgeable", and thus meets all of the security goals of		"strongly unforgeable", and thus meets all of the security goals of
	that reference.		that reference.
			During the decryption process, the inputs A and C are mapped into the
			input of the HMAC algorithm. It is essential for security that each
			possible input to the MAC algorithm corresponds unambiguously to
			exactly one pair (A, C) of possible inputs. The fact that this
			property holds can be verified as follows. The HMAC input is X = A
			|| C || len(A). Let (A,C) and (A',C') denote two distinct input
			pairs, in which either 1) A != A' and C = C', 2) C != C and A = A',
			or 3) both inequalities hold. We also let X' = A' || C' || len(A').
			In cases 1 and 2, X != X' follows immediately. In case 3, if len(A)
			!= len(A'), then X != X' directly. If len(A) = len(A'), then X != X
			follows from the fact that the initial len(A) bits of X and X' must
			be distinct.
	There are security benefits to providing both confidentiality and		There are security benefits to providing both confidentiality and
	authentication in a single atomic operation, as done in this note.		authentication in a single atomic operation, as done in this note.
	This tight binding prevents subtle attacks such as the padding oracle		This tight binding prevents subtle attacks such as the padding oracle
	attack.		attack.
	As with any block cipher mode of operation, the security of AES-CBC		As with any block cipher mode of operation, the security of AES-CBC
	degrades as the amount of data that is process increases. Each fixed		degrades as the amount of data that is process increases. Each fixed
	key value SHOULD NOT be used to protect more than 2^64 bytes of data.		key value SHOULD NOT be used to protect more than 2^64 bytes of data.
	This limit ensures that the AES-CBC algorithm will stay under the		This limit ensures that the AES-CBC algorithm will stay under the
	birthday bound, i.e. because of the limit, it is unlikely that there		birthday bound, i.e. because of the limit, it is unlikely that there
	will be two AES plaintext inputs that are equal. (If this event		will be two AES plaintext inputs that are equal. (If this event
	occurs, information about the colliding plaintexts is leaked, so it		occurs, information about the colliding plaintexts is leaked, so it
	is desirable to bound the amount of plaintext processed in order to		is desirable to bound the amount of plaintext processed in order to
	make it unlikely.)		make it unlikely.)
	7. Acknowledgements		7. Acknowledgements
	Thanks are due to Matt Miller and John Foley for their constructive		Thanks are due to Matt Miller and John Foley for their constructive
	feedback; special thanks to John for his generation of the test		feedback; special thanks to John for his generation of the test
	cases.		cases. Thanks also to Kelly Burgin and Michael Peck for their
			suggestions and help.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[FIPS186-2]		[FIPS186-2]
	"FIPS 180-2: Secure Hash Standard,", Federal Information		"FIPS 180-2: Secure Hash Standard,", Federal Information
	Processing Standard		Processing Standard
	(FIPS) http://www.itl.nist.gov/fipspubs/fip180-1.htm.		(FIPS) http://www.itl.nist.gov/fipspubs/fip180-1.htm.
	skipping to change at page 20, line 15 ¶		skipping to change at page 19, line 15 ¶
	[BN00] "Authenticated encryption: Relations among notions and		[BN00] "Authenticated encryption: Relations among notions and
	analysis of the generic composition paradigm", Proceedings		analysis of the generic composition paradigm", Proceedings
	of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531-		of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531-
	545 http://www-cse.ucsd.edu/users/mihir/papers/oem.html.		545 http://www-cse.ucsd.edu/users/mihir/papers/oem.html.
	[CHVV03] Vaudenay, S., Canvel, B., Hiltgen, A., and M. Vuagnoux,		[CHVV03] Vaudenay, S., Canvel, B., Hiltgen, A., and M. Vuagnoux,
	"Password Interception in a SSL/TLS Channel", CRYPT0		"Password Interception in a SSL/TLS Channel", CRYPT0
	2003 http://lasecwww.epfl.ch/pub/lasec/doc/CHVV03.ps,		2003 http://lasecwww.epfl.ch/pub/lasec/doc/CHVV03.ps,
	2003.		2003.
	[DP09] Paterson, K. and D. Degabriele, "On the (in)security of		[DP07] Paterson, K. and J. Degabriele, "Attacking the IPsec
	IPsec in MAC-then-encrypt configurations", IEEE Symposium		Standards in Encryption-only Configurations", IEEE
	on Privacy and		Symposium on Privacy and
	Security http://eprint.iacr.org/2007/125.pdf, 2009.		Security http://eprint.iacr.org/2007/125.pdf, 2007.
	[DP10] Paterson, K. and D. Degabriele, "On the (in)security of		[DP10] Paterson, K. and J. Degabriele, "On the (in)security of
	IPsec in MAC-then-encrypt configurations.", ACM Conference		IPsec in MAC-then-encrypt configurations.", ACM Conference
	on Computer and Communications Security (ACM CCS)		on Computer and Communications Security (ACM CCS)
	2010 http://www.isg.rhul.ac.uk/~kp/CCSIPsecfinal.pdf,		2010 http://www.isg.rhul.ac.uk/~kp/CCSIPsecfinal.pdf,
	2010.		2010.
	[M04] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:		[M04] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
	Problems and Countermeasures", Web		Problems and Countermeasures", Web
	Page http://www.openssl.org/~bodo/tls-cbc.txt, 2004.		Page http://www.openssl.org/~bodo/tls-cbc.txt, 2004.
	[PRS11] Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag Size		[PRS11] Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag Size
	Does Matter: Attacks and Proofs for the TLS Record		Does Matter: Attacks and Proofs for the TLS Record
	Protocol", IEEE Symposium on Security and Privacy		Protocol", IEEE Symposium on Security and Privacy
	2012 http://web.cecs.pdx.edu/~teshrim/tmAnotherLook.pdf,		2012 http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf,
	January 2012.		January 2012.
	[R02] "Authenticated encryption with Associated-Data",		[R02] "Authenticated encryption with Associated-Data",
	Proceedings of the 2002 ACM Conference on Computer and		Proceedings of the 2002 ACM Conference on Computer and
	Communication Security (CCS'02), pp. 98-107, ACM Press,		Communication Security (CCS'02), pp. 98-107, ACM Press,
	2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.pdf.		2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.pdf.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
End of changes. 36 change blocks.
	239 lines changed or deleted		161 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/