< draft-mcgrew-aead-aes-cbc-hmac-sha2-02.txt   draft-mcgrew-aead-aes-cbc-hmac-sha2-03.txt >
Network Working Group D. McGrew Network Working Group D. McGrew
Internet-Draft J. Foley Internet-Draft J. Foley
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: January 16, 2014 K. Paterson Expires: August 17, 2014 K. Paterson
Royal Holloway, University of Royal Holloway, University of
London London
July 15, 2013 February 13, 2014
Authenticated Encryption with AES-CBC and HMAC-SHA Authenticated Encryption with AES-CBC and HMAC-SHA
draft-mcgrew-aead-aes-cbc-hmac-sha2-02.txt draft-mcgrew-aead-aes-cbc-hmac-sha2-03.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 41 skipping to change at page 1, line 41
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 January 16, 2014. This Internet-Draft will expire on August 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions Used In This Document . . . . . . . . . . . . 4 1.2. Conventions Used In This Document . . . . . . . . . . . . 4
2. CBC-HMAC algorithms . . . . . . . . . . . . . . . . . . . . . 5 2. CBC-HMAC algorithms . . . . . . . . . . . . . . . . . . . . . 5
2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Length . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Length . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. AEAD_AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . 8 2.4. AEAD_AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . 8
2.5. AEAD_AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 9 2.5. AEAD_AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 9
2.6. AEAD_AES_256_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 9 2.6. AEAD_AES_256_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 9
2.7. AEAD_AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . 10 2.7. AEAD_AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . 10
2.8. AEAD_AES_128_CBC_HMAC_SHA1 . . . . . . . . . . . . . . . . 10 2.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Randomness Requirements . . . . . . . . . . . . . . . . . . . 11
3. Randomness Requirements . . . . . . . . . . . . . . . . . . . 12 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. AEAD_AES_128_CBC_HMAC_SHA256 . . . . . . . . . . . . . . . 14
5.1. AEAD_AES_128_CBC_HMAC_SHA256 . . . . . . . . . . . . . . . 15 5.2. AEAD_AES_192_CBC_HMAC_SHA384 . . . . . . . . . . . . . . . 15
5.2. AEAD_AES_192_CBC_HMAC_SHA384 . . . . . . . . . . . . . . . 16
5.3. AEAD_AES_256_CBC_HMAC_SHA384 . . . . . . . . . . . . . . . 17 5.3. AEAD_AES_256_CBC_HMAC_SHA384 . . . . . . . . . . . . . . . 17
5.4. AEAD_AES_256_CBC_HMAC_SHA512 . . . . . . . . . . . . . . . 19 5.4. AEAD_AES_256_CBC_HMAC_SHA512 . . . . . . . . . . . . . . . 18
5.5. AEAD_AES_128_CBC_HMAC_SHA1 . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 24 Appendix A. CBC Encryption and Decryption . . . . . . . . . . . . 26
Appendix A. CBC Encryption and Decryption . . . . . . . . . . . . 27
Appendix B. Alternative Interface for Legacy Encoding . . . . . . 28 Appendix B. Alternative Interface for Legacy Encoding . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
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
skipping to change at page 3, line 34 skipping to change at page 3, line 34
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.
Comments on this version are requested and should be forwarded to the
IRTF Crypto Forum Research Group (CFRG). An earlier version of this
document benefited from some review from that group.
1.1. History 1.1. History
This subsection describes the revision history of this Internet This subsection describes the revision history of this Internet
Draft. It should be removed by the RFC Editor before publication as Draft. It should be removed by the RFC Editor before publication as
an RFC. an RFC.
The changes of version 02 from version 01 are: The changes of version 02 from version 01 are:
Added test cases for each of the five operational modes. Added test cases for each of the five operational modes.
skipping to change at page 5, 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.7, or hash function to be used. Section 2.4, Section 2.5, and
and Section 2.8, define instances of CBC-HMAC that specify those Section 2.7 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. The key MUST
MUST be generated in a way that is uniformly random or pseudorandom;
guidance on random sources is provided in [RFC4086].
In CBC-HMAC, the nonce MUST be a zero-length string; a nonce is not In CBC-HMAC, the nonce N MUST be a zero-length string; a nonce is not
needed and is not used (see Section 4 for further background). needed and is not used (see Section 4 for further background).
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
skipping to change at page 6, line 5 skipping to change at page 6, line 5
order. order.
Here we denote the number of octets in the MAC_KEY as Here we denote the number of octets in the MAC_KEY as
MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN; MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN;
the values of these parameters are specified by the AEAD the values of these parameters are specified by the AEAD
algorithms (in Section 2.4 and Section 2.5). The number of algorithms (in Section 2.4 and Section 2.5). The number of
octets in the input key K is the sum of MAC_KEY_LEN and octets in the input key K is the sum of MAC_KEY_LEN and
ENC_KEY_LEN. When generating the secondary keys from K, MAC_KEY ENC_KEY_LEN. When generating the secondary keys from K, MAC_KEY
and ENC_KEY MUST NOT overlap. and ENC_KEY MUST NOT overlap.
2. An Initialization Vector (IV) is generated randomly or 2. Prior to CBC encryption, the plaintext P is padded by appending a
pseudorandomly, as described in Section 3, for use in the cipher.
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 = 04040404 if len(P) mod 128 = 96,
PS = 0505050505 if len(P) mod 128 = 88, PS = 0505050505 if len(P) mod 128 = 88,
PS = 060606060606 if len(P) mod 128 = 80, PS = 060606060606 if len(P) mod 128 = 80,
skipping to change at page 6, line 34 skipping to change at page 6, line 31
PS = 0C0C0C0C0C0C0C0C0C0C0C0C if len(P) mod 128 = 32, PS = 0C0C0C0C0C0C0C0C0C0C0C0C if len(P) mod 128 = 32,
PS = 0D0D0D0D0D0D0D0D0D0D0D0D0D if len(P) mod 128 = 24, PS = 0D0D0D0D0D0D0D0D0D0D0D0D0D if len(P) mod 128 = 24,
PS = 0E0E0E0E0E0E0E0E0E0E0E0E0E0E if len(P) mod 128 = 16, PS = 0E0E0E0E0E0E0E0E0E0E0E0E0E0E if len(P) mod 128 = 16,
PS = 0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F if len(P) mod 128 = 8, PS = 0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F if len(P) mod 128 = 8,
PS = 10101010101010101010101010101010 if len(P) mod 128 = 0. 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 3. 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, as described in Appendix A. We denote the
We denote the ciphertext output from this step as S, and it MUST ciphertext output from this step as S.
include the IV as its prefix.
5. The octet string AL is equal to the number of bits in A expressed 4. The octet string AL is equal to the number of bits in A expressed
as a 64-bit unsigned integer in network byte order. as a 64-bit unsigned integer in network byte order.
6. A message authentication tag T is computed by applying HMAC 5. 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.
The string MAC_KEY is used as the MAC key. We denote the output The string MAC_KEY is used as the MAC key. We denote the output
of the MAC computed in this step as T. of the MAC computed in this step as T.
7. The AEAD Ciphertext consists of the string S, with the string T 6. The AEAD Ciphertext consists of the string S, with the string T
appended to it. This Ciphertext is returned as the output of the appended to it. This Ciphertext is returned as the output of the
AEAD encryption operation. AEAD encryption operation.
The encryption process can be illustrated as follows. Here P, A, and The encryption process can be illustrated as follows. Here P, A, and
C denote the AEAD plaintext, associated data, and ciphertext, C denote the AEAD plaintext, associated data, and ciphertext,
respectively. respectively.
MAC_KEY = initial MAC_KEY_LEN bytes of K MAC_KEY = initial MAC_KEY_LEN bytes of K
ENC_KEY = final ENC_KEY_LEN bytes of K ENC_KEY = final ENC_KEY_LEN bytes of K
S = CBC-ENC(ENC_KEY, P || PS), S = CBC-ENC(ENC_KEY, P || PS),
T = MAC(MAC_KEY, A || S || AL), T = MAC(MAC_KEY, A || S || AL),
C = S || T. C = S || T.
2.2. Decryption 2.2. Decryption
The authenticated decryption operation has four inputs: K, N, and A, The authenticated decryption operation has four inputs: K, N, and A,
as defined above, and the Ciphertext C. It has only a single output, as defined above, and the Ciphertext C. As discussed above, N is an
either a plaintext value P or a special symbol FAIL that indicates empty string in AES-CBC and is not used below. It has only a single
that the inputs are not authentic. The authenticated decryption output, either a plaintext value P or a special symbol FAIL that
algorithm takes is as follows, or uses an equivalent set of steps: indicates that the inputs are not authentic. The authenticated
decryption algorithm takes is as follows, or uses an equivalent 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 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 6 of Section 2.1. The computing HMAC with the inputs as in Step 6 of Section 2.1. The
value T, from the previous step, is compared to the HMAC output. value T, from the previous step, is compared to the HMAC output,
using a comparison routine that takes constant time to execute.
If those values are identical, then A and C are considered valid, If those values are identical, then A and C are considered valid,
and processing is continued. Otherwise, all of the data used in and the processing continues. Otherwise, all of the data used in
the MAC validation are discarded, and the AEAD decryption the MAC validation are discarded, and the AEAD decryption
operation returns an indication that it failed, and the operation operation returns an indication that it failed, and the operation
halts. halts.
4. The value S is decrypted, using the initial 16 octets of the 4. The value S is CBC decrypted, as described in Appendix A, using
ciphertext as the IV. The value ENC_KEY is used as the the value ENC_KEY is 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 stripped from the resulting plaintext.
inferred from the value of the final octet of P || PS, if that Note that the length of PS can be inferred from the value of the
value is between 00 and 0F (hexadecimal). If the final octet has final octet of P || PS, if that value is between 01 and 10
a value outside that range, then all of the data used in the (hexadecimal). If the final octet has a value outside that
processing of the message is zeroized and discarded, and the AEAD range, then all of the data used in the processing of the message
decryption operation returns an indication that it failed, and is zeroized and discarded, and the AEAD decryption operation
the operation halts. returns an indication that it failed, and the operation halts.
6. The plaintext value is returned. 6. The plaintext value is returned.
2.3. Length 2.3. Length
The length of the ciphertext can be inferred from that of the The length of the ciphertext can be inferred from that of the
plaintext. The number L of octets in the ciphertext is given by plaintext. The number L of octets in the ciphertext is given by
L = 16 * ( floor(M / 16) + 2) L = 16 * ( floor(M / 16) + 2)
where M denotes the number of octets in the plaintext, and the where M denotes the number of octets in the plaintext, and the
function floor() rounds its argument down to the nearest integer. function floor() rounds its argument down to the nearest integer.
This fact is useful to applications that need to reserve space for a This fact is useful to applications that need to reserve space for a
ciphertext within a message or data structure. ciphertext within a message or data structure.
2.4. AEAD_AES_128_CBC_HMAC_SHA_256 2.4. AEAD_AES_128_CBC_HMAC_SHA_256
This algorithm is randomized and stateless. It is based on the CBC- This algorithm is randomized; each invocation of the encrypt
HMAC algorithm detailed above. It uses the HMAC message operation makes use of a random value (the IV described in
authentication code [RFC2104] with the SHA-256 hash function Appendix A. It is based on the CBC-HMAC algorithm detailed above,
[FIPS186-2] to provide message authentication, with the HMAC output and uses the HMAC message authentication code [RFC2104] with the SHA-
truncated to 128 bits, corresponding to the HMAC-SHA-256-128 256 hash function [FIPS186-2] to provide message authentication, with
algorithm defined in [RFC4868]. For encryption, it uses AES in the the HMAC output truncated to 128 bits, corresponding to the HMAC-SHA-
cipher block chaining (CBC) mode of operation as defined in Section 256-128 algorithm defined in [RFC4868]. For encryption, it uses the
6.2 of [SP800-38], with the padding method used by PEM, PKCS, and Advanced Encryption Standard (AES) [FIPS197] block cipher defined in
TLS. CBC mode.
The input key K is 32 octets long. The input key K is 48 octets long.
The AES CBC IV is 16 octets long. ENC_KEY_LEN is 16 octets. ENC_KEY_LEN is 16 octets.
The SHA-256 hash algorithm is used in HMAC. MAC_KEY_LEN is 16 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 and N_MAX are zero octets,
N_MIN is zero octets,
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.
skipping to change at page 10, line 29 skipping to change at page 10, line 26
MAC_KEY_LEN is 32 octets. MAC_KEY_LEN is 32 octets.
The length of the input key K is 64 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.8. AEAD_AES_128_CBC_HMAC_SHA1 2.8. Summary
AEAD_AES_128_CBC_HMAC_SHA1 is based on AEAD_AES_128_CBC_HMAC_SHA_256,
but with the following differences:
HMAC-SHA1 is used instead of HMAC-SHA-256. Test cases for HMAC-
SHA1 are provided in [RFC2202].
MAC_KEY_LEN is 20 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
octets. (Note that this matches the truncation used in
[RFC2404].)
The input length restrictions are as for
AEAD_AES_CBC_128_HMAC_SHA_256.
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 | 16 | 16 | | AEAD_AES_128_CBC_HMAC_SHA_256 | 16 | 16 | 16 |
| | | | | | | | | |
| AEAD_AES_192_CBC_HMAC_SHA_384 | 24 | 24 | 24 | | AEAD_AES_192_CBC_HMAC_SHA_384 | 24 | 24 | 24 |
| | | | | | | | | |
| AEAD_AES_256_CBC_HMAC_SHA_384 | 32 | 24 | 24 | | AEAD_AES_256_CBC_HMAC_SHA_384 | 32 | 24 | 24 |
| | | | | | | | | |
| AEAD_AES_256_CBC_HMAC_SHA_512 | 32 | 32 | 32 | | AEAD_AES_256_CBC_HMAC_SHA_512 | 32 | 32 | 32 |
| | | | |
| 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 within uniformly at random, in which case it SHOULD have min-entropy within
one bit of len(IV). 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.
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:
systems that have the CBC and HMAC algorithms available, but do systems that have the CBC and HMAC algorithms available, but do
not have dedicated AEAD algorithms such as GCM or CCM [RFC5116], not have dedicated AEAD algorithms such as GCM or CCM [RFC5116],
scenarios in which AEAD is useful, but it is undesirable to have scenarios in which AEAD is useful, but it is undesirable to have
the application maintain a deterministic nonce; see Section 4 of the application maintain a deterministic nonce; see Section 4 of
skipping to change at page 13, line 48 skipping to change at page 12, line 48
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."
This note uses HMAC-SHA1 because it is widely deployed and is This note uses HMAC-SHA-2 because it is widely deployed, it is
adequately secure, and HMAC-SHA-2, because it is used in newer mandated in newer standards, and because SHA1 is being deprecated.
standards and is expected to become widely deployed. It has been It has been recently announced that the SHA-3 standard will be based
recently announced that the SHA-3 standard will be based on KECCAK, on KECCAK, but this note does not incorporate that hash function. To
but this note does not incorporate that hash function. To do so do so would be to speculate on the final form of the SHA-3 standard.
would be to speculate on the final form of the SHA-3 standard. In
addition, while the use of KECCAK as a hash function is In addition, while the use of KECCAK as a hash function is
straightforward, there are multiple options for its use in straightforward, there are multiple options for its use in
authenticated encryption. The focus of this note is the definition authenticated encryption. The focus of this note is the definition
of AEAD algorithms based on currently used cryptographic mechanisms, of AEAD algorithms based on currently used cryptographic mechanisms,
so SHA-3 is out of scope. so SHA-3 is out of scope.
5. Test Cases 5. Test Cases
5.1. AEAD_AES_128_CBC_HMAC_SHA256 5.1. AEAD_AES_128_CBC_HMAC_SHA256
K = 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
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
ENC_KEY = 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ENC_KEY = 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69
6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66
skipping to change at page 16, line 18 skipping to change at page 15, line 18
fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36 fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36
09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8 09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8
6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b 6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b
38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f 38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f
bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5 bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5
4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db 4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db
65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4
5.2. AEAD_AES_192_CBC_HMAC_SHA384 5.2. AEAD_AES_192_CBC_HMAC_SHA384
K = 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
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f MAC_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 10 11 12 13 14 15 16 17
ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27
28 29 2a 2b 2c 2d 2e 2f 28 29 2a 2b 2c 2d 2e 2f
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
skipping to change at page 17, line 33 skipping to change at page 17, line 7
4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b 4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b
3b ed 78 7a 2f 0f fc bf 39 04 be 2a 64 1d 5c 21 3b ed 78 7a 2f 0f fc bf 39 04 be 2a 64 1d 5c 21
05 bf e5 91 ba e2 3b 1d 74 49 e5 32 ee f6 0a 9a 05 bf e5 91 ba e2 3b 1d 74 49 e5 32 ee f6 0a 9a
c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27 c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27
f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3 f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3
84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20
75 16 80 39 cc c7 33 d7 75 16 80 39 cc c7 33 d7
5.3. AEAD_AES_256_CBC_HMAC_SHA384 5.3. AEAD_AES_256_CBC_HMAC_SHA384
K = 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
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30 31 32 33 34 35 36 37
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f MAC_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 10 11 12 13 14 15 16 17
ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27
28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
skipping to change at page 19, line 7 skipping to change at page 18, line 20
8f 19 51 12 d6 ad 48 fa 3b 1e 89 aa 7f 20 d5 96 8f 19 51 12 d6 ad 48 fa 3b 1e 89 aa 7f 20 d5 96
68 2f 10 b3 64 8d 3b b0 c9 83 c3 18 5f 59 e3 6d 68 2f 10 b3 64 8d 3b b0 c9 83 c3 18 5f 59 e3 6d
28 f6 47 c1 c1 39 88 de 8e a0 d8 21 19 8c 15 09 28 f6 47 c1 c1 39 88 de 8e a0 d8 21 19 8c 15 09
77 e2 8c a7 68 08 0b c7 8c 35 fa ed 69 d8 c0 b7 77 e2 8c a7 68 08 0b c7 8c 35 fa ed 69 d8 c0 b7
d9 f5 06 23 21 98 a4 89 a1 a6 ae 03 a3 19 fb 30 d9 f5 06 23 21 98 a4 89 a1 a6 ae 03 a3 19 fb 30
dd 13 1d 05 ab 34 67 dd 05 6f 8e 88 2b ad 70 63 dd 13 1d 05 ab 34 67 dd 05 6f 8e 88 2b ad 70 63
7f 1e 9a 54 1d 9c 23 e7 7f 1e 9a 54 1d 9c 23 e7
5.4. AEAD_AES_256_CBC_HMAC_SHA512 5.4. AEAD_AES_256_CBC_HMAC_SHA512
K = 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
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f MAC_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 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
ENC_KEY = 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f ENC_KEY = 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
skipping to change at page 20, line 18 skipping to change at page 20, line 5
82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2 82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2
e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b
36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1 36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1
1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3 1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3
a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e
31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b 31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b
be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6 be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6
4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf
2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5 2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5
5.5. AEAD_AES_128_CBC_HMAC_SHA1
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13
ENC_KEY = 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69
6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66
20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f
75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63
69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20
4b 65 72 63 6b 68 6f 66 66 73
PS = 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
AL = 00 00 00 00 00 00 01 50
S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
c6 3a ec 99 63 f4 ff 33 a8 5e 56 4c d0 5f 92 40
0a 71 fe 98 bc b3 39 ac c1 d7 8c 92 b3 aa 6a 32
14 60 d2 ae ce c4 3b 78 4b 3b 08 b8 30 be 52 91
dc 04 00 b8 af c6 cd 1c 84 75 76 46 32 a8 36 05
01 e5 31 9a 12 81 27 ae 4b 0e aa 9b 2f 97 ea 6d
f0 22 00 d6 f6 8c 74 3b 79 4e d5 d6 13 9e 84 c4
cb 91 9e bb 8d 82 56 09 8b 63 85 e4 14 76 c4 16
cf c8 5a 46 fa c4 0e a4 50 d2 b4 c0 fd 7e 03 dc
d8 33 c8 c3 d2 13 5f 0d 10 9b d2 31 80 8b b3 fd
T = 4d 9d f6 8e 54 f7 d9 7e 91 4b 4a 9d
C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
c6 3a ec 99 63 f4 ff 33 a8 5e 56 4c d0 5f 92 40
0a 71 fe 98 bc b3 39 ac c1 d7 8c 92 b3 aa 6a 32
14 60 d2 ae ce c4 3b 78 4b 3b 08 b8 30 be 52 91
dc 04 00 b8 af c6 cd 1c 84 75 76 46 32 a8 36 05
01 e5 31 9a 12 81 27 ae 4b 0e aa 9b 2f 97 ea 6d
f0 22 00 d6 f6 8c 74 3b 79 4e d5 d6 13 9e 84 c4
cb 91 9e bb 8d 82 56 09 8b 63 85 e4 14 76 c4 16
cf c8 5a 46 fa c4 0e a4 50 d2 b4 c0 fd 7e 03 dc
d8 33 c8 c3 d2 13 5f 0d 10 9b d2 31 80 8b b3 fd
4d 9d f6 8e 54 f7 d9 7e 91 4b 4a 9d
6. Security Considerations 6. Security Considerations
Comments on this version are requested and should be forwarded to the
IRTF Crypto Forum Research Group (CFRG). An earlier version of this
document benefited from some review from that group.
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.
Implementations of the encryption and decryption algorithms should
avoid side channels that would leak information about the secret key.
To avoid timing channels, the processing time should be independent
of the secret key. The Encrypt-then-MAC construction used in this
note has some inherent strength against timing attacks because,
during the decryption operation, the authentication check is computed
before the plaintext padding is processed. However, the security of
the algorithm still relies on the absence of timing channels in both
CBC and HMAC. Additionally, comparison between the authentication
tag T and the HMAC output should be done using a constant-time
operation.
During the decryption process, the inputs A and C are mapped into the 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 input of the HMAC algorithm. It is essential for security that each
possible input to the MAC algorithm corresponds unambiguously to possible input to the MAC algorithm corresponds unambiguously to
exactly one pair (A, C) of possible inputs. The fact that this 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 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 || 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', 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'). 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) 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 != len(A'), then X != X' directly. If len(A) = len(A'), then X != X
skipping to change at page 23, line 7 skipping to change at page 22, line 7
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 for his constructive feedback, and Thanks are due to Matt Miller for his constructive feedback, Kelly
Kelly Burgin, Michael Peck, and Mike Jones for their suggestions and Burgin, Michael Peck, and Mike Jones for their suggestions and help,
help. and Jim Schaad and Rob Napier for their excellent review and
suggestions.
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 24, line 25 skipping to change at page 23, line 25
Information Processing Standard Information Processing Standard
(FIPS) http://www.itl.nist.gov/fipspubs/fip197.htm. (FIPS) http://www.itl.nist.gov/fipspubs/fip197.htm.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[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.
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
SHA-1", RFC 2202, September 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
RFC 4231, December 2005. RFC 4231, December 2005.
[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.
skipping to change at page 25, line 41 skipping to change at page 24, line 34
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://www.isg.rhul.ac.uk/~kp/mee-comp.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.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[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.
[SP800-38] [SP800-38]
Dworkin, M., "NIST Special Publication 800-38: Dworkin, M., "NIST Special Publication 800-38:
Recommendation for Block Cipher Modes of Operation", U.S. Recommendation for Block Cipher Modes of Operation", U.S.
National Institue of Standards and Technology http:// National Institue of Standards and Technology http://
csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf.
[V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - [V02] Vaudenay, S., "Security Flaws Induced by CBC Padding -
skipping to change at page 27, line 8 skipping to change at page 26, line 8
[YHR04] Yu, T., Hartman, S., and K. Raeburn, "The Perils of [YHR04] Yu, T., Hartman, S., and K. Raeburn, "The Perils of
Unauthenticated Encryption: Kerberos Version 4", Network Unauthenticated Encryption: Kerberos Version 4", Network
and Distributed Security Symposium (NDSS) and Distributed Security Symposium (NDSS)
2004 http://web.mit.edu/tlyu/papers/krb4peril-ndss04.pdf, 2004 http://web.mit.edu/tlyu/papers/krb4peril-ndss04.pdf,
2004. 2004.
Appendix A. CBC Encryption and Decryption Appendix A. CBC Encryption and Decryption
The Cipher Block Chaining (CBC) mode of operation is defined in The Cipher Block Chaining (CBC) mode of operation is defined in
[SP800-38]. This section recalls how that mode works, for the Section 6.2 of [SP800-38]. This section recalls how that mode works,
convenience of the reader. The following notation is used: for the convenience of the reader. The following notation is used:
K denotes the key of the underlying block cipher, K denotes the key of the underlying block cipher,
The function CIPHER(K, P) denotes the encryption of the block P The function CIPHER(K, P) denotes the encryption of the block P
with the block cipher, with the block cipher, where P contains exactly b bits,
The function CIPHER-INV(K, C) denotes the decryption of the block The function CIPHER-INV(K, C) denotes the decryption of the block
C with the block cipher; this is the inverse operation of C with the block cipher, where C contains exactly b bits; this is
CIPHER(), and CIPHER-INV(K, CIPHER(K, P)) = P for all P and all K. the inverse operation of CIPHER(), and CIPHER-INV(K, CIPHER(K, P))
= P for all P and all K,
P_1, P_2, ... , P_n denotes the sequence of plaintext blocks, P_1, P_2, ... , P_n denotes the sequence of plaintext blocks,
where each block contains exactly the number of bits that the where each block contains exactly b bits,
block cipher accepts as its plaintext input,
C_0, C_1, C_2, ... , C_n denotes the sequence of ciphertext C_0, C_1, C_2, ... , C_n denotes the sequence of ciphertext
blocks, where each block contains exactly the number of bits that blocks, where each block contains exactly b bits,
the block cipher accepts as its plaintext input,
P_i and C_i denote the ith blocks of the plaintext, and P_i and C_i denote the ith blocks of the plaintext, and
IV denotes the initialization vector, which contains exactly the IV denotes the initialization vector, which contains exactly b
number of bits that the block cipher accepts as its plaintext bits.
input.
The CBC encryption operation (denoted as CBC-ENC) takes as input a The CBC encryption operation (denoted as CBC-ENC) takes as input a
sequence of n plaintext blocks and produces a sequence of n + 1 sequence of n plaintext blocks and produces a sequence of n + 1
ciphertext blocks as follows: ciphertext blocks as follows:
IV = random IV = random
C_i = / IV if i=0, C_i = / IV if i=0,
\ CIPHER(K, P_i XOR C_{i-1}) if i=1, 2, ... , n. \ CIPHER(K, P_i XOR C_{i-1}) if i=1, 2, ... , n.
CBC-ENC(K, P_1 || P_2 || ... || P_n) returns the value C_0 || C_1 ||
C_2 || ... || C_n. Note that the returned value is one block longer
than the input value, and that C_0 = IV.
The IV MUST be generated using a uniformly random process, or a The IV MUST be generated using a uniformly random process, or a
pseudorandom process with a cryptographic strength equivalent to that pseudorandom process with a cryptographic strength equivalent to that
of the underlying block cipher. It MUST NOT be predictable to an of the underlying block cipher; see [RFC4086] for background on
attacker; in particular, it MUST NOT be set to the value of any random sources. It MUST NOT be predictable to an attacker; in
previous ciphertext blocks. particular, it MUST NOT be set to the value of any previous
ciphertext blocks.
The CBC decryption operation (denoted as CBC-DEC) takes as input a The CBC decryption operation (denoted as CBC-DEC) takes as input a
sequence of m ciphertext blocks and produces a sequence of m-1 sequence of m ciphertext blocks and produces a sequence of m-1
plaintext blocks as follows: plaintext blocks as follows:
P_i = CIPHER-INV(K, P_1 XOR IV) for i=1, 2, ... , n. P_i = CIPHER-INV(K, C_i) XOR C_{i-1} for i=1, 2, ... , n.
The initial block C_0 corresponds to the initialization vector.
Appendix B. Alternative Interface for Legacy Encoding Appendix B. Alternative Interface for Legacy Encoding
In some scenarios, cryptographic data such as the ciphertext, In some scenarios, cryptographic data such as the ciphertext,
initialization vector, and message authentication tag are encoded initialization vector, and message authentication tag are encoded
separately. To allow for the use of the algorithms defined in this separately. To allow for the use of the algorithms defined in this
document in such scenarios, this appendix describes an interface in document in such scenarios, this appendix describes an interface in
which those data elements are discrete. New implementations SHOULD which those data elements are discrete. New implementations SHOULD
NOT use this interface, because it is incompatible with other NOT use this interface, because it is incompatible with other
authenticated encryption methods and is more complex; however, it MAY authenticated encryption methods and is more complex; however, it MAY
 End of changes. 49 change blocks. 
177 lines changed or deleted 131 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/