One document matched: draft-mcgrew-aead-aes-cbc-hmac-sha2-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 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-01.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 A. McGrew" initials="D.A.M." surname="McGrew">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street> 13600 Dulles Technology Drive </street>
<city>Herndon</city>
<region>VA</region>
<code>20171</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>
<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="October" year="2012" />
<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) [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 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>
<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 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"/>, <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.
</t>
<t>
In CBC-HMAC, the nonce 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. <!--
(Note that this IV is distinct
from the nonce that may be provided as an input to the
authenticated encryption operation.)
-->
</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, 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>
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. 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. If those values are identical, then A and
C are considered valid, and processing is
continued. 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 decrypted, using the initial 16 octets of
the ciphertext as the IV. The value ENC_KEY is used
as the decryption key.</t>
<t>
The padding string is removed. Note that the length
of PS can be inferred from the value of the final
octet of P || PS, if that value is between 00 and 0F
(hexadecimal). If the final octet has a value outside
that range, then all of the data used in the
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 and stateless. It is based on
the CBC-HMAC algorithm detailed above. It 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 AES
in the cipher block chaining (CBC) mode of operation as
defined in Section 6.2 of <xref target="SP800-38"></xref>, with
the padding method used by PEM, PKCS, and TLS. </t>
<t>
The input key K is 32 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 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="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>
<t>
SP 800-90 describes suitable pseudorandom generators.
</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 applicaiton 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-SHA1 because it is widely deployed and is
adequately secure, and HMAC-SHA-2, because it is used in newer
standards and is expected to become widely deployed. 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">
<t>
A future version of this note will contain test cases for all of the
AEAD algorithms that it defines.
</t>
<!--
<section title="AEAD_AES_128_CBC_HMAC_SHA1">
<figure >
<artwork>
P = 41206369706865722073797374656d206d757374206e6f742062652072657175
6972656420746f206265207365637265742c20616e64206974206d7573742062
652061626c6520746f2066616c6c20696e746f207468652068616e6473206f66
2074686520656e656d7920776974686f757420696e636f6e76656e69656e6365
K = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
20212223
MAC_KEY = 000102030405060708090a0b0c0d0e0f10111213
ENC_KEY = 1415161718191a1b1c1d1e1f20212223
A = 546865207365636f6e64207072696e6369706c65206f66204175677573746520
4b6572636b686f666673
IV = 1af38c2dc2b96ffdd86694092341bc04
C_0 = 1af38c2dc2b96ffdd86694092341bc04
P_1 = 41206369706865722073797374656d20
C_1 = c63aec9963f4ff33a85e564cd05f9240
P_2 = 6d757374206e6f742062652072657175
C_2 = 0a71fe98bcb339acc1d78c92b3aa6a32
P_3 = 6972656420746f206265207365637265
C_3 = 1460d2aecec43b784b3b08b830be5291
P_4 = 742c20616e64206974206d7573742062
C_4 = dc0400b8afc6cd1c8475764632a83605
P_5 = 652061626c6520746f2066616c6c2069
C_5 = 01e5319a128127ae4b0eaa9b2f97ea6d
P_6 = 6e746f207468652068616e6473206f66
C_6 = f02200d6f68c743b794ed5d6139e84c4
P_7 = 2074686520656e656d7920776974686f
C_7 = cb919ebb8d8256098b6385e41476c416
P_8 = 757420696e636f6e76656e69656e6365
C_8 = cfc85a46fac40ea450d2b4c0fd7e03dc
P_9 = 10101010101010101010101010101010
C_9 = d833c8c3d2135f0d109bd231808bb3fd
S = 1af38c2dc2b96ffdd86694092341bc04c63aec9963f4ff33a85e564cd05f9240
0a71fe98bcb339acc1d78c92b3aa6a321460d2aecec43b784b3b08b830be5291
dc0400b8afc6cd1c8475764632a8360501e5319a128127ae4b0eaa9b2f97ea6d
f02200d6f68c743b794ed5d6139e84c4cb919ebb8d8256098b6385e41476c416
cfc85a46fac40ea450d2b4c0fd7e03dcd833c8c3d2135f0d109bd231808bb3fd
T = 9aed4feb1e6d25070b9a6f07
C = 1af38c2dc2b96ffdd86694092341bc04c63aec9963f4ff33a85e564cd05f92400
a71fe98bcb339acc1d78c92b3aa6a321460d2aecec43b784b3b08b830be5291dc
0400b8afc6cd1c8475764632a8360501e5319a128127ae4b0eaa9b2f97ea6df02
200d6f68c743b794ed5d6139e84c4cb919ebb8d8256098b6385e41476c416cfc8
5a46fac40ea450d2b4c0fd7e03dcd833c8c3d2135f0d109bd231808bb3fd9aed4
feb1e6d25070b9a6f07
</artwork>
</figure>
</section>
<section title="AEAD_AES_128_CBC_HMAC_SHA256">
<figure >
<artwork>
K = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
20212223242526270001020304050607
P = 41206369706865722073797374656d206d757374206e6f742062652072657175
6972656420746f206265207365637265742c20616e64206974206d7573742062
652061626c6520746f2066616c6c20696e746f207468652068616e6473206f66
2074686520656e656d7920776974686f757420696e636f6e76656e69656e6365
A = 546865207365636f6e64207072696e6369706c65206f66204175677573746520
4b6572636b686f666673
IV = 1af38c2dc2b96ffdd86694092341bc04
S = 1af38c2dc2b96ffdd86694092341bc04bec9dc25654f7eee633a29d2a14becfe
79d5b3bfd19b0676584990ee84bb4279197d7ebca389b7e5c101898eed58c34b
df22b74683a82cf07ae4ddeb4bf5731fc00dd4a98195de6e2e36985161bbe5ec
13067e3508162da908dede1808a97578dc896d221063c7425679fd6bcfb8ce90
c197fd05447a2cf7f2fe02a03fdf29c675fa66ecb12e398b7f6fc3c9ae3d03ba
T = e0f20e4a7d3fa9dd5aadcd3ad982f09e
C = 1af38c2dc2b96ffdd86694092341bc04bec9dc25654f7eee633a29d2a14becfe
79d5b3bfd19b0676584990ee84bb4279197d7ebca389b7e5c101898eed58c34b
df22b74683a82cf07ae4ddeb4bf5731fc00dd4a98195de6e2e36985161bbe5ec
13067e3508162da908dede1808a97578dc896d221063c7425679fd6bcfb8ce90
c197fd05447a2cf7f2fe02a03fdf29c675fa66ecb12e398b7f6fc3c9ae3d03ba
e0f20e4a7d3fa9dd5aadcd3ad982f09e
</artwork>
</figure>
</section>
<section title="AEAD_AES_192_CBC_HMAC_SHA384">
<figure>
<artwork>
K = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
2021222324252627000102030405060708090a0b0c0d0e0f1011121314151617
18191a1b1c1d1e1f
P = 41206369706865722073797374656d206d757374206e6f742062652072657175
6972656420746f206265207365637265742c20616e64206974206d7573742062
652061626c6520746f2066616c6c20696e746f207468652068616e6473206f66
2074686520656e656d7920776974686f757420696e636f6e76656e69656e6365
IV = 1af38c2dc2b96ffdd86694092341bc04
A = 546865207365636f6e64207072696e6369706c65206f66204175677573746520
4b6572636b686f666673
PS = 10101010101010101010101010101010
AL = 0000000000000150
S = 1af38c2dc2b96ffdd86694092341bc04ac57bb8225686ff568320b98ad54fa10
eea70c609d4d11d4c34435e386623d0240e9f6c0f78126678546ae2ba2d3017c
4e0ef70d7c5ec2724fecf715518bc48e9048e446077db090e135f33710a2c40d
e0ea744adeca3149a94f9be65fe3e2982ca63e89d026e39319322b417ff9ee5a
b06b71ea5894d9f0ad5089402e174a90cf65bed15f8835d3134a6302ef6cfd4d
T = 0b3948b860797cc2ba0f89d3e79d5465ed770cc8e5b8a430
C = 1af38c2dc2b96ffdd86694092341bc04ac57bb8225686ff568320b98ad54fa10
eea70c609d4d11d4c34435e386623d0240e9f6c0f78126678546ae2ba2d3017c
4e0ef70d7c5ec2724fecf715518bc48e9048e446077db090e135f33710a2c40d
e0ea744adeca3149a94f9be65fe3e2982ca63e89d026e39319322b417ff9ee5a
b06b71ea5894d9f0ad5089402e174a90cf65bed15f8835d3134a6302ef6cfd4d
0b3948b860797cc2ba0f89d3e79d5465ed770cc8e5b8a430
</artwork>
</figure>
</section>
<section title="AEAD_AES_256_CBC_HMAC_SHA384">
<figure>
<artwork>
TBD
</artwork>
</figure>
</section>
<section title="AEAD_AES_256_CBC_HMAC_SHA512">
<figure>
<artwork>
K = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
2021222324252627000102030405060708090a0b0c0d0e0f1011121314151617
18191a1b1c1d1e1f2021222324252627000102030405060708090a0b0c0d0e0f
P = 41206369706865722073797374656d206d757374206e6f742062652072657175
6972656420746f206265207365637265742c20616e64206974206d7573742062
652061626c6520746f2066616c6c20696e746f207468652068616e6473206f66
2074686520656e656d7920776974686f757420696e636f6e76656e69656e6365
IV = 1af38c2dc2b96ffdd86694092341bc04
A = 546865207365636f6e64207072696e6369706c65206f66204175677573746520
4b6572636b686f666673
PS = 10101010101010101010101010101010
AL = 0000000000000150
S = 1af38c2dc2b96ffdd86694092341bc04d39c2d2b1248eb14a7f8d1c1e8f3ff17
309d44cb0cb0dfd38695bf29f37258f74fc9ef1d05b7c71cb3c6fb04bad09105
bc605e8b9c737008a47453b9415cd7407e7314cc73f5ba432172b6da53c33553
8ba9614d79f36e393c8178ba8fb2deec0eaa4cf1eda1cf279fabd9799af60542
04c96e06eacedb231c76c33e38317882eeb55fd9e534c1e73343d8cf00ff283a
T = 2cf60bc4a50b569f0ae708a7889761b3f867c37537a8bd74c162e9b8ee859b08
C = 1af38c2dc2b96ffdd86694092341bc04d39c2d2b1248eb14a7f8d1c1e8f3ff17
309d44cb0cb0dfd38695bf29f37258f74fc9ef1d05b7c71cb3c6fb04bad09105
bc605e8b9c737008a47453b9415cd7407e7314cc73f5ba432172b6da53c33553
8ba9614d79f36e393c8178ba8fb2deec0eaa4cf1eda1cf279fabd9799af60542
04c96e06eacedb231c76c33e38317882eeb55fd9e534c1e73343d8cf00ff283a
2cf60bc4a50b569f0ae708a7889761b3f867c37537a8bd74c162e9b8ee859b08
</artwork>
</figure>
</section>
-->
</section>
<section title="Security Considerations">
<t>
An earlier version of this document benefitted from some review.
Comments on this version are requested and should be forwarded to 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="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>
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 and John Foley for their
constructive feedback; special thanks to John for his generation
of the test cases. Thanks also to Kelly Burgin and Michael Peck
for their suggestions and help.
</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">
<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;
&rfc4107;
-->
</references>
<section title="CBC Encryption and Decryption">
<t>
The Cipher Block Chaining (CBC) mode of operation is defined
in <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,
</t>
<t>
The function CIPHER-INV(K, C) denotes the decryption of the
block C with the block cipher; 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 the number of bits that
the block cipher accepts as its plaintext input,
</t>
<t>
C_0, C_1, C_2, ... , C_n denotes the sequence of ciphertext blocks,
where each block contains exactly the number of bits that
the block cipher accepts as its plaintext input,
</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
the number of bits that the block cipher accepts as its
plaintext input.
</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>
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. 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, P_1 XOR IV) for i=1, 2, ... , n.
]]></artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:18:36 |