One document matched: draft-mcgrew-aead-aes-cbc-hmac-sha1-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY rfc4106 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4106.xml">
<!ENTITY rfc4309 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4309.xml">
<!ENTITY rfc2104 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml">
<!ENTITY rfc2202 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2202.xml">
<!ENTITY rfc4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY rfc4107 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4107.xml">
<!ENTITY rfc4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY rfc5116 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5116.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" docName="draft-mcgrew-aead-aes-cbc-hmac-sha1-01.txt"
ipr="trust200902">
<front>
<title abbrev="AEAD-AES-CBC-HMAC-SHA1">
Authenticated Encryption with AES-CBC and HMAC-SHA1
(and other generic combinations of ciphers and MACs)
</title>
<author fullname="David A. McGrew" initials="D.A.M." surname="McGrew">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>510 McCarthy Blvd.</street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>US</country>
</postal>
<phone>(408) 525 8651</phone>
<email>mcgrew@cisco.com</email>
<uri>http://www.mindspring.com/~dmcgrew/dam.htm</uri>
</address>
</author>
<date month="March" year="2009" />
<area>General</area>
<keyword>Encryption, Authentication</keyword>
<abstract>
<t>
This document specifies algorithms for authenticated
encryption with additional authenticated data (AEAD) that are
based on the composition of the Advanced Encryption Standard
(AES) in the Cipher Block Chaining (CBC) mode of operation for
encryption, and the HMAC-SHA1 message authentication code
(MAC). It also separately defines a generic composition
method that can be used with other MACs and randomized ciphers
(that is, ciphers that use random initialization vectors).
</t>
<t>
These algorithms are randomized, and thus are suitable for
use with applications that cannot provide distinct nonces
to each invocation of the AEAD encrypt operation.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Authenticated encryption <xref target="BN00"/> is a form of
encryption that, in addition to providing confidentiality for
the plaintext that is encrypted, provides a way to check its
integrity and authenticity. Authenticated encryption with
Associated Data, or AEAD, adds the ability to check the
integrity and authenticity of some associated data (also called
"additional authenticated data") that is not encrypted. This
document defines two AEAD algorithms, using the interface defined
in <xref target="RFC5116"/>, based on AES and HMAC-SHA1,
with key sizes of 128 bits and 256 bits.
</t>
<section title="Conventions Used In This Document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
</section>
<section anchor="generic" title="A Generic Composition Method">
<t>
This section defines a particular "generic composition"
method, using the the encrypt-then-MAC method defined in
Section 4.3 of <xref target="AE"></xref>. The method
describes how to make a randomized AEAD algorithm out of a
randomized cipher, such as a block cipher mode of operation
that uses a random initialization vector, and a MAC.
</t>
<section title="Encryption">
<t> We briefly recall the interface defined in Section 2 of
<xref target="RFC5116"/>. The AEAD encryption algorithm takes
as input four octet strings: a secret key K, a plaintext P,
associated data A, and a nonce N. An authenticated
ciphertext value is provided as output. The data in the
plaintext are encrypted and authenticated, and the
associated data are authenticated, but not encrypted. The
AEAD encryption process is as follows, or uses an equivalent
set of steps:
<list style="numbers">
<t> 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 string.
<list style="letters">
<t>MAC_KEY consists of the first MAC_KEY_LEN octets of
K, in order.</t>
<t>ENC_KEY consists of the last ENC_KEY_LEN octets of
K, in order.</t>
</list>
Here we denote the number of octets in the MAC_KEY as
MAC_KEY_LEN, and the number of bits in ENC_KEY as
ENC_KEY_LEN.
</t>
<t> An Initialization Vector (IV) is generated uniformly
at random, for use in the cipher. (Note that this IV is
distinct from the nonce that may be provided as an input
to the authenticated encryption operation.)
</t>
<t>
The plaintext P is encrypted using the cipher with
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 include the IV as its prefix.
</t>
<t>A message authentication code (MAC) is computed by
applying the MAC to the following data, in order:
<list style="letters">
<t> the nonce N, </t>
<t> the associated data A, </t>
<t> the ciphertext S computed in the previous step </t>
<t> the number of bits in N expressed as a 64-bit
unsigned integer in network byte order, </t>
<t> and the number of bits in A expressed as a 64-bit
unsigned integer in network byte order.</t>
</list>
The string MAC_KEY is used as the MAC key. We denote
the output of the MAC computed in this step as T.
</t>
<t>The AEAD Ciphertext consists of the string S, with the
string T appended to it. This Ciphertext is returned as
the output of the AEAD encryption operation.
</t>
</list></t>
<t>
The encryption process can be illustrated as follows. Here
P, A, and C denote the AEAD plaintext, associated data, and
ciphertext, respectively.
<list>
<t>
S = ENC(ENC_KEY, P)
</t>
<t>
T = MAC(MAC_KEY, N || A || S || len(N) || len(A))
</t>
<t>
C = S || T
</t>
</list>
Here ENC(X,P) denotes the encryption of P using the cipher
with the key X; recall that the IV is included in its
output. The expression MAC(Y,M) denotes the application of
the MAC to the message M, using the key Y. The
concatenation of two octet strings A and B is denoted as A
|| B, and len(X) denotes the number of bits in the string X,
expressed as an unsigned integer in network byte order.
</t>
</section>
<section title="Decryption">
<t>
The authenticated decryption operation has four inputs: K, N,
and A, as defined above, and the Ciphertext C. It has only
a single output, either a plaintext value P or a special
symbol FAIL that indicates that the inputs are not
authentic. The authenticated decryption algorithm takes is
as follows, or uses an equivalent set of steps:
<list style="numbers">
<t> 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 string.
<list style="letters">
<t>MAC_KEY consists of the first MAC_KEY_LEN octets of
K, in order.</t>
<t>ENC_KEY consists of the last ENC_KEY_LEN octets of
K, in order.</t>
</list>
As above, we denote the number of octets in the
MAC_KEY as MAC_KEY_LEN, and the number of bits in ENC_KEY
as ENC_KEY_LEN.
</t>
<t>
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 AEAD algorithm. We denote
the initial octets of C as S, and denote the final
T_LEN octets as T.
</t>
<t> The integrity and authenticity of N, A, and C are
checked by computing MAC validation algorithm, using the
same inputs as in Step 5 of the encryption operation.
In the MAC-validation step, the message consists of N,
A, the number of bits in N expressed as a 64-bit
unsigned integer in network byte order, the number of
bits in A expressed as a 64-bit unsigned integer in
network byte order, as S, in that order. The value
MAC_KEY is used as the key. The value T, from the
previous step, is used as the correct MAC value for
validation purposes. If the MAC-validation operation
indicates that the MAC T is valid, then the processing
is continued. Otherwise, all of the data used in the MAC
validation are discard, and the AEAD decryption
operation returns an indication that it failed, and the
operation halts.</t>
<t> The value S is decrypted, using the first 128 bits of
the ciphertext as the IV. The value ENC_KEY is used
as the decryption key.</t>
<t> The plaintext value is returned..</t>
</list></t>
</section>
<section title="Length">
<t>The length of the ciphertext can be inferred from that of the
plaintext. The number L of octets in the ciphertext is given by
<list>
<t>L = 16 * ( floor(M / 16) + 2)</t>
</list> where M denotes the number of octets in the
plaintext, and the function floor() rounds its argument down
to the nearest integer. This fact is useful to applications
that need to reserve space for a ciphertext within a message
or data structure.</t>
</section>
</section>
<section anchor="aesHmac" title="AEAD_AES_CBC_128_HMAC_SHA1">
<t>This algorithm is randomized and stateless. It is based on
the "generic composition" of CBC encryption with HMAC
authentication, with the the encrypt-then-MAC method defined
in Section 4.3 of <xref target="AE"></xref>. It uses the HMAC
message authentication code <xref target="RFC2104"></xref>
with the SHA-1 hash function <xref target="SHA1"></xref> to
provide message authentication. Test cases for HMAC_SHA1 are
provided in <xref target="RFC2202"></xref>. For encryption, it
uses AES in the cipher block chaining (CBC) mode of operation
as defined in Section 6.2 of <xref target="MODES"></xref>,
with the padding method defined by Appendix A of the same
reference. </t>
<t>
The input key K is 36 octets long.
</t>
<section title="Encryption">
<t>
The AES CBC IV is 16 octets long. ENC_KEY_LEN is 16
octets.
</t>
<t>Prior to CBC encryption, the plaintext is padded by
appending a single '1' bit to that data and then appending
to the resulting string as few '0' bits as are necessary
to make the number of bits in the plaintext into a
multiple of 128. Note that padding MUST be added to the
data; if the number of bits in the payload data is a
multiple of 128, then 128 bits of padding will be
added.</t>
<t>The plaintext is then encrypted using AES-128 in CBC mode,
using ENC_KEY as the key and the random IV. The IV is
included in the ciphertext as its initial 16 octets. </t>
</section>
<section title="Message Authentication">
<t>
HMAC-SHA1 is used as the MAC. MAC_KEY_LEN is 20 octets.
The HMAC-SHA1 output is truncated to 16 octets, by
stripping off the final four octets.
</t>
</section>
<section title="Decryption">
<t>After CBC decryption, the padding is removed by
deleting the final '1' bit and all of the following '0'
bits. The remaining data forms the plaintext.</t>
<t>
The HMAC-SHA1 validation operation consists of computing
the HMAC-SHA1 value of the message, truncating it to 16
octets by discarding the final four octets, then
comparing that value with the MAC value. If values are
not equal, then the message is rejected. Otherwise, it
is accepted.
</t>
</section>
<section title="Length Restrictions">
<t>The lengths of the inputs are restricted as follows:</t>
<t><list>
<t>K_LEN is 36 octets,</t>
<t>P_MAX is 2^64 - 1 octets,</t>
<t>A_MAX is 2^64 - 1 octets,</t>
<t>N_MIN is zero octets,</t>
<t> N_MAX is 2^64 octets, and</t>
<t>C_MAX is 2^64 + 47 octets.</t>
</list></t>
</section>
<section title="Test Cases">
<t>A future version of this document will include test cases.</t>
</section>
</section>
<section anchor="aesHmac2" title="AEAD_AES_256_HMAC_SHA_256">
<t>
AEAD_AES_CBC_256_HMAC_SHA_256 is like AEAD_AES_CBC_128_HMAC_SHA1,
with the following differences:
<list>
<t>
AES-256 is used instead of AES-128.
</t>
<t>
HMAC-SHA-256 is used instead of HMAC-SHA1.
</t>
<t>
ENC_KEY_LEN and MAC_KEY_LEN are each
32 octets.
</t>
<t>
The input key length is 64 octets.
</t>
</list>
</t>
</section>
<section anchor="Rationale" title="Rationale">
<t>
The AEAD_AES_CBC_128_HMAC_SHA1 and AEAD_AES_CBC_256_HMAC_SHA_256
algorithms are intended for use in applications that make use of the
AEAD interface. It is expected to be useful with cryptomodules that
contain efficient implementations of AES-CBC and HMAC-SHA1, but which
do not implement any other AEAD algorithms. They are not intended to
replace existing uses of AES-CBC and HMAC-SHA1, except in those
circumstances where the existing use is not sufficiently secure or
sufficiently general-purpose.
</t>
<t>
One advantage of these algorithms is that they are suitable for use
in applications that cannot provide distinct nonces to each
invocation of the AEAD encryption operation. In short, they can be
used with zero-length nonces. However, the algorithms can accept
nonces; this ensures that they can be used with applications that
are designed to work primarily with algorithms that expect nonces.
The nonce data is authenticated.
</t>
</section>
<section title="Security Considerations">
<t>
This initial version of this document has not been reviewed; regarding
security, it should be considered guilty until proven innocent.
Review has been requested from the IRTF Crypto Forum Research Group
(CFRG).
</t>
<t>
The algorithms defined in this document use the "generic composition"
of CBC encryption with HMAC authentication, with the encrypt-then-MAC
method defined in Section 4.3 of <xref target="AE"></xref>. This
method has sound and well-understood security properties; for details,
please see that reference.
</t>
<t>
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
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
"birthday bound", i.e., that it is unlikely that there will be two AES
plaintext inputs that are equal. (If this event occurs, information
about the colliding plaintexts is leaked, so it is desirable to bound
the amount of plaintext processed in order to make it unlikely.)
</t>
<t>
The nonce data is authenticated, as is expected in <xref target="RFC5116"/>.
</t>
</section>
<!--
<section title="Discussion">
<t>
</t>
</section>
-->
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2202;
&rfc5116;
<!--
<reference anchor="M07">
<front>
<title>An Interface and Registry for Authenticated
Encryption with Associated Data
</title>
<author initials="D.A." surname="McGrew" fullname="David A. McGrew">
<organization/>
</author>
<date month="November" year="2007"/>
</front>
<seriesInfo name="Internet Draft (approved for RFC)"
value="draft-mcgrew-auth-enc-05.txt" />
</reference>
-->
<!--
<reference anchor="GCM">
<front>
<title>The Galois/Counter Mode of Operation (GCM)</title>
<author fullname="David A. McGrew" initials="D.A." surname="McGrew">
<organization></organization>
</author>
<author fullname="John Viega" initials="J." surname="Viega">
<organization></organization>
</author>
<date month="January" year="2004" />
</front>
<seriesInfo name="Submission to NIST"
value="http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/gcm-spec.pdf" />
</reference>
<reference anchor="CCM">
<front>
<title>NIST Special Publication 800-38C: The CCM Mode for
Authentication and Confidentiality</title>
<author fullname="M. Dworkin">
<organization></organization>
</author>
</front>
<seriesInfo name="U.S. National Institute of Standards and Technology"
value="http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf" />
</reference>
-->
<reference anchor="MODES">
<front>
<title>NIST Special Publication 800-38: Recommendation for
Block Cipher Modes of Operation
</title>
<author fullname="Morris Dworkin" initials="M." surname="Dworkin">
<organization />
</author>
</front>
<seriesInfo name="U.S. National Institue of Standards and Technology"
value="http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf" />
</reference>
&rfc2104;
<reference anchor="SHA1">
<front>
<title>FIPS 180-1: Secure Hash Standard,</title>
<author fullname="U.S. National Institute of Standards and Technology (NIST)">
<organization />
</author>
</front>
<seriesInfo name="Federal Information Processing Standard (FIPS)"
value="http://www.itl.nist.gov/fipspubs/fip180-1.htm" />
</reference>
</references>
<references title="Informative References">
<reference anchor="BN00">
<front>
<title>Authenticated encryption: Relations among notions and
analysis of the generic composition paradigm</title>
<author fullname="Mihir Bellare and Chanathip Namprempre">
<organization />
</author>
</front>
<seriesInfo name="Proceedings of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531-545"
value="http://www-cse.ucsd.edu/users/mihir/papers/oem.html" />
</reference>
<reference anchor="AE">
<front>
<title>Authenticated encryption: Relations among notions and
analysis of the generic composition paradigm</title>
<author fullname="Mihir Bellare and Chanathip Namprempre">
<organization />
</author>
</front>
<seriesInfo name="Proceedings of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531-545"
value="http://www" />
</reference>
<!--
<reference anchor="BOYD">
<front>
<title>
Protocols for Authentication and Key Establishment
</title>
<author fullname="Colin Boyd" initials="C." surname="Boyd">
<organization />
</author>
<author fullname="Anish Mathuria" initials="A." surname="Mathuria">
<organization />
</author>
</front>
<seriesInfo
name="Springer, 2003"
value="" />
</reference>
<reference anchor="EEM04">
<front>
<title>Breaking and provably repairing the SSH authenticated
encryption scheme: A case study of the Encode-then-Encrypt-and-MAC
paradigm</title>
<author fullname="Mihir Bellare, Tadayoshi Kohno, and Chanathip Namprempre">
<organization />
</author>
</front>
<seriesInfo name="ACM Transactions on Information and System Security,"
value="http://www-cse.ucsd.edu/users/tkohno/papers/TISSEC04/" />
</reference>
<reference anchor="GR05">
<front>
<title>
When Virtual is Harder than Real: Security Challenges in
Virtual Machine Based Computing Environments
</title>
<author fullname=" Tal Garfinkel" initials="T." surname="Garfinkel">
<organization />
</author>
<author fullname="Mendel Rosenblum" initials="M." surname="Rosenblum" >
<organization />
</author>
</front>
<seriesInfo
name="Proceedings of the 10th Workshop on Hot Topcis in Operating Sytems"
value="http://www.stanford.edu/~talg/papers/HOTOS05/virtual-harder-hotos05.pdf"
/>
</reference>
&rfc4106;
&rfc4309;
&rfc4303;
<reference anchor="MV04">
<front>
<title>The Security and Performance of the Galois/Counter
Mode (GCM)</title>
<author initials="D.A." surname="McGrew" fullname="David A. McGrew">
<organization/>
</author>
<author initials="J." surname="Viega" fullname="John Viega">
<organization/>
</author>
<date month="December" year="2004"/>
</front>
<seriesInfo name="Proceedings of INDOCRYPT '04," value="http://eprint.iacr.org/2004/193"/>
</reference>
<reference anchor="J02">
<front>
<title>On the Security of CTR + CBC-MAC</title>
<author initials="J." surname="Jonsson" fullname="Jakob Jonsson">
<organization/>
</author>
<date year="2002"/>
</front>
<seriesInfo name="Proceedings of the 9th Annual Workshop on Selected Areas on Cryptography,"
value="http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ccm/ccm-ad1.pdf"/>
</reference>
<reference anchor="CMAC">
<front>
<title>NIST Special Publication 800-38B</title>
<author fullname="M. Dworkin, U.S. National Institute of Standards and Technology (NIST))">
<organization />
</author>
</front>
<seriesInfo name=""
value="http://csrc.nist.gov/CryptoToolkit/modes/800-38_Series_Publications/SP800-38B.pdf" />
</reference>
&rfc2434;
&rfc4086;
&rfc4107;
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:38:31 |