< draft-mcgrew-aead-aes-cbc-hmac-sha2-03.txt   draft-mcgrew-aead-aes-cbc-hmac-sha2-04.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: August 17, 2014 K. Paterson Expires: August 18, 2014 K. Paterson
Royal Holloway, University of Royal Holloway, University of
London London
February 13, 2014 February 14, 2014
Authenticated Encryption with AES-CBC and HMAC-SHA Authenticated Encryption with AES-CBC and HMAC-SHA
draft-mcgrew-aead-aes-cbc-hmac-sha2-03.txt draft-mcgrew-aead-aes-cbc-hmac-sha2-04.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 August 17, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 26 skipping to change at page 5, line 26
Section 2.7 define instances of CBC-HMAC that specify those details. Section 2.7 define instances of CBC-HMAC that specify those 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. The key MUST associated data are authenticated, but not encrypted. The key MUST
MUST be generated in a way that is uniformly random or pseudorandom; be generated in a way that is uniformly random or pseudorandom;
guidance on random sources is provided in [RFC4086]. guidance on random sources is provided in [RFC4086].
In CBC-HMAC, the nonce N 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
skipping to change at page 8, line 27 skipping to change at page 8, line 27
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; each invocation of the encrypt This algorithm is randomized; each invocation of the encrypt
operation makes use of a random value (the IV described in operation makes use of a random value (the IV described in
Appendix A. It is based on the CBC-HMAC algorithm detailed above, Appendix A). It is based on the CBC-HMAC algorithm detailed above,
and uses the HMAC message authentication code [RFC2104] with the SHA- and uses the HMAC message authentication code [RFC2104] with the SHA-
256 hash function [FIPS186-2] to provide message authentication, with 256 hash function [FIPS186-2] to provide message authentication, with
the HMAC output truncated to 128 bits, corresponding to the HMAC-SHA- the HMAC output truncated to 128 bits, corresponding to the HMAC-SHA-
256-128 algorithm defined in [RFC4868]. For encryption, it uses the 256-128 algorithm defined in [RFC4868]. For encryption, it uses the
Advanced Encryption Standard (AES) [FIPS197] block cipher defined in Advanced Encryption Standard (AES) [FIPS197] block cipher in CBC
CBC mode. mode.
The input key K is 48 octets long. The input key K is 32 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 32 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 and N_MAX are zero octets,
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
skipping to change at page 12, line 25 skipping to change at page 12, line 25
[RFC5116] for more background, [RFC5116] for more background,
new systems, such as JSON Cryptography and W3C Web Crypto, which new systems, such as JSON Cryptography and W3C Web Crypto, which
can omit unauthenticated symmetric encryption altogether by can omit unauthenticated symmetric encryption altogether by
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 algorithms in this note truncate the HMAC output to half of the
size of the output of the underlying hash function. This size is the
recommended minimum (see Section 5 of [RFC2104]), and this parameter
choice has withstood the test of time.
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. final bytes of A, or vice-versa.
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 very 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-SHA-2 because it is widely deployed, it is This note uses HMAC-SHA-2 because it is widely deployed, it is
mandated in newer standards, and because SHA1 is being deprecated. mandated in newer standards, and because SHA1 is being deprecated.
It has been recently announced that the SHA-3 standard will be based It has been recently announced that the SHA-3 standard will be based
on KECCAK, but this note does not incorporate that hash function. To on KECCAK, but this note does not incorporate that hash function. To
do so would be to speculate on the final form of the SHA-3 standard. do so 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
skipping to change at page 22, line 9 skipping to change at page 22, line 9
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, Kelly Thanks are due to Matt Miller for his constructive feedback, Kelly
Burgin, Michael Peck, and Mike Jones for their suggestions and help, Burgin, Michael Peck, and Mike Jones for their suggestions and help,
and Jim Schaad and Rob Napier for their excellent review and and Jim Schaad, Rob Napier, James Manger, and David Jacobson for
suggestions. 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 28, line 28 skipping to change at page 28, line 28
encryption operation the same as those defined in Section 2.1 (the encryption operation the same as those defined in Section 2.1 (the
secret key K, the plaintext P, the associated data A). The outputs secret key K, the plaintext P, the associated data A). The outputs
of the encryption operation are: of the encryption operation are:
the initialization vector IV as defined in Appendix A, the initialization vector IV as defined in Appendix A,
the ciphertext C, as defined in Appendix A, and the ciphertext C, as defined in Appendix A, and
the message authentication tag T, as defined in Section 2.1. the message authentication tag T, as defined in Section 2.1.
The inputs to the decryption operation are: The inputs to the decryption operation (in addition to K and A) are:
the initialization vector IV as defined in Appendix A, the initialization vector IV as defined in Appendix A,
the ciphertext C, as defined in Appendix A, and the ciphertext C as defined in Appendix A, excluding the initial
block C_0 (which is equal to the IV), and
the message authentication tag T, as defined in Section 2.1. the message authentication tag T, as defined in Section 2.1.
The output of the decryption operation is the same as that defined in The output of the decryption operation are the same as that defined
Section 2.2 (either a plaintext value P or a special symbol FAIL that in Section 2.2 (either a plaintext value P or a special symbol FAIL
indicates that the inputs are not authentic). that indicates that the inputs are not authentic).
All processing other than the encoding and decoding of IV, C, and T All processing other than the encoding and decoding of IV, C, and T
is done as defined above. In particular, the IV is an output of the is done as defined above. In particular, the IV is an output of the
encryption operation, rather than an input. encryption operation, rather than an input.
Authors' Addresses Authors' Addresses
David McGrew David McGrew
Cisco Systems Cisco Systems
13600 Dulles Technology Drive 13600 Dulles Technology Drive
 End of changes. 17 change blocks. 
20 lines changed or deleted 25 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/