One document matched: draft-mcgrew-aead-aes-cbc-hmac-sha2-03.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 rfc4231 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4231.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">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc4868 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4868.xml">
<!ENTITY rfc2404 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2404.xml">
<!ENTITY rfc6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.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-sha2-03.txt"
ipr="trust200902">
<front>
<title abbrev="AEAD-AES-CBC-HMAC-SHA">
Authenticated Encryption with AES-CBC and HMAC-SHA
<!-- (and other generic combinations of CBC and HMAC) -->
</title>
<author fullname="David McGrew" initials="D.A.M." surname="McGrew">
<organization>Cisco Systems</organization>
<address>
<postal>
<street> 13600 Dulles Technology Drive </street>
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<email>mcgrew@cisco.com</email>
<uri>http://www.mindspring.com/~dmcgrew/dam.htm</uri>
</address>
</author>
<author fullname="John Foley" initials="J.F." surname="Foley">
<organization>Cisco Systems</organization>
<address>
<postal>
<street> 7025-2 Kit Creek Road </street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>14987</code>
<country>US</country>
</postal>
<email>foleyj@cisco.com</email>
</address>
</author>
<author fullname="Kenny Paterson" initials="K." surname="Paterson">
<organization>Royal Holloway, University of London</organization>
<address>
<postal>
<street> TW20 0EX </street>
<city>Egham</city>
<region>Surrey</region>
<code>TW20 0EX</code>
<country>UK</country>
</postal>
<phone> +44 1784 414393</phone>
<email> Kenny.Paterson@rhul.ac.uk </email>
<uri>http://www.isg.rhul.ac.uk/~kp/</uri>
</address>
</author>
<date month="February" year="2014" />
<area>General</area>
<keyword>Encryption, Authentication</keyword>
<abstract>
<t>
This document specifies algorithms for authenticated
encryption with associated 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-SHA 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 are randomized encryption algorithms, 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 (AE) <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. This combination of features can, when properly
implemented, provide security against adversaries who have access to
full decryption capabilities for ciphertexts of their choice, and
access to full encryption capabilities for plaintexts of their
choice. The strong form of security provided by AE is known to be
robust against a large class of adversaries for general purpose
applications of AE, including applications such as securing network
communications over untrusted networks. The strong security properties
of AE stand in contrast to the known weaknesses of "encryption only"
forms of encryption, see <xref target="B96"/><xref target="YHR04"/>
<xref target="DP07"/> for examples.
</t>
<t>
Authenticated encryption with Associated Data, or AEAD <xref
target="R02"/>, adds the ability to check the integrity and
authenticity of some associated data (sometimes called
"additional authenticated data") for which confidentiality is
not required (or is not desirable). While many approaches to
building AEAD schemes are known, a particularly simple,
well-understood, and cryptographically strong method is to
employ an "Encrypt-then-MAC" construction. This document
defines new AEAD algorithms of this general type, using the
interface defined in <xref target="RFC5116"/>, based on the
Advanced Encryption Standard (AES) <xref target="FIPS197"/> in
the Cipher Block Chaining (CBC) mode of operation <xref
target="SP800-38"/> and HMAC using the Secure Hash Algorithm
(SHA) <xref target="FIPS186-2"/>, with security levels of 128,
192, and 256 bits.
</t>
<t>
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.
</t>
<section title="History">
<t>
This subsection describes the revision history of this Internet Draft.
It should be removed by the RFC Editor before publication as an RFC.
</t>
<t>
The changes of version 02 from version 01 are:
<list>
<t>
Added test cases for each of the five operational modes.
</t>
<t>
Added John as a coauthor.
</t>
<t>
Adds a legacy-style interface in Appendix B.
</t>
</list>
</t>
<t>
The changes of version 01 from version 00 are:
<list>
<t>
MIN_LEN_A and associated logic was eliminated.
</t>
<t>
Padding String (PS) typo corrected in Section 2.1.
</t>
<t>
Decryption Step 3 refers to the appropriate step in the
encryption process.
</t>
<t>
Random IV min-entropy clarified in Section 3.
</t>
<!--
<t>
Ciphertext Stealing ciphersuites have been added.
</t>
-->
<t>
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).
</t>
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<section title="Conventions Used In This Document">
<t>
We use the following notational conventions.
<list>
<t> CBC-ENC(X,P) denotes the CBC encryption of P using the cipher
with the key X </t>
<t>
MAC(Y, M) denotes the application of the Message
Authentication Code (MAC) to the message M, using the key Y
</t>
<t> The
concatenation of two octet strings A and B is denoted as A || B
</t>
<t> len(X) denotes the number of bits in the string X,
expressed as an unsigned integer in network byte order.
</t>
</list>
</t>
<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="CBC-HMAC algorithms">
<t>
This section defines CBC-HMAC, an algorithm based on the the
encrypt-then-MAC method defined in Section 4.3 of <xref
target="BN00"></xref>. That method constructs 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>
<t>
<xref target="Enc"/> and <xref target="Dec"/> define the
CBC-HMAC encryption and decryption algorithms, without
specifying the particular block cipher or hash function to
be used. <xref target="aesHmac"/>, <xref
target="aesHmac2"/>, and <xref target="aesHmac3"/>
<!-- , and <xref target="aesHmac4"/>, -->
define instances of CBC-HMAC that specify those details.
</t>
<section anchor="Enc" title="Encryption">
<t>
We briefly recall the encryption 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 key MUST MUST be generated in a
way that is uniformly random or pseudorandom; guidance on
random sources is provided in <xref target="RFC4086"/>.
</t>
<t>
In CBC-HMAC, the nonce N MUST be a zero-length string; a
nonce is not needed and is not used (see <xref
target="Rationale"/> for further background).
</t>
<t>
The CBC-HMAC 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="empty">
<t>MAC_KEY consists of the initial MAC_KEY_LEN octets of
K, in order.</t>
<t>ENC_KEY consists of the final 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 octets in ENC_KEY as
ENC_KEY_LEN; the values of these parameters are specified
by the AEAD algorithms (in <xref target="aesHmac"/> and
<xref target="aesHmac2"/>). The number of 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 and ENC_KEY
MUST NOT overlap.
</t>
<!--
<t> An Initialization Vector (IV) is generated randomly or
pseudorandomly, as described in <xref target="random"/>,
for use in the cipher.
</t>
-->
<t>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 multiple of 128, as is needed
for the CBC operation. The value of PS is as follows:
<figure>
<artwork>
PS = 01 if len(P) mod 128 = 120,
PS = 0202 if len(P) mod 128 = 112,
PS = 030303 if len(P) mod 128 = 104,
PS = 04040404 if len(P) mod 128 = 96,
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.
</artwork>
</figure>
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 be
added.</t>
<t>
The plaintext and appended padding P || PS is
CBC encrypted using ENC_KEY as the key, as described in
<xref target="cbc"/>. We denote the ciphertext output
from this step as S.
</t>
<t>
The octet string AL is equal to the number
of bits in A expressed as a 64-bit unsigned integer in network byte
order.
</t>
<t>A message authentication tag T is computed by applying
HMAC <xref target="RFC2104"/> to the following data, in
order:
<list style="empty">
<!-- <t> the nonce N, </t> -->
<t> the associated data A, </t>
<t> the ciphertext S computed in the previous step, and </t>
<t> the octet string AL defined above. </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>
MAC_KEY = initial MAC_KEY_LEN bytes of K
</t>
<t>
ENC_KEY = final ENC_KEY_LEN bytes of K
</t>
<t>
S = CBC-ENC(ENC_KEY, P || PS),
</t>
<t>
T = MAC(MAC_KEY, A || S || AL),
</t>
<t>
C = S || T.
</t>
</list>
</t>
</section>
<section anchor="Dec" title="Decryption">
<t>
The authenticated decryption operation has four inputs: K,
N, and A, as defined above, and the Ciphertext C. As
discussed above, N is an empty string in AES-CBC and is
not used below. 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 in Step 1 of <xref target="Enc"/>.
<!-- follows. Each of these two
keys is an octet string.
<list style="empty">
<t>MAC_KEY consists of the initial MAC_KEY_LEN octets of
K, in order.</t>
<t>ENC_KEY consists of the final 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 A and C are checked
by computing HMAC with the inputs as in Step 6 of
<xref target="Enc"/>.
<!-- The HMAC
message input consists of A, S, and AL, in that order. The
value MAC_KEY is used as the key.
-->
The 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, and the
processing continues. Otherwise, all of the data used
in the MAC validation are discarded, and the AEAD
decryption operation returns an indication that it
failed, and the operation halts.</t>
<t> The value S is CBC decrypted, as described in <xref
target="cbc"/>, using the value ENC_KEY is as the
decryption key.</t>
<t>
The padding string is stripped from the resulting
plaintext. Note that the length of PS can be inferred
from the value of the final octet of P || PS, if that
value is between 01 and 10 (hexadecimal). If the
final octet has a value outside that range, then all
of the data used in the processing of the message is
zeroized and discarded, and the AEAD decryption
operation returns an indication that it failed, and
the operation halts.
</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 anchor="aesHmac" title="AEAD_AES_128_CBC_HMAC_SHA_256">
<t>This algorithm is randomized; each invocation of the
encrypt operation makes use of a random value (the IV
described in <xref target="cbc"/>. It is based on the
CBC-HMAC algorithm detailed above, and uses the HMAC message
authentication code <xref target="RFC2104"></xref> with the
SHA-256 hash function <xref target="FIPS186-2"></xref> to
provide message authentication, with the HMAC output truncated
to 128 bits, corresponding to the HMAC-SHA-256-128 algorithm
defined in <xref target="RFC4868"/>. For encryption, it uses
the Advanced Encryption Standard (AES) <xref target="FIPS197"/>
block cipher defined in CBC mode.
</t>
<t>
The input key K is 48 octets long.
</t>
<t>
<!-- The AES CBC IV is 16 octets long.
-->
ENC_KEY_LEN is 16 octets.
</t>
<t>
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 stripping off the final 16 octets. Test cases for
HMAC-SHA-256 are provided in <xref target="RFC4231"/>.
<!-- question: does this match IPsec use? -->
</t>
<t>The lengths of the inputs are restricted as follows:</t>
<t><list>
<t>K_LEN is 48 octets,</t>
<t>P_MAX is 2^64 - 1 octets,</t>
<t>A_MAX is 2^64 - 1 octets,</t>
<t>N_MIN and N_MAX are zero octets,</t>
<t>C_MAX is 2^64 + 47 octets.</t>
</list></t>
</section>
<section anchor="aesHmac2" title="AEAD_AES_192_CBC_HMAC_SHA_384">
<t>
AEAD_AES_192_CBC_HMAC_SHA_384 is based on AEAD_AES_128_CBC_HMAC_SHA_256,
but with the following differences:
<list>
<t>
AES-192 is used instead of AES-128.
</t>
<t>
SHA-384 is used in HMAC instead of SHA-256.
</t>
<t>
ENC_KEY_LEN is 24 octets.
</t>
<t>
MAC_KEY_LEN is 24 octets.
</t>
<t>
The length of the input key K is 48 octets.
</t>
<t>
The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of 16 octets.
</t>
</list>
</t>
<t>
The input length restrictions are as for AEAD_AES_CBC_128_HMAC_SHA_256.
</t>
</section>
<section anchor="aesHmac5" title="AEAD_AES_256_CBC_HMAC_SHA_384">
<t>
AEAD_AES_256_CBC_HMAC_SHA_384 is based on AEAD_AES_128_CBC_HMAC_SHA_256,
but with the following differences:
<list>
<t>
AES-256 is used instead of AES-128.
</t>
<t>
SHA-384 is used in HMAC instead of SHA-256.
</t>
<t>
ENC_KEY_LEN is 32 octets.
</t>
<t>
MAC_KEY_LEN is 24 octets.
</t>
<t>
The length of the input key K is 56 octets.
</t>
<t>
The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of 16 octets.
</t>
</list>
</t>
<t>
The input length restrictions are as for AEAD_AES_CBC_128_HMAC_SHA_256.
</t>
</section>
<section anchor="aesHmac3" title="AEAD_AES_256_CBC_HMAC_SHA_512">
<t>
AEAD_AES_256_CBC_HMAC_SHA_512 is based on AEAD_AES_128_CBC_HMAC_SHA_256,
but with the following differences:
<list>
<t>
AES-256 is used instead of AES-128.
</t>
<t>
SHA-512 is used in HMAC instead of SHA-256.
</t>
<t>
ENC_KEY_LEN is 32 octets.
</t>
<t>
MAC_KEY_LEN is 32 octets.
</t>
<t>
The length of the input key K is 64 octets.
</t>
<t>
The HMAC-SHA-512 value is truncated to T_LEN=32 octets instead of 16 octets.
</t>
</list>
</t>
<t>
The input length restrictions are as for AEAD_AES_CBC_128_HMAC_SHA_256.
</t>
</section>
<!--
<section anchor="aesHmac4" title="AEAD_AES_128_CBC_HMAC_SHA1">
<t>
AEAD_AES_128_CBC_HMAC_SHA1 is based on AEAD_AES_128_CBC_HMAC_SHA_256,
but with the following differences:
<list>
<t>
HMAC-SHA1 is used instead of HMAC-SHA-256. Test cases for
HMAC-SHA1 are provided in <xref target="RFC2202"></xref>.
</t>
<t>
MAC_KEY_LEN is 20 octets.
</t>
<t>
The length of the input key K is 36 octets.
</t>
<t>
The HMAC-SHA-1 value is truncated to T_LEN=12 octets
instead of 16 octets. (Note that this matches the
truncation used in <xref target="RFC2404"/>.)
</t>
</list>
</t>
<t>
The input length restrictions are as for AEAD_AES_CBC_128_HMAC_SHA_256.
</t>
</section>
-->
<section title="Summary">
<t>
The parameters of the CBC-HMAC algorithms are summarized in the following table.
</t> <texttable>
<ttcol align="center"> algorithm </ttcol>
<ttcol align="center"> ENC_KEY_LEN </ttcol>
<ttcol align="center"> MAC_KEY_LEN </ttcol>
<ttcol align="center"> T_LEN </ttcol>
<c> AEAD_AES_128_CBC_HMAC_SHA_256 </c>
<c> 16 </c>
<c> 16 </c>
<c> 16 </c>
<c> AEAD_AES_192_CBC_HMAC_SHA_384 </c>
<c> 24 </c>
<c> 24 </c>
<c> 24 </c>
<c> AEAD_AES_256_CBC_HMAC_SHA_384 </c>
<c> 32 </c>
<c> 24 </c>
<c> 24 </c>
<c> AEAD_AES_256_CBC_HMAC_SHA_512 </c>
<c> 32 </c>
<c> 32 </c>
<c> 32 </c>
<!--
<c> AEAD_AES_128_CBC_HMAC_SHA1 </c>
<c> 16 </c>
<c> 20 </c>
<c> 12 </c>
-->
</texttable>
</section>
</section>
<!--
<section anchor="tlscompat" title="MAC-Encode-Encrypt (MEE) algorithms">
<t>
This section uses a different generic composition method, called
MAC-Encode-Encrypt (MEE); it is based on and compatible with
the way that CBC and HMAC are used in the Transport Layer Security (TLS)
protocol <xref target="RFC5246"/>.
The MEE method is regarded as slightly less robust, but adequately
secure as long as the HMAC authentication tag is not truncated
<xref target="PRS"/>.
</t>
<t>
Implementations of these MEE algorithms may be able to benefit
from implementation re-use with cryptographic functions that
support TLS.
</t>
<section title="Encryption">
<t>
Recall that in AEAD encryption, the inputs are K, P, A, and N, and a
single authenticated ciphertext C is output.
</t>
<t>
MEE-CBC-HMAC encryption processing 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 per Step 1 of ETM-CBC-HMAC.
</t>
<t> An Initialization Vector (IV) is generated randomly or
pseudorandomly, as described in <xref target="random"/>,
for use in the cipher.
</t>
<t>
The octet string AL is computed as per Step 5 of ETM-CBC-HMAC.
</t>
<t>A message authentication tag T is computed by applying
HMAC <xref target="RFC2104"/> to the following data, in
order:
<list style="empty">
<t> the associated data A, </t>
<t> the octet string AL defined above, and </t>
<t> the plaintext P. </t>
</list>
The string MAC_KEY is used as the HMAC key. We denote
the output of the MAC computed in this step as T.
</t>
<t>
The tag T is appended to the plaintext P, and a padding string PS
is appended to the resulting string, with PS computed as per Step
3 of ETM-CBC-HMAC encryption.
</t>
<t>
The plaintext, tag, and appended padding P || T || PS is
CBC encrypted using 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>
</list>
</t>
<t>
These steps can be illustrated as follows:
<list>
<t> MAC_KEY = initial MAC_KEY_LEN bytes of K </t>
<t> ENC_KEY = final ENC_KEY_LEN bytes of K </t>
<t> T = MAC(MAC_write_key, A || P) </t>
<t> C = IV || AES-CBC(write_key, P || T || padding || padding_length) </t>
</list>
</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 per Step 1 of ETM-CBC-HMAC.
</t>
<t> C is CBC decrypted, using the first 128 bits of the
ciphertext as the IV, and ENC_KEY as the decryption
key.</t>
<t>
The padding string is removed from the resulting
plaintext. Note that the length of PS can be inferred
from the value of the final octet of P || PS.
</t>
<t>
The final T_LEN octets are stripped from the plaintext.
Here T_LEN denotes the number of octets in the MAC,
which is a fixed parameter of the AEAD algorithm. We
denote the final T_LEN octets as T.
</t>
<t> The integrity and authenticity of A and C are checked
by computing the HMAC validation algorithm, using the same
inputs as in Step 4 of the encryption operation. In the
HMAC-validation process, the message consists of A, AL,
and 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 HMAC value for validation purposes. If the output
of the HMAC operation exactly matches T, then A and C are
considered valid, and the processing is
continued. Otherwise, all of the data used in the MAC
validation are discard, and the authenticated decryption
operation returns an indication that it failed, and the
operation halts.</t>
<t>
The padding string PS is checked to make sure that it
is in the correct format, namely, that each octet is
identical. This step MUST be performed after the
HMAC step. If the format is not correct, and
the authenticated decryption operation returns
an indication that it failed, and the operation halts.
This indication of failure MUST be identical to
that given in case of HMAC failure, to ensure
that an attacker cannot learn information
from the type of failure that occured during
the processing of a maliciously chosen ciphertext.
</t>
<t> The plaintext value is returned.</t>
</list></t>
</section>
<section title="AEAD_MEE_AES_128_CBC_HMAC_SHA256">
<t>This algorithm is randomized and stateless. It is based on
the MEE generic composition of CBC encryption with a MAC
defined above. It uses the HMAC message authentication code
<xref target="RFC2104"></xref> with the SHA256 hash function
<xref target="SHA2"></xref> to provide message authentication.
Test cases for HMAC-SHA256 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 used by PEM, PKCS, and TLS.
</t>
<t>
The input key K is 36 octets long.
</t>
<t>
The AES CBC IV is 16 octets long. ENC_KEY_LEN is 16
octets.
</t>
<t>
HMAC-SHA256 is used as the MAC. MAC_KEY_LEN is 32 octets.
The HMAC-SHA256 output is truncated to 16 octets, by
stripping off the final 16 octets.
</t>
<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 anchor="MEEaesHmac2" title="AEAD_MEE_AES_256_CBC_HMAC_SHA512">
<t>
AEAD_MEE_AES_CBC_256_HMAC_SHA512 is based on AEAD_MEE_AES_CBC_128_HMAC_SHA256,
but with the following differences:
<list>
<t>
AES-256 is used instead of AES-128.
</t>
<t>
HMAC-SHA512 is used instead of HMAC-SHA256.
</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 title="TLS Compatibility">
<t>
When using the MEE algorithms in TLS, the inputs are as follows:
<list>
<t> K = write_key || MAC_write_key </t>
<t> P = content </t>
<t> A = seq_num || TLSCompressed.type || TLSCompressed.version || TLSCompressed.length </t>
<t> MIN_LEN_A = len(A) </t>
<t> N = {} // nonce is zero length </t>
<t> GenericBlockCipher = C </t>
</list>
Note: here P and A are identical to the way that TLS uses AEAD. That
is, a GenericAEADCipher using MEE is compatible with the
GenericBlockCipher using the same AES and HMAC parameters.
</t>
<t>
To use the MEE algorithms in TLS, the key K will need to be generated
as per the TLS rules for AES and HMAC, and not the AEAD rules, which
are slightly different.
</t>
</section>
</section>
-->
<section anchor="random" title="Randomness Requirements">
<t>
Each IV MUST be unpredictable to the adversary. It MAY be chosen
uniformly at random, in which case it SHOULD have min-entropy
within one bit of len(IV). Alternatively, it MAY be generated
pseudorandomly, using any method that provides the same level of
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.
</t>
</section>
<section anchor="Rationale" title="Rationale">
<t>
The CBC-HMAC AEAD algorithms defined in this note are intended to be useful in
the following applications:
<list>
<t>
systems that have the CBC and HMAC algorithms available, but do
not have dedicated AEAD algorithms such as GCM or CCM <xref
target="RFC5116"/>,
</t>
<t>
scenarios in which AEAD is useful, but it is undesirable to have
the application maintain a deterministic nonce; see Section 4 of
<xref target="RFC5116"/> for more background,
</t>
<t>
new systems, such as JSON Cryptography and W3C Web Crypto, which can
omit unauthenticated symmetric encryption altogether by providing
CBC and HMAC through an AEAD interface.
</t>
</list>
</t>
<t>
These algorithms are not intended to replace existing
uses of AES-CBC and HMAC, 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>
-->
<t>
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
understanding of that length. Because of this, an attacker cannot
trick the receiver into interpreting the initial bytes of C as the
final bytes of A, or vice-versa.
</t>
<t>
The padding method used in this note is based on that of Privacy
Enhanced Mail (PEM) and the Public Key Cryptography Standards (PKCS),
because it is implemented in many environments.
</t>
<t>
The encrypt-then-MAC method is used because of its better security
properties. It would be possible to define AEAD algorithms based on
the MAC-encode-encrypt (MEE) method that is used by the Transport
Layer Security (TLS) protocol <xref target="RFC5246"/>. That
alternative would provide more code-sharing opportunities for an
implementation that is co-resident with a TLS implementation. It is
possible (but tricky) to implement MEE in a way that provides good
security, as was shown in <xref target="PRS11"/>. But its negatives
outweigh its positives; its security is inadequate for some parameter
choices, and it has proven to be difficult to implement in a way that
resists padding oracle and related timing attacks
<xref target="V02"/>
<xref target="CHVV03"/>
<xref target="M04"/>
<xref target="DP10"/>
<xref target="AP12"/>. For future uses of CBC and HMAC, it is better
to use encrypt-then-MAC."
</t>
<t>
This note uses HMAC-SHA-2 because it is widely deployed, it is
mandated in newer standards, and because SHA1 is being deprecated. 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 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
straightforward, there are multiple options for its use in
authenticated encryption. The focus of this note is the definition of
AEAD algorithms based on currently used cryptographic mechanisms, so
SHA-3 is out of scope.
</t>
</section>
<section title="Test Cases">
<section title="AEAD_AES_128_CBC_HMAC_SHA256">
<figure > <artwork>
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
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
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
</artwork></figure>
<figure > <artwork>
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
</artwork></figure>
<figure > <artwork>
S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79
a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9
a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2
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
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
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
T = 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4
</artwork></figure>
<figure > <artwork>
C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79
a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9
a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2
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
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
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
65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4
</artwork></figure>
</section>
<section title="AEAD_AES_192_CBC_HMAC_SHA384">
<figure> <artwork>
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
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
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
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
</artwork></figure>
<figure > <artwork>
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
</artwork></figure>
<figure > <artwork>
S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5
d3 03 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db
00 0d 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6
57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21
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
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
f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3
T = 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20
75 16 80 39 cc c7 33 d7
</artwork></figure>
<figure > <artwork>
C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5
d3 03 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db
00 0d 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6
57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21
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
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
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
75 16 80 39 cc c7 33 d7
</artwork> </figure>
</section>
<section title="AEAD_AES_256_CBC_HMAC_SHA384">
<figure>
<artwork>
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
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
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
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
</artwork></figure>
<figure > <artwork>
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
</artwork></figure>
<figure > <artwork>
S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
89 31 29 b0 f4 ee 9e b1 8d 75 ed a6 f2 aa a9 f3
60 7c 98 c4 ba 04 44 d3 41 62 17 0d 89 61 88 4e
58 f2 7d 4a 35 a5 e3 e3 23 4a a9 94 04 f3 27 f5
c2 d7 8e 98 6e 57 49 85 8b 88 bc dd c2 ba 05 21
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
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
d9 f5 06 23 21 98 a4 89 a1 a6 ae 03 a3 19 fb 30
T = dd 13 1d 05 ab 34 67 dd 05 6f 8e 88 2b ad 70 63
7f 1e 9a 54 1d 9c 23 e7
</artwork></figure>
<figure > <artwork>
C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
89 31 29 b0 f4 ee 9e b1 8d 75 ed a6 f2 aa a9 f3
60 7c 98 c4 ba 04 44 d3 41 62 17 0d 89 61 88 4e
58 f2 7d 4a 35 a5 e3 e3 23 4a a9 94 04 f3 27 f5
c2 d7 8e 98 6e 57 49 85 8b 88 bc dd c2 ba 05 21
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
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
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
7f 1e 9a 54 1d 9c 23 e7
</artwork>
</figure>
</section>
<section title="AEAD_AES_256_CBC_HMAC_SHA512">
<figure>
<artwork>
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
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
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
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
</artwork></figure>
<figure > <artwork>
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
</artwork></figure>
<figure > <artwork>
S = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd
3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd
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
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
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
be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6
T = 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
</artwork></figure>
<figure > <artwork>
C = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd
3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd
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
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
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
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
2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5
</artwork>
</figure>
</section>
<!--
<section title="AEAD_AES_128_CBC_HMAC_SHA1">
<figure >
<artwork>
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
</artwork></figure>
<figure > <artwork>
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
</artwork></figure>
<figure > <artwork>
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
</artwork></figure>
<figure > <artwork>
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
</artwork>
</figure>
</section>
-->
</section>
<section title="Security Considerations">
<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="BN00"></xref>. This
method has sound and well-understood security properties; for details,
please see that reference. Note that HMAC is a good pseudorandom
function and is "strongly unforgeable", and thus meets all of
the security goals of that reference.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
There are security benefits to providing both confidentiality and
authentication in a single atomic operation, as done in this note.
This tight binding prevents subtle attacks such as the padding
oracle attack.
</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. because of the limit, 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>
</section>
<!--
<section title="Discussion">
<t>
</t>
</section>
-->
<section title="Acknowledgements">
<t>
Thanks are due to Matt Miller for his constructive feedback,
Kelly Burgin, Michael Peck, and Mike Jones for their suggestions and help,
and Jim Schaad and Rob Napier for their excellent review and suggestions.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2104;
&rfc2119;
<!--
&rfc2202;
&rfc2404;
-->
&rfc4231;
&rfc4868;
&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="FIPS186-2">
<front>
<title>FIPS 180-2: 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>
<reference anchor="FIPS197">
<front>
<title>FIPS 197: Advanced Encryption Standard (AES)</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/fip197.htm" />
</reference>
</references>
<references title="Informative References">
&rfc4086;
<reference anchor="SP800-38">
<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>
<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="R02">
<front>
<title>Authenticated encryption with Associated-Data</title>
<author fullname="Philip Rogaway">
<organization />
</author>
</front>
<seriesInfo name="Proceedings of the 2002 ACM Conference on Computer and Communication Security (CCS'02), pp. 98-107, ACM Press, 2002."
value="http://www.cs.ucdavis.edu/~rogaway/papers/ad.pdf" />
</reference>
<reference anchor="PRS11">
<front>
<title>Tag Size Does Matter: Attacks and Proofs for the TLS Record Protocol</title>
<author initials="K." surname="Paterson">
<organization></organization>
</author>
<author initials="T." surname="Ristenpart">
<organization></organization>
</author>
<author initials="T." surname="Shrimpton">
<organization></organization>
</author>
<date month="January" year="2012" />
</front>
<seriesInfo name="IEEE Symposium on Security and Privacy 2012"
value="http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf" />
</reference>
<reference anchor="V02">
<front>
<title> Security Flaws Induced by CBC Padding - Applications to SSL, IPSEC, WTLS .... </title>
<author initials="S." surname="Vaudenay">
<organization></organization>
</author>
<date year="2002" />
</front>
<seriesInfo name="EUROCRYPT 2002"
value="http://lasecwww.epfl.ch/php_code/publications/search.php?ref=Vau02a" />
</reference>
<reference anchor="CHVV03">
<front>
<title> Password Interception in a SSL/TLS Channel</title>
<author initials="S." surname="Vaudenay">
<organization></organization>
</author>
<author initials="B." surname="Canvel">
<organization></organization>
</author>
<author initials="A." surname="Hiltgen">
<organization></organization>
</author>
<author initials="M." surname="Vuagnoux">
<organization></organization>
</author>
<date year="2003" />
</front>
<seriesInfo name="CRYPT0 2003"
value="http://lasecwww.epfl.ch/pub/lasec/doc/CHVV03.ps" />
</reference>
<reference anchor="M04">
<front>
<title> Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures</title>
<author initials="B." surname="Moeller">
<organization></organization>
</author>
<date year="2004" />
</front>
<seriesInfo name="Web Page"
value="http://www.openssl.org/~bodo/tls-cbc.txt" />
</reference>
<reference anchor="DP10">
<front>
<title>On the (in)security of IPsec in MAC-then-encrypt configurations.</title>
<author initials="K." surname="Paterson">
<organization></organization>
</author>
<author initials="J.P." surname="Degabriele">
<organization></organization>
</author>
<date year="2010" />
</front>
<seriesInfo name="ACM Conference on Computer and Communications Security (ACM CCS) 2010"
value="http://www.isg.rhul.ac.uk/~kp/CCSIPsecfinal.pdf" />
</reference>
<reference anchor="DP07">
<front>
<title>Attacking the IPsec Standards in Encryption-only
Configurations</title>
<author initials="K." surname="Paterson">
<organization></organization>
</author>
<author initials="J.P." surname="Degabriele">
<organization></organization>
</author>
<date year="2007" />
</front>
<seriesInfo name="IEEE Symposium on Privacy and Security"
value="http://eprint.iacr.org/2007/125.pdf" />
</reference>
<reference anchor="AP12">
<front>
<title>Plaintext-Recovery Attacks Against Datagram TLS</title>
<author initials="K." surname="Paterson">
<organization></organization>
</author>
<author initials="N." surname="AlFardan">
<organization></organization>
</author>
<date year="2012" />
</front>
<seriesInfo name="Network and Distributed System Security Symposium (NDSS) 2012"
value="http://www.isg.rhul.ac.uk/~kp/dtls.pdf" />
</reference>
<reference anchor="YHR04">
<front>
<title>The Perils of Unauthenticated Encryption: Kerberos Version 4</title>
<author initials="T." surname="Yu">
<organization></organization>
</author>
<author initials="S." surname="Hartman">
<organization></organization>
</author>
<author initials="K." surname="Raeburn">
<organization></organization>
</author>
<date year="2004" />
</front>
<seriesInfo name="Network and Distributed Security Symposium (NDSS) 2004"
value="http://web.mit.edu/tlyu/papers/krb4peril-ndss04.pdf" />
</reference>
<reference anchor="B96">
<front>
<title>Problem areas for the IP security protocols</title>
<author initials="S." surname="Bellovin">
<organization></organization>
</author>
<date year="1996" />
</front>
<seriesInfo name="Proceedings of the Sixth Usenix Unix Security Symposium"
value="https://www.cs.columbia.edu/~smb/papers/badesp.pdf" />
</reference>
&rfc5246;
<!--
<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/13"/>
</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;
-->
</references>
<section anchor="cbc" title="CBC Encryption and Decryption">
<t>
The Cipher Block Chaining (CBC) mode of operation is defined
in Section 6.2 of <xref target="SP800-38"/>. This section recalls how that
mode works, for the convenience of the reader.
The following notation is used:
<list>
<t>
K denotes the key of the underlying block cipher,
</t>
<t>
The function CIPHER(K, P) denotes the encryption of the
block P with the block cipher, where P contains exactly
b bits,
</t>
<t>
The function CIPHER-INV(K, C) denotes the decryption of the
block C with the block cipher, where C contains exactly b
bits; this is the inverse operation of CIPHER(), and
CIPHER-INV(K, CIPHER(K, P)) = P for all P and all K,
</t>
<t>
P_1, P_2, ... , P_n denotes the sequence of plaintext blocks,
where each block contains exactly b bits,
</t>
<t>
C_0, C_1, C_2, ... , C_n denotes the sequence of ciphertext blocks,
where each block contains exactly b bits,
</t>
<t>
P_i and C_i denote the ith blocks of the plaintext, and
</t>
<t>
IV denotes the initialization vector, which contains exactly
b bits.
</t>
</list>
The CBC encryption operation (denoted as CBC-ENC) takes as input
a sequence of n plaintext blocks and produces a sequence
of n + 1 ciphertext blocks as follows:
</t>
<figure>
<artwork><![CDATA[
IV = random
C_i = / IV if i=0,
\ CIPHER(K, P_i XOR C_{i-1}) if i=1, 2, ... , n.
]]></artwork>
</figure>
<t>
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.
</t>
<t>
The IV MUST be generated using a uniformly random process, or a
pseudorandom process with a cryptographic strength equivalent to
that of the underlying block cipher; see <xref
target="RFC4086"/> for background on random sources. It MUST
NOT be predictable to an attacker; in particular, it MUST NOT be
set to the value of any previous ciphertext blocks.
</t>
<t>
The CBC decryption operation (denoted as CBC-DEC) takes as input
a sequence of m ciphertext blocks and produces a sequence
of m-1 plaintext blocks as follows:
</t>
<figure>
<artwork><![CDATA[
P_i = CIPHER-INV(K, C_i) XOR C_{i-1} for i=1, 2, ... , n.
]]></artwork>
</figure>
<t>
The initial block C_0 corresponds to the initialization vector.
</t>
</section>
<section title="Alternative Interface for Legacy Encoding">
<t>
In some scenarios, cryptographic data such as the ciphertext,
initialization vector, and message authentication tag are
encoded separately. To allow for the use of the algorithms
defined in this document in such scenarios, this appendix
describes an interface in which those data elements are
discrete. New implementations SHOULD NOT use this interface,
because it is incompatible with other authenticated encryption
methods and is more complex; however, it MAY be useful
in scenarios in which the separate encoding is already
in use.
</t>
<!--
<t>
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.
</t>
-->
<t>
The alternative interface is as follows.
The inputs to the encryption operation the same as those
defined in <xref target="Enc"/> (the secret key K, the
plaintext P, the associated data A).
The outputs of the encryption operation are:
<list>
<t>
the initialization vector IV as defined in <xref target="cbc"/>,
</t>
<t>
the ciphertext C, as defined in <xref target="cbc"/>, and
</t>
<t>
the message authentication tag T, as defined in <xref target="Enc"/>.
</t>
</list>
</t>
<t>
The inputs to the decryption operation are:
<list>
<t>
the initialization vector IV as defined in <xref target="cbc"/>,
</t>
<t>
the ciphertext C, as defined in <xref target="cbc"/>, and
</t>
<t>
the message authentication tag T, as defined in <xref target="Enc"/>.
</t>
</list>
The output of the decryption operation is the same as that
defined in <xref target="Dec"/> (either a plaintext value P or a
special symbol FAIL that indicates that the inputs are not
authentic).
</t>
<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 encryption operation, rather than an input.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:26:49 |