One document matched: draft-mcgrew-aero-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 rfc4418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4418.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 rfc4771 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4771.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">
<!ENTITY rfc5297 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5297.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<rfc category="std" docName="draft-mcgrew-aero-01.txt"
ipr="trust200902">
<front>
<title abbrev="AERO">
Authenticated Encryption with Replay prOtection (AERO)
</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>
<date month="February" year="2014" />
<area>General</area>
<keyword>Encryption, Authentication, Replay</keyword>
<abstract>
<t>
This document describes Authenticated Encryption with Replay
prOtection (AERO), a cryptographic technique that provides all of
the essential security services needed for communication security.
AERO offers several advantages over other methods: it has more
compact messages, provides stronger misuse resistance, avoids the
need to manage implicit state, and is simpler to use. This
document defines a particular AERO algorithm as well as a registry
for such algorithms.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
This document describes Authenticated Encryption with Replay
prOtection (AERO), a cryptographic technique that provides all of
the essential security services needed for communication security.
</t>
<t>
AERO can be considered a stateful and self-synchronizing
authenticated encryption method that provides protection
from replay attacks as a side benefit. Replay protection and
authentication are provided through a single mechanism, in
which a sequence number is encrypted along with a plaintext
message. If the ciphertext message is not tampered with, then
this sequence number will be recovered by the decrypter, and
verified to be valid. If the ciphertext message is a replay
of an earlier message, then the decrypter will detect this
fact from the recovered sequence number. If the ciphertext
message is tampered with, or is crafted as a forgery, this
fact will be apparent to the decrypter because the value that
should be a valid sequence is instead a pseudorandom value.
</t>
<t>
AERO makes use of an underlying stateless encryption
algorithm. This note defines a set of AERO algorithms that
are based on an underlying Wide Pseudo-Random Permutation
(WPRP). AERO is not, by itself, a block cipher mode of
operation.
</t>
<t>
This note is structured as follows. <xref target="intro"/>
introduces the basic idea of AERO, describes the conventions
and notations used in this note, and provides a glossary of
acronyms and variables. <xref target="background"/> provides
background on the problems that AERO solves. The interface and
implementation are presented in <xref target="interface"/> and
<xref target="implementation"/>, respectively. The underlying
cryptographic primitives are described in <xref
target="stateless"/>. <xref target="synch"/> describes
synchronization between encrypters and decrypters, and <xref
target="usage"/> describes usage. A rationale for the design
details is offered in <xref target="rationale"/>, and test
considerations and test cases are presented in
<xref target="test"/>. IANA considerations and security
considerations follow in <xref target="iana"/> and <xref
target="security"/>, respectively.
</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">
</section>
-->
<section title="Conventions used in this document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="glossary" title="Glossary">
<t>
This section describes the symbols and acronyms used in this
document.
</t>
<t>
<list>
<t>
A - Associated Data. An unencrypted value whose
integrity and authenticity is to be protected.
</t>
<t>
AERO - Authenticated Encryption with Replay prOtection. A
cryptographic technique that combines the three security
services essential to communication security.
</t>
<t>
C - Ciphertext. An encrypted value that corresponds to a
plaintext.
</t>
<t>
FAIL - a value returned by the AERO decryption operation
to indicate that a ciphertext message is not valid; it
could be either a replay or a forgery attempt.
</t>
<t>
K - Key. A secret key that is shared between
the sender(s) and receiver(s).
</t>
<t>
M - bitmask. A bit vector used by the AERO decryption
algorithm that holds information about the sequence
numbers that have already been accepted. If a message
with the sequence number X has been accepted and the
current sequence number S > X, then M[S-X] = 1; otherwise
M[S-X] = 0.
</t>
<t>
P - Plaintext. An unencrypted value whose
confidentiality, integrity and authenticity is to be
protected.
</t>
<t>
PMIN - minimum number of bytes of plaintext for a
stateless encryption algorithm. PMIN is a parameter of
the stateless encryption algorithm, which is used in the
padding logic.
</t>
<t>
R - the last rejected candidate sequence number that is
greater than the current sequence number S. A T-bit
unsigned integer maintained by the AERO decryption
algorithm.
</t>
<t>
S - the current sequence number. A T-bit unsigned integer
maintained by the AERO encryption algorithm, where it
represents the sequence number of the next message to be
encrypted, and by the AERO decryption algorithm, where it
represents the last candidate sequence number that was
accepted.
</t>
<t>
T - The number of bits in the sequence number that
is internal to AERO encryption and decryption.
</t>
<t>
W - Reorder tolerance parameter. A parameter used in AERO
decryption (but not encryption) that determines the amount
of message loss or reorder that the algorithm will
tolerate. This value is 64 by default, but other values
may be used as well.
</t>
<t>
V - Resynchronization parameter. A parameter that
determines the amount of message loss or reorder that the
AERO decryption algorithm will tolerate during
resynchronization. This value is 8 by default, but other
values may be used as well.
</t>
<t>
Z - the candidate sequence number. A value used in AERO
decryption that may be a sequence number, or alternately may
be data that resulted from the actions of an attacker.
</t>
</list>
</t>
</section>
<section anchor="notation" title="Data types and notation">
<t>
An octet string is an ordered sequence of eight-bit values.
Note that these strings are not character strings, and
issues such as character representation are out of scope for
this note.
</t>
<t>
len(X) denotes the number of bits in the string X,
expressed as an unsigned integer in network byte order.
</t>
<t> The concatenation of two octet strings A and B is
denoted as A || B
</t>
<t>
Conversion between unsigned integers and octet strings is
done as follows. The Integer to String (I2S) algorithm
takes as input an unsigned integer U, and converts it to
network byte order (that is, a big-endian representation, in
which the most significant octet is the initial one), and
then returns the resulting octet string. The String to
Integer (S2I) algorithm takes as input an octet string S,
considers it as an integer in network byte order, and then
converts it into the internal representation for unsigned
integers used by the system.
</t>
</section>
</section>
<section anchor="background" title="Background">
<t>
Authenticated encryption <xref target="BN00"/> is a form of
encryption that, in addition to providing confidentiality for the
plaintext that is encrypted, provides a way to check its integrity
and authenticity. Authenticated Encryption with Associated Data,
or AEAD <xref target="R02"/>, adds the ability to check the
integrity and authenticity of some Associated Data (AD), also
called "additional authenticated data", that is not encrypted.
</t>
<t>
AEAD is used in many communication security protocols, such as ESP,
TLS, DTLS, IKE, and SRTP. These protocols also incorporate replay
protection using an sequence number that is carried in the packet,
which is authenticated because it is part of the associated data.
This security service enables the receiver of a message to detect
when a received message is a duplicate of a previously received
message.
</t>
<t>
In order to minimize the data overhead, some protocols (such as
SRTP and ESP) have the most significant part of the sequence
number (that is, the high order bits) be implicit state, which is
not sent on the wire. The receiver constructs an estimate of the
sequence number from the data on the wire and its current state.
</t>
<t>
Authenticated Encryption with Replay prOtection (AERO) extends AEAD
so that it provides a replay protection service. It also enables a
receiver to correctly sequence all of the messages that it receives
into the same order that they were sent. A replay protection
service has a reorder tolerance parameter W; if a receiver
processes a message that is more than W messages earlier than a
previously processed message, then the service will reject the
message even if it is not a replay.
</t>
<section title="Problems addressed by AERO">
<t>
Many communication security protocols are operated in environments
where bandwidth is a scarce resource, and thus they seek to
minimize the data overhead, that is, the number of
additional bytes that must be communicated in order to add
confidentiality, authenticity, and replay protection to each
message. To authenticate a message, lengthening it is unavoidable.
However, traditional encryption and replay protection techniques
add avoidable overhead. Encryption methods methods such as AES-CBC
encryption <xref target="SP800-38"/> have an average overhead of 24
bytes, and many uses of CTR, GCM <xref target="GCM"/>, and CCM
<xref target="CCM"/> have eight bytes of overhead because a nonce
is carried in each message. In addition to that overhead, replay
protection typically adds its own overhead; the use of a four-byte
sequence number, for instance, adds that number of bytes.
</t>
<t>
Some communication security protocol uses an implicit or partly
implicit sequence number to reduce overhead. This practice
complicates the use of that protocol whenever there are multiple
receivers, since it is necessary to (securely) communicate the
current value of the implicit part of the sequence number to a new
receiver at the time that the receiver joins the session. For
instance, <xref target="RFC4771"/> furnishes an example of the
complications introduced by the need to manage implicit state.
</t>
<t>
Several cryptographic algorithms require that a distinct nonce is
input into each invocation of the encryption algorithm. This
requirement is difficult to satisfy if there are multiple senders,
or multiple encryption units, using the same secret key. Algorithms
that require nonces introduce significant complexity into the
systems that use them, as is revealed by the survey of usage of and
issues with nonces in Internet protocols <xref target="IV-GEN"/>.
One of the cannons of computer security is that "input is evil",
that is, data that is accepted into a security module might be
manipulated by an attacker and thus should not be trusted until it
has been validated. A cryptographic algorithm that accepts a nonce
and requires it to be distinct introduces an opportunity for an
attacker to defeat security through "evil" influence of that input.
</t>
<t>
Several cryptographic algorithms that require a distinct nonce as an
input have a serious security degradation if there is nonce misuse
(that is, if a system failure results in two or more identical
nonces being used for the same key). CTR, CCM, and GCM all have a
loss of confidentiality for each message that is associated with a
misused nonce. GCM, GMAC <xref target="GCM"/>, UMAC <xref
target="RFC4418"/>, and POLY1305 leak their authentication keys
after nonce misuse. In scenarios in which it is not possible to
provide high assurance that nonces will not be misused, these
algorithms may not be appropriate.
</t>
<t>
Both dedicated authenticated encryption algorithms, and the
traditional method of combination of separate authentication and
encryption algorithms, are often complex to use. Nonces and
initialization vectors, especially, are often a source of confusion
for implementers and application designers.
</t>
<t>
AERO solves these problems by using a technique that combines
message authentication with replay protection, thus eliminating the
data overhead associated with replay protection and any need for
using implicit state. AERO does not use a nonce as input, which
addresses multiple issues: it reduces data overhead, it avoids all
of the problems of coordinating nonces and the potential problems of
nonce misuse, and it simplifies the jobs of the designers and
implementers of applications and protocols. AERO can easily be used
in multiple-sender scenarios, because no coordination of nonces is
needed, and in multiple-receiver scenarios, because no coordination
of implicit state is needed.
</t>
</section>
</section>
<section anchor="interface" title="Interface">
<t>
An AERO algorithm has four operations: encryption,
decryption, encryption initialization, and decryption
initialization. The inputs and outputs of these algorithms are
defined below in terms of octet strings.
An octet string is an ordered sequence of eight-bit values.
</t>
<t>
The terms "AERO encryption" and "AERO decryption" refer to
algorithms that provide authenticated encryption with replay
protection. For brevity, these algorithms are simply called
"encryption" and "decryption" when AERO is clear from the context.
</t>
<t>
An implementation MAY accept additional inputs to these algorithms.
For example, an optional input could be provided to allow the user
to select between different implementation strategies. However,
such extensions MUST NOT affect interoperability with other
implementations.
</t>
<section title="Encryption Initialization">
<t>
The encryption initialization operation has one input:
<list >
<t>
A secret key K, which MUST be generated in a way that is
uniformly random or pseudorandom. This input is an octet string.
The number of octets in K is fixed for each AERO algorithm,
and is between 1 and 255.
</t>
</list>
The operation has a single output, an AERO encryption context.
</t>
</section>
<section title="Encryption">
<t>
The AERO encryption operation has three inputs, each of which
is an octet string:
<list>
<t>
An AERO encryption context.
</t>
<t>
A plaintext P, which contains the data to be encrypted and
authenticated. The number of octets in P MAY be zero.
</t>
<t>
The associated data A, which contains the data to be
authenticated, but not encrypted. The number of octets in A MAY
be zero.
</t>
</list>
There is a single output:
<list>
<t>
A ciphertext C, which is an octet string that is at least as
long as the plaintext.
</t>
<!--
<t>
an indication that the requested encryption operation could not be
performed.
</t>
-->
</list>
</t>
<t>
A plaintext P and its associated data A is sometimes denoted
together as (A, P), and that pair of elements is called a plaintext
message. Similarly, a ciphertext C and its associated data A is
denoted together as (A, C), and is called a ciphertext message.
</t>
</section>
<section title="Decryption Initialization">
<t>
The decryption initialization operation has one or two inputs:
<list>
<t>
A secret key K, which MUST match the secret key used in the
corresponding encryption initialization. This input is an octet
string.
</t>
<t>
The reorder tolerance parameter W, a non-negative integer which
indicates the amount of reorder of messages that must be
tolerated. This input is optional; when it is not provided as
an input, the default value of 64 SHOULD be used.
</t>
</list>
The operation has a single output, an AERO decryption context.
</t>
</section>
<section title="Decryption">
<t>
The AERO decryption operation has three inputs, each of which
is an octet string:
<list>
<t>
An AERO decryption context.
</t>
<t>
An octet string C.
</t>
<t>
The associated data A, which contains the data to be
authenticated, but not encrypted. The length of A
MAY be zero.
</t>
</list>
The output is one of these two alternatives:
<list>
<t>
An octet string P and an unsigned integer indicating the
order in which P appeared in the sequence of plaintexts
input to the send algorithm, or
</t>
<t>
The symbol FAIL, which indicates that either the value C was not
output by the send algorithm, or that (A, C) matches a
previously accepted pair of values.
</t>
</list>
</t>
</section>
<section anchor="ms" title="Multiple senders and multiple receivers">
<t>
A communications security protocol may have multiple senders
(encrypters) as well as multiple receivers (decrypters). A single
AERO key MAY be used by multiple senders, in which case each
sender MUST use a distinct AERO encryption context.
</t>
<t>
When multiple AERO encryption contexts are in use for a single
key, a receiver must use a distinct AERO decryption context to
process the messages encrypted with each distinct encryption
context. That is, the receiver maintains a decryption context for
each sender. This matches the conventional practice of
communication security protocols, in which the receiver maintains
a distinct security association for each sender.
</t>
<t>
When processing a protected message, a receiver needs to select
the appropriate AERO context to use in processing that message.
Thus, each protected message must be associated with some
indication of its sender. We call a field that contains this
indication a Sender IDentifier (SID).
</t>
<t>
When there are multiple senders, the values of the associated data
input to the encryption algorithm for different senders SHOULD be
distinct. This practice ensures that no two messages are
identical, and that fact ensures that the AERO system provides
strong confidentiality. An easy way to ensure the distinctness of
Associated Data values is to include an SID in those values. For
example, this requirement is met if the associated data includes a
message header, and that header contains a field that identifies
the sender of the message. Alternatively, the value of the
plaintext can be distinct for each sender, for instance, if each
plaintext includes an SID.
</t>
<t>
If senders accidentally use the same SID value, the security of
the session will degrade, but not catastrophically. See
section <xref target="mssecurity"/> for more details.
</t>
</section>
<section title="AEAD interface">
<t>
AERO can be used through the IETF standard interface for
authenticated encryption with associated data <xref
target="RFC5116"/>. As AERO does not use a nonce or
initialization vector, N_MAX = N_MIN = 0, and the application
using the AEAD interface need not provide a nonce. Note that most
of the usage guidance in RFC 5116 describes stipulations and
cautions on the use of the nonces, so by eliminating the need for
a nonce, AERO is simplifying the use of this standard.
</t>
</section>
</section>
<section anchor="implementation" title="Implementation">
<t>
AERO makes use of a technique that combines message authentication
with replay protection, in which the sender maintains a sequence
number, and the encrypted value of this sequence number is
communicated to the receiver. When the receiver decrypts a message,
it parses out the data that would be equal to a sequence number if the
message was sent by a legitimate sender, and verifies that this data
is sensible. This data is called a candidate sequence number, and is
denoted as Z; the verification process is detailed below. If the data
is not sensible, then the decryption algorithm rejects the message.
The technique provides authenticity because Z is a pseudorandom
function of both the ciphertext and associated data, and in a forgery
attempt, Z will be rejected with overwhelming probability.
</t>
<t>
AERO is a stateful encryption method. It makes use of an underlying
stateless encryption method; the interface to this method is defined
below. This interface allows an AERO implementation to separate out
the authentication and replay protection logic from the cryptographic
algorithms that provide pseudorandomness. The interface also
facilitates the use of different cryptographic techniques, thus
allowing algorithm agility.
</t>
<t>
The stateless encryption algorithm takes as input a secret key K, a
plaintext P, a T-bit unsigned integer S, and an associated data A, and
returns a ciphertext C. Here K, A, P, and C are all octet
strings.
</t>
<t>
The stateless decryption algorithm takes as input a secret key K, a
ciphertext C, and an associated data A, and returns a plaintext P and
a T-bit unsigned integer U.
</t>
<t>
The stateless encryption algorithm may not be able to encrypt
plaintexts that are shorter than a certain minimum value, so
plaintexts are lengthend with the "pad" routine prior to encryption,
and padding is removed after decryption with the "strip" routine.
We denote as PMIN the minimum number of bytes in a plaintext that
the stateful encryption algorithm can accept.
</t>
<t>
Note that the stateless encryption provides only confidentiality, and not
authenticity.
</t>
<section title="Contexts">
<t>
An encryption context includes a T-bit unsigned integer that holds the
sequence number S.
</t>
<t>
A decryption context includes a W-bit bitmask M and two T-bit unsigned
integers S and R, which record the highest candidate sequence number
that has been accepted, and the last candidate sequence number that
has been rejected, respectively.
</t>
</section>
<section title="Encryption Initialization">
<t>
The encryption initialization operation does the following:
<list style="numbers">
<t>
S is initialized to zero.
</t>
<t>
The value of the secret key K is stored in the context.
</t>
</list>
</t>
</section>
<section title="Encryption">
<t>
To encrypt a message (A, P), the following steps are performed:
<list style="numbers">
<t>
The current sequence number S is read from the context. If S
is greater than 2^T - 1, then the context cannot be used to
encrypt any messages, so an indication of this error state is
returned and the encryption processing halts. Otherwise,
processing continues as follows.
</t>
<t>
U is set to the value of a S converted from an unsigned integer
to an octet string using the Integer to String (I2S) routine
described in <xref target="notation"/>.
</t>
<t>
If PMIN * 8 > T, then P is lengthened by appending a padding
string PS to it, to ensure that
L = len(P) + len(PS) + T is at
least 128. The value of PS is as follows:
<figure>
<artwork>
PS = 00 if len(P) + T >= 120,
PS = 0101 if len(P) + T = 112,
PS = 020202 if len(P) + T = 104,
PS = 03030303 if len(P) + T = 96,
PS = 0404040404 if len(P) + T = 88,
PS = 050505050505 if len(P) + T = 80,
PS = 06060606060606 if len(P) + T = 72,
PS = 0707070707070707 if len(P) + T = 64,
PS = 080808080808080808 if len(P) + T = 56,
PS = 09090909090909090909 if len(P) + T = 48,
PS = 0A0A0A0A0A0A0A0A0A0A0A if len(P) + T = 40,
PS = 0B0B0B0B0B0B0B0B0B0B0B0B if len(P) + T = 32,
PS = 0C0C0C0C0C0C0C0C0C0C0C0C0C if len(P) + T = 24,
PS = 0D0D0D0D0D0D0D0D0D0D0D0D0D0D if len(P) + T = 16,
PS = 0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E if len(P) + T = 8.
</artwork>
</figure>
Note that padding MUST be appended to the plaintext if
PMIN * 8 > T, and otherwise padding MUST NOT
be used. As the parameter T is fixed for each particular key,
either all of the messages processed by a particular key will use
padding, or all will not.
</t>
<t>
The stateless encryption algorithm is applied to U, P, and A,
using the secret key from the context.
</t>
<t>
The sequence number in the context is incremented by one.
</t>
<t>
The ciphertext C resulting from the stateless encryption algorithm is
returned.
</t>
</list>
</t>
<t>
<figure anchor="aero-enc" title="An illustration of the AERO encryption process.">
<artwork>
A P
+----|------|------------------+
| | | |
| | | +------+ |
| | | | | |
| | | v +----+ |
| | | S ->| +1 | |
| | | | +----+ |
| | v v |
| | +-----+ +-----+ | AERO
| | | pad | | I2S | | encryption
| | +-----+ +-----+ |
| | | | |
| v v v |
| +------------------+ |
K ---->| stateless | |
| | encryption | |
| +------------------+ |
| | |
+-----------|------------------+
v
C
</artwork>
</figure>
</t>
</section>
<section title="Decryption Initialization">
<t>
During the decryption initialization process,
<list style="numbers">
<t>
S is initialized to the reorder tolerance parameter W,
</t>
<t>
R is initialized to 2^T - 1, and
</t>
<t>
the bitmask M is initialized to the all-zero value.
</t>
</list>
</t>
</section>
<section title="Decryption">
<t>
To decrypt an encrypted message (A, C),
<list style="numbers">
<t>
The stateless decryption algorithm is applied to A and C, using
the secret key K in the context, returning a candidate sequence
number Z, which is a T-bit unsigned integer, and a plaintext Q,
which is an octet string.
</t>
<t>
If PMIN * 8 > T, then padding is removed from Q as follows. B is
set to the value of the last octet of Q, converted to an 8-bit
unsigned integer. If B > (128 - T)/8, then the FAIL symbol is
returned, and processing halts. Otherwise, the octet string P is
set to all but the final B + 1 octets of Q.
</t>
<t>
Z is converted from an octet string to an unsigned integer
using the S2I routine defined in <xref target="notation"/>.
</t>
<t>
Z is processed as follows; see <xref target="csn"/> for an
illustration.
<list>
<t>
If Z is between 0 and S-W, inclusive, then Z is rejected.
</t>
<t>
If Z is between S-W+1 and S, inclusive, then the bitmask M
is checked. If M[S-Z] = 0, then Z is accepted, M[S-Z] is
set to 1, and P is returned as the plaintext. If M[S-Z] =
1, then Z is rejected.
</t>
<t>
If Z is between S+1 and S+W, inclusive, then Z is accepted,
S is set to Z, and P is returned as the plaintext. The
bitmask is shifted by Z-S (in the direction of higher indicies).
</t>
<t>
If Z is between S+W+1 and R, inclusive, then
Z is rejected and R is set to Z.
</t>
<t>
If Z is between R+1 and R+V, inclusive, then Z is accepted,
S is set to Z, the bitmask M is set to the all-zero value,
and P is returned as the plaintext.
</t>
<t>
If Z is between R+V+1 and 2^T+1, inclusive, then Z is rejected and
R is set to Z.
</t>
</list>
</t>
<t>
When Z is rejected, then AERO decryption MUST return the FAIL symbol,
which indicates that either the message was a replay or a forgery
attempt.
</t>
</list>
</t>
<t>
<figure anchor="aero-dec" title="An illustration of the AERO decryption process.">
<artwork><![CDATA[
A C
+------|-------|--------------+
| v v |
| +-------------+ |
K ---->| stateless | |
| | decryption | |
| +-------------+ |
| | | |
| v v |
| +-----+ +-----+ |
| |strip| | S2I | |
| +-----+ +-----+ | AERO
| | | | decryption
| v v |
| P Z |
| | |
| v |
| +-------------+ |
| S-->| check |<--R |
| ^ +-------------+ ^ |
| | | | | |
| +----------+ +----------+ |
| | accept | | reject | |
| +----------+ +----------+ |
| | | |
+--------|-----------|--------+
v v
P (or) FAIL
]]></artwork>
</figure>
</t>
<t>
<figure anchor="csn" title="An illustration of how the candidate
sequence number Z is processed during AERO decryption. The possible
values of Z are shown on a number line from 0 to 2^T-1. S and
R are taken from the decryption context, the region into which
Z falls determines how that value is processed. The acceptance region between
R and R+V provides resynchronization as described in Section 6.">
<artwork>
check reject reject
bitmask and and
| set R to Z set R to Z
reject | accept | accept |
| | | | | |
v v v v v v
+---------+----+----+----------------+---+----------------+-> Z
| | | | | | |
0 S-W S S+W R R+V 2^T-1
</artwork>
</figure>
</t>
</section>
</section>
<section anchor="stateless" title="Stateless encryption algorithms">
<section anchor="wprp" title="Wide PRP (WPRP)">
<t>
An Pseudo-Random Permutation (PRP) is a keyed function that is both
invertible and pseudorandom; that is, when the key is chosen at
random, an attacker cannot distinguish it from an invertible function
selected at random. For instance, a block cipher is a PRP with a
fixed length (and narrow) input and output.
</t>
<t>
An encryption algorithm that accepts plaintexts that have varying
lengths can also be a PRP. This type of algorithm is called a Wide
Pseudo-Random Permutation (WPRP), because the inputs can be wider than
those of a typical block cipher. For our purposes, the WPRP must also
accept an associated data input. For each distinct value of the
associated data, the WPRP must realize a distinct pseudorandom
function. Informally, for each distinct value of A, the
WPRP "looks like" a distinct PRP.
</t>
<t>
A WPRP is used as the underlying stateful encryption encryption method
as follows. To encrypt an associated data A, a plaintext P, and a
sequence number U with a secret key K, first U is appended to P,
and the WPRP encryption is performed with the key K, the associated
data A, and the plaintext Q = P || U resulting from the concatenation
of P and U. The output of the WPRP encryption is returned as the
ciphertext. This process is shown in <xref target="aero-wprp-enc"/>.
</t>
<!--
<t>
The Pad function works as follows.
<list>
<t>
If T
</t>
</list>
</t>
-->
<t>
<figure anchor="aero-wprp-enc" title="Using a WPRP as a stateless encryption method in AERO.">
<artwork>
A P U
+------|-----|----|-----+
| | | | |
| | v v |
| | +--------+ |
| | | append | |
| | +--------+ | stateless
| | | | encryption
| | v |
| | Q |
| | | |
| v v |
| +-----------------+ |
K ---->| WPRP encryption | |
| +-----------------+ |
| | |
+-----------|-----------+
v
C
</artwork>
</figure>
</t>
<t>
To decrypt a ciphertext C with associated data A with a secret key K,
first the WPRP decryption is applied to C, using the key K. Then the
resulting output Q is split into two separate octet strings. The
final T bits of the output is returned as U, and the initial len(Q) - T
bits of Q are returned as P.
This process is shown in <xref target="aero-wprp-dec"/>.
</t>
<t>
<figure anchor="aero-wprp-dec" title="Using
a WPRP as a stateless decryption method in AERO.">
<artwork>
A C
+------|-------|--------+
| | | |
| | | |
| v v |
| +-----------------+ |
K ---->| WPRP decryption | |
| +-----------------+ |
| | |
| v |
| Q | stateless
| | | decryption
| v |
| +-------+ |
| | split | |
| +-------+ |
| | | |
+-----------|-----|-----+
v v
P U
</artwork>
</figure>
</t>
<t>
A WPRP has the property that each bit of its output is a pseudorandom
function of each bit of both of its inputs, for both encryption and
decryption. A WPRP is very well suited for use in AERO. The fact
that encryption is a WPRP, combined with the use of a sequence number,
ensures strong confidentiality of the plaintext. The fact that the
decryption algorithm is a WPRP ensures that an attacker cannot predict
(much less control) the candidate sequence number, thus ensuring
strong integrity, authenticity, and replay protection.
</t>
<t>
WPRPs are used in disk-block encryption <xref target="1619.2"/>,
because they provide the best security possible in scenarios where the
ciphertext cannot be any longer than the plaintext.
<!--
One such WPRP is
the XCB mode of operation; below we define an AERO algorithm based on
that standard <xref target="XCB"/>.
-->
</t>
<t>
When a WPRP algorithm is used as the EAD algorithm in AERO, we call
the resulting combination AERO-WPRP. An AERO-WPRP algorithm has very
strong security properties, as described in <xref target="security"/>.
</t>
<!--
<section anchor="XCB" title="AERO-AES-XCB">
<t>
The Advanced Encryption Standard (AES) eXtended Code Book (XCB) mode
of operation, or AES-XCB <xref target="MF07"/>, is a WPRP that was
standardized in the IEEE <xref target="1619.2"/>. Below we define
AERO-AES-128-XCB and AERO-AES-256-XCB, which utilize that standard.
Test cases are provided in <xref target="test"/>. AES-XCB can encrypt
only plaintexts that are at least PMIN = 16 bytes long, so padding
MUST be used whenever the length T of the sequence number is less than
128 bits.
</t>
<t>
AERO_AES_128_XCB uses AES with a 128 bit key in the XCB mode of
operation as the underlying stateless encryption method in AERO.
XCB is a WPRP, so the processing is performed as described in <xref
target="wprp"/>.
</t>
<t>
AERO_AES_192_XCB uses AES with a 192 bit key in the XCB mode of
operation as the underlying stateless encryption method, as
described in <xref target="wprp"/>.
</t>
<t>
AERO_AES_256_XCB uses AES with a 256 bit key in the XCB mode of
operation as the underlying stateless encryption method, as
described in <xref target="wprp"/>.
</t>
</section>
-->
<section title="WPRP Requirements and survey">
<t>
There are many WPRP designs in the cryptographic literature, driven
largely by interest in disk-block encryption. However, AERO has some
requirements that are different from those of disk-block encryption.
Most importantly, the WPRP encryption algorithm must be able to
process plaintexts that vary in length, using a single key. (In
contrast, all of the blocks in a disk typically have the same length,
allowing a WPRP design to be optimized for a fixed size.)
</t>
<t>
The Advanced Encryption Standard (AES) eXtended Code Book (XCB) mode
of operation, or AES-XCB <xref target="MF07"/>, is a WPRP that can
accept plaintexts with lengths of 16 bytes or higher. Internally, it
roughly consists of a layer of hashing, followed by a layer of counter
mode, followed by another layer of hashing, with a small amount of
additional processing. It was first introduced in 2004, and a second
version was introduced in 2007, and was standardized in the IEEE <xref
target="1619.2"/>. Recent work has raised questions about the
security of the second version when used in scenarios in which the
lengths of the plaintexts vary, which would make it inappropriate for
AERO.
</t>
<t>
Chakraborty and Sarkar presented HCH, an improved hash-couter-hash
WPRP mode of operation in 2007, which reduces the amount of additional
processing and improves the security bound, so that more data can be
securely encrypted for a fixed key <xref target="CS07"/>.
</t>
<t>
Sarkar introduced yet another improvement in WPRPs in 2007, presenting
a mode of operation based on a hash-encrypt-hash design <xref
target="S07"/>.
</t>
<t>
Other designs have been put forward as well. When considering an appropriate WPRP,
the following criteria will be important:
<list>
<t>
the computational cost should be as low as possible,
</t>
</list>
</t>
</section>
</section>
<section anchor="other" title="Other cryptographic techniques">
<t>
Using a Wide PRP in AERO provides very strong security. However, it
is more computationally expensive than some other approaches. Thus,
it may be useful to use other techniques that trade some
well-understood reduction in security properties for lessened
computational cost. We do not define any such techniques in this
note, but we outline the tradeoffs that are possible.
</t>
<t>
AEAD algorithms fit into two distinct categories: online and
offline. With an online encryption algorithm, the ith ciphertext
block can be output before the (i+1)st plaintext block has to be
read (where a block is the size of the data blocks processed by a
block cipher, typically) . These algorithms make a single pass over
the data, and implementations need not buffer a significant amount
of state. In contrast, with an offline encryption algorithm the
entire plaintext must be read in before the first block of
ciphertext can be output. Such algorithms must store state equal in
length to the plaintext or ciphertext that they are processing. In
a software environment, an offline algorithm is acceptable, as long
it processes only plaintexts with lengths are short enough that
they fit into high-speed random access memory. However,
offline algorithms cannot be implemented in a hardware pipeline,
such as those used in high-speed network encryption (for
protocols such as 802.1AE).
</t>
<t>
A WPRP is necessarily an offline algorithm. However, an online
algorithm can implement a weakened variant of a WPRP: an Online
Pseudo-Random Permutation (OPRP). An online permutation is a
length-preserving permutation such that the ith block of output
depends only on the first i blocks of input, for all values of i.
An OPRP is an keyed online permutation that a computationally
limited attacker cannot distinguish from an online permutation
chosen uniformly at random from the set of all online permutations.
With an OPRP, an attacker will be able to recognize when two
messages with common plaintext prefixes are encrypted with the same
key, since the ciphertext prefixes will be identical.
</t>
<t>
There are OPRPs in the cryptographic literature that are suitable for
use in AERO, such as the Pipelineable Online Encryption (POE) mode of
operation <xref target="AFFFLMW14"/>, or the McOE-G <xref
target="FFLW11"/> family of online authenticated encryption algorithms
of Fleischmann, Forler, Lucks, and Wenzel.
<!--
The design, selection, and standardization of such schemes
would be valuable work, but it is beyond the scope of this note.
-->
</t>
<!--
<t>
Bellare and Namprempre showed in that IND-CCA-security implies non-
malleable chosen-ciphertext -security (NM-CCA) <xref
target="BN00"/>. Hence, OPERM-CCA implies weak non-malleability, i.e.,
an adversary that manipulates the i-th ciphertext block cannot
distinguish the (i+1)-st, (i+2)-nd, etc. ciphertext blocks from
random. Thus, it suffices to show the OPERM-CCA-security to obtain
non-malleability.
</t>
-->
<t>
There are offline ciphers that are more efficient that WPRPs, such as
the Synthetic Initialization Vector (SIV) mode of operation of Rogaway
and Shrimpton <xref target="RFC5297"/>. SIV encryption makes two
passes over the plaintext, first to compute a Message Authentication
Code (MAC) of that plaintext, the second to encrypt the plaintext
using counter mode, using the MAC as the initialization vector for the
encryption process. This two-pass encryption approach can be adapted
for use in AERO, by having the IV computed by the tweakable encryption
of the sequence number, using the MAC as the tweak. Such a mode of
operation could be computationally less costly than a WPRP, but would
also lack some of the misuse-resistance properties of a WPRP.
</t>
<!--
<t> A WPRP provides protection against decryption misuse. If the
post-decryption plaintext is released by the decrypter prior to the
authentication check being complete, the attacker cannot learn any
useful information from this fact, because the post-decryption
plaintext is a pseudorandom function of the ciphertext and associated
data. If an application does not require decryption misuse, then it
can us </t>
-->
</section>
<!--
<section anchor="SIV" title="Encrypted Sequence Number (ESN) mode of operation">
<t>
In this section, we describe the Encrypted Sequence Number (ESN)
block cipher mode of operation, which is less computationally
expensive than the Wide PRP approach. To gain that advantage, it
gives up decryption misuse resistance.
</t>
<t>
The block cipher encryption of an octet string X with key K is
denoted as ENC(K, X). The decryption of X with key K is denoted as
DEC(K, X). The concatenation of two octet strings X and Y is
denoted as X || Y. The counter mode encryption of a string Y, using
initialization vector X and key K, is denoted as CTR(K, X, Y).
</t>
<t>
In the following, we denote the number of bits in the block cipher
inputs and outputs as L, and the number of bits in the sequence
number as T. Given these two parameters, the smallest plaintext
that can be encrypted without padding is PMIN = (L-T)/8 bytes long.
</t>
<t>
ESN encryption takes as input a T-bit octet string S, which contains
the sequence number, a plaintext P, and an associated data A, as
well as a secret key K, and returns a ciphertext C. If PMIN > 0, P
MUST be padded as described in <xref target="padding"/>.
</t>
<t>
To encrypt a plaintext message (A, P) using sequence number S and
key K, the following (or any equivalent) steps are performed:
<list>
<t>
H is set to END(K, 0^128).
</t>
<t>
PP is set to the initial L-T bits of P.
</t>
<t>
PS is set to the final len(P) - (L-T) bits of P.
</t>
<t>
X is set to GHASH(H, A, PS).
</t>
<t>
Y is set to S || PP.
</t>
<t>
IV is set to ENC(K, X XOR Y).
</t>
<t>
CS is set to CTR(K, IV, PS).
</t>
<t>
C is set to IV || CS, and is returned as the
output of the encryption process.
</t>
</list>
Here and below, H, PP, PS, X, Y, IV, and CS are octet strings.
</t>
<t>
To decrypt a ciphertext message (C, P) using key K, the following
(or any equivalent) steps are performed:
<list>
<t>
IV is set to the initial L bits of C.
</t>
<t>
CS is set to the final len(C)-L bits of C.
</t>
<t>
PS is set to CTR(K, IV, CS).
</t>
<t>
H is set to E(K, 0^128).
</t>
<t>
X is set to GHASH(H, A, PS).
</t>
<t>
Y is set to DEC(K, IV) XOR X.
</t>
<t>
S is set to the initial T bits of Y.
</t>
<t>
PP is set to the final L-T bits of Y.
</t>
<t>
P is set to PP || PS and is returned as the output.
</t>
</list>
</t>
<t>
ESN is in some ways similar to the the Synthetic Initialization
Vector (SIV) mode of operation of Rogaway and Shrimpton. SIV is an
authenticated encryption method in which an authentication tag,
computed using the CBC-MAC message authentication code applied to
the associated data and plaintext, also serves as the IV for the
counter mode encryption of the plaintext.
</t>
</section>
-->
</section>
<section anchor="synch" title="Loss, reorder, and resynchronization">
<t>
AERO relies on the synchronization of the sequence number S between
the sender (encryption algorithm) and the receiver (decryption
algorithm). If those values differ by more than W, then we say that
the sender and receiver are desynchronized; if this occurs, then it is
likely that the decryption algorithm will discard at least one
legitimate message that it receives. Desynchronization will occur
whenever W+1 or more messages are lost by the communication channel
between the sender and the receiver.
</t>
<t>
When initializing an AERO decryption context, the reorder tolerance
parameter W should be set to a value that is larger than the message
reorder of the communication channel in use. However, values of W
larger than 256 are discouraged for security reasons; see <xref
target="security"/>. The default value of W=64 is recommended when
AERO ciphertext messages are carried over an unreliable transport
protocol. When they are carried over a reliable transport protocol,
W=1 is recommended.
</t>
<t>
Resynchronization occurs automatically in AERO, because of the
processing of candidate sequence numbers between R+1 and R+V. If a
burst of exactly J messages that are lost, where J > W+1, then the
receiver will reject the first message received immediately after the
burst of lost messages, and will set R to the value of the current
sequence number S of the sender. The candidate sequence number of the
next message received will fall into the region between R+1 and R+V,
since R=S and the candidate sequence number is S+1. Thus, after a
burst of J > W lost packets, resynchronization is obtained after the
spurious rejection of a single packet.
</t>
<t>
Most applications can accept the induced loss of a single message in
situations where J > W or more messages have been lost, since this
corresponds to an increase in packet loss less than 2% when the
recommended value of W=64 is used. However, an application MAY choose
to cache a rejected message (A, C) and re-submit it to the AERO
decryption algorithm if it appears to have been spuriously rejected
during the resynchronization process, to eliminate the induced message
loss. An application can do this without any need for special
processing from an AERO implementation.
</t>
<t>
When there are multiple receivers, it may be the case that one of the
receivers is a "late joiner" that does not receive the initial
messages sent in a session, because it joined that session some time
after it began. The automatic resynchronization described above will
enable a late joiner to synchronize with the sender after a single
spurious rejection of a valid message. If an application protocol is
designed to allow a late joiner in a session, it is likely that the
application can tolerate this one spurious rejection as the cost of
achieving synchronization without external coordination of state.
</t>
<t>
The one free parameter in an AERO implementation is the number T of
bits in the sequence number. This parameter determines the strength
of the authentication provided, as well as the number of messages that
can be encrypted by a particular sender using a particular key.
Securty is the main consideration in the selection of this parameter;
this topic is covered in <xref target="authstrength"/>.
</t>
</section>
<section anchor="usage" title="Usage and applicability">
<t>
AERO addresses several outstanding issues in cryptography as it is
used for communication security. It is especially well suited for
scenarios where there are bandwidth constrains or high costs
associated with transmission and reception, as well as scenarios in
which multiple senders or multiple receivers share an encryption
key. It is also suitable for use when misuse resistance is
desirable.
</t>
<t>
AERO always detects replayed messages, as is expected of a replay
protection service, but AERO may reject a message because it does
not have all of the stored state that it needs in able to
authoritatively determine that the message is not a replay. In this
way, it matches the conventional practice of replay protection using
sequence numbers.
</t>
<t>
The sequence number output by the decryption algorithm can be used
by the application calling AERO to put the decrypted plaintexts into
their correct order. Some applications will not need this
information, because they can rely on information in the associated
data or plaintext to get information about the ordering of messages,
or because they do not need to process the messages in order.
</t>
<t>
When AERO ciphertext messages are carried above a reliable transport
protocol such as TCP or SCCP, the reorder tolerance parameter W can
be set to one and the resynchronization parameter V can be set to
zero. This has the effect of improving the strength of the
authentication that is provided.
</t>
<t>
AERO-WPRP should be used, unless it is not possible to buffer the
entire plaintext or ciphertext in memory during the encryption and
decryption processes, in which case an AERO-OPRP would be more
appropriate. Currently, there are no OPRP algorithms that can be
implemented in an efficient pipeline, as is done with other AEAD
algorithms such as AES-GCM, so this is an area of ongoing work.
</t>
</section>
<!--
<section title="Overview">
<t>
A communication security protocol provides a way for a sender and
receiver that share a secret key to communicate securely over an
untrusted communication channel. In a packet-oriented
communication security protocol, an ordered sequence of
finite-length messages are input to the protocol on the sender
side, and an ordered sequence of messages is output on the other
receiver side; there may be more than one receiver, in which case
each receiver has their own sequence of output messages. Each
message consists of a pair of octet strings: a plaintext, and an
associated data value. Communication security is provided by a
protect algorithm, by which the sender prepares input messages to
be sent across the untrusted channel, and an unprotect algoritm, by
which a receiver processes the protected messages that have been
received.
</t>
<t>
The security model is detailed in <xref target="security"/>; it
allows the attacker to control the communications channel, and to
drop, to read, to edit, to copy, and to duplicate messages at will,
and to submit chosen plaintext/associated data pairs. The security
goals are:
<list>
<t>
confidentiality: the attacker does not learn anything about
the protected plaintexts.
</t>
<t>
message authenticity: each message returned by the unprotect
algorithm is identical to a message input to the protect
algorithm.
</t>
<t>
replay protection: a protected message will be accepted by the
unprotect algorithm only once.
</t>
<t>
sequence authenticity: the unprotect algorithm indicates the
correct position of the message in the sequence of all of the
messages that were input to the protect algorithm.
</t>
</list>
The protect algorithm takes as input a plaintext string and an
associated data string, and it returns a ciphertext string. The
unprotect algorithm takes as input a ciphertext string and
associated data string, and returns either the symbol FAIL, or a
plaintext string and a sequence number. The sequence number is an
unsigned integer that indicates the position of the plaintext
string in the sequence of plaintext strings that were processed by
the sender.
</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 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>
AES-XCB was chosen as it provides suitable security and performance,
and it is a standard. In the future, stateless encryption algorithms
with performance or security benefits over AES-XCB may be developed,
but it is essential to specify a particular algorithm in this note, in
order to gain experience in the implementation and use of AERO.
</t>
<t>
It is unfortunate, but unavoidable, that the plaintext must be padded.
It is unfortunate because of the slight additional overhead and
implementation complexity. It is unavoidable because there is no
efficient way to encrypt fewer than b bytes of plaintext using a block
cipher with a b-byte block, in a way that meets the security needs of
AERO. Also, there are not (yet) any dedicated encryption algorithms
that are suitable.
</t>
<t>
The padding and pad-stripping operations are included in the AERO
encryption and decryption algorithms, respectively, because the
pad-stripping operation also incorporates an authentication check.
This arrangement simplifies the stateless encryption algorithm, and
also ensures that more algorithms can be used as stateless
encryption methods.
</t>
<t>
Incorporating the sequence number generation inside of AERO has the
advantage of putting that security-critical operation inside of the
cryptographic module, which often benefits from higher assurance
than other system components, including testing, as
observed by Sections 5 and 6 of <xref target="IV-GEN"/>.
</t>
</section>
<section anchor="test" title="Testing">
<t>
In the typical case in which the underlying stateless encryption
algorithm is deterministic, both AERO encryption and AERO decryption
are deterministic. This makes it possible to use test cases for all
of the operations supported by an AERO algorithm.
</t>
<!--
<t>
In this section we provide test cases for the AERO AES-XCB algorithm
defined above.
</t>
<section title="AERO_AES_128_XCB">
<t>
Test Case 1
<figure> <artwork>
K: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
P: 01 02 03 04 05 06
A: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
U: 00 00 00 00 00 00 00 01
PS: 01 01
Q: 01 02 03 04 05 06 01 01 00 00 00 00 00 00 00 01
C: 23 e0 61 3f 18 07 d4 55 64 71 8d 72 9e fc 3d 46
</artwork></figure>
</t>
<t>
Test Case 2
<figure> <artwork>
K: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
P: 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00
A: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
U: ff 00 00 00 0f 0e 0c 0b
PS: 00
Q: 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00
00 ff 00 00 00 0f 0e 0c 0b
C: e3 82 08 73 ff 55 20 6a 95 a5 83 2e a8 e4 c2 fd
ee 96 ef b0 30 e1 fd cd 6f
</artwork></figure>
</t>
</section>
-->
<!--
<section title="AERO_AES_192_XCB">
<figure> <artwork>
KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
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
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
C = .. .. .. .. ..
</artwork></figure>
</section>
<section title="AERO_AES_256_XCB">
<figure> <artwork>
KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
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
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
C = .. .. .. .. ..
</artwork></figure>
</section>
-->
</section>
<section anchor="iana" title="IANA Considerations">
<t>The Internet Assigned Numbers Authority (IANA) has defined
the AERO algorithm registry described below. An algorithm designer MAY
register an algorithm in order to facilitate its
use. Additions to the AERO algorithm registry require that a
specification be documented in an Internet RFC or another
permanent and readily available reference, in sufficient detail
that interoperability between independent implementations is
possible. Each entry in the registry contains the following
elements: <list>
<t>a short name, such as "AERO_AES_128_XCB", that starts
with the string "AERO",</t>
<t>a positive number, and</t>
<t>a reference to a specification that completely defines an AERO
algorithm and provides test cases that can be used to verify the
correctness of an implementation.</t>
</list>
Requests to add an entry to the registry MUST include the name
and the reference. The number is assigned by IANA. These
number assignments SHOULD use the smallest available positive
number. Submitters SHOULD have their requests reviewed by the
IRTF Crypto Forum Research Group (CFRG) at cfrg@ietf.org.
Interested applicants that are unfamiliar with IANA processes
should visit http://www.iana.org.
</t>
<t>
The numbers between 32,768 (binary 1000000000000000) and
65,535 (binary 1111111111111111) inclusive, will not be
assigned by IANA, and are reserved for private use; no attempt
will be made to prevent multiple sites from using the same
value in different (and incompatible) ways <xref
target="RFC2434"/>.
</t>
<!--
<t>IANA will add the following entries to the AERO algorithm registry:
</t>
<texttable>
<ttcol align="left">Name</ttcol>
<ttcol align="center">Reference</ttcol>
<ttcol align="center">Numeric Identifier</ttcol>
<c>AERO_AES_128_XCB</c>
<c><xref target="XCB"></xref></c>
<c>1</c>
<c>AERO_AES_192_XCB</c>
<c><xref target="XCB"></xref></c>
<c>2</c>
<c>AERO_AES_256_XCB</c>
<c><xref target="XCB"></xref></c>
<c>3</c>
</texttable>
-->
<t>
An IANA registration of an AERO algorithm does not constitute
an endorsement of that algorithm or its security.
</t>
</section>
<section anchor="security" title="Security considerations">
<t>
There are three AERO security services: confidentiality, message
authentication, and replay protection. We consider those services in
that order. We use a simplistic but realistic model in which
pseudorandom values are treated as random values.
</t>
<t>A more precise analysis would define the advantage that an
adversary has in distinguishing the pseudorandom output of the
stateless encryption algorithm from a truly random value, then
quantify an attacker's advantage at forging AERO messages or
distinguishing the output of the decryption algorithm from random, and
then show that the attacker's advantage against AERO is negligibly
small as long as the advantage against the stateless encryption
algorithm is negligibly small. However, such a detailed analysis is
beyond the scope of this note.
</t>
<t>
Below we sketch out a formal security analysis for AERO, using the
conventional definition of advantage as the absolute value of the
difference between the probability that a distinguisher will have a
true positive and the probability that it will have a false positive.
AERO is secure in the following model, which captures the idea of a
very strong adversary. The attacker is assumed to be able to
adaptively choose plaintext messages (A, P) and ciphertext messages
(A, C), and obtain the corresponding ciphertext and plaintext
messages.
</t>
<t>
Assume that there is an attack that can distinguish AERO from a
randomly chosen function with the same domain and range. Then we can
use this attack to build a distinguisher that can tell the underlying
stateless encryption function from a truly random function, as
follows. Given access to an oracle that is either the stateless
encryption function with a randomly chosen secret key, or is a truly
random function, we use that oracle to construct an AERO instance. We
then run the AERO-distinguishing attack against that AERO instance,
responding to the the queries made by the attack by constructing the
appropriate AERO queries. If the attack returns a guess of "AERO",
then we return a guess of "not random". Otherwise, return a guess of
"random". This attack on the underlying encryption functions works
with essentially the same advantage as the attack on AERO.
</t>
<t>
Similarly, if there is an attack that can forge AERO messages with
probability significantly greater than 1/2^T' (where T' is the
effective authentication tag length defined below), then we can use
that attack to build a distinguisher that can tell the underlying
stateless encryption function from a truly random function, as
follows. Given access to an oracle that is either the stateless
encryption function with a randomly chosen secret key, or is a truly
random function, we use that oracle to construct an AERO instance. We
then run the forgery attack against that AERO instance, responding to
the queries made by the attack by constructing the appropriate AERO
queries. If the attack against AERO succeeds in making a forgery,
then we return a guess of "not random". Otherwise, return a guess of
"random". This distinguishing attack works with advantage P - 1/2^T',
where P is the probability that the AERO-forgery attack will succeed
in a forgery attempt.
</t>
<t>
AERO is a stateful authenticated encryption method. Bellare, Kohno,
and Namprempre have studied the security of stateful encrption and
decryption in the context of the Secure Shell (SSH) protocol <xref
target="BKN04"/>.
</t>
<section title="Authentication and confidentiality">
<t>
The confidentiality properties of AERO follow directly from that of
the stateless encryption algorithm that it incorporates. When a WPRP
is used, each WPRP plaintext will be distinct, because of the
uniqueness of the sequence numbers. This fact ensures the
indistinguishability of AERO encryption from a random function, and
thus the strength of the confidentiality that it provides.
</t>
<t>
AERO decryption can detect forgery attempts in two ways: the
processing of the candidate sequence number, and the strip function
that removes padding from the plaintext.
The candidate sequence number is
a pseudorandom function of both the AERO ciphertext and the AERO
associated data, as is the post-decryption padding string PS.
To an attacker that cannot distinguish the
pseudorandom value from a random one, the probability p that
a forgery attempt will not be detected by the candidate
sequence number processing is
<figure><artwork><![CDATA[
(2*W + V)
p = ------------.
2^T
]]></artwork></figure>
To an attacker that cannot distinguish the post-decryption
value of PS from a random string, the probability ps that
a forgery attempt will pass through the "strip"
function undetected is
<figure><artwork><![CDATA[
(PMIN - T/8)
ps = -------------.
256
]]></artwork></figure>
Thus, the probability that a forgery attempt will
go undetected is 1/2^T', where
<figure><artwork><![CDATA[
T' = T + 8 - lg((2*W + V) - lg(PMIN - T/8))
]]></artwork></figure>
and lg(X) denotes the logarithm base two of X.
<!--
example:
T' = T + 8 - lg(136) - lg(16 - 8)
T' = T - 2.10
prob = (2*W + V)(PMIN - T/8)/((2^T)(256)
= 2^(-T) * (2*W + V)(PMIN - T/8) / 256
prob <= 2^(-T) whenever
(2*W + V)(PMIN - T/8) <= 256
prob = 2^(-T + delta)
delta = lg((2*W + V)(PMIN - T/8)/256)
64,8,16,64: 136 * 8 / 256
* * * * * * *
If B > PMIN - T/8, then FAIL
(PMIN - T/8) accepted values out of 256
W V PMIN T | T' | Overhead
64 8 16 128 | 121.0 | 128 bits
64 8 16 120 | 121.0 | 128 bits
64 8 16 96 | 95.0 | 120
64 8 16 88 | 86.6 | 96
64 8 16 64 | 62.0 | 72
64 8 16 56 | 54.0 | 64
64 8 16 32 | 29.3 | 40
64 8 16 28 | 25.3 | 32
64 8 8 128 | 121.0 | 128
64 8 8 120 | 113.0 | 120
64 8 8 96 | 88.9 | 96
64 8 8 88 | 81.0 | 88
64 8 8 64 | 56.9 | 64
64 8 8 56 | 56.9 | 64
64 8 8 48 | 48.0 | 56
64 8 8 32 | 30.1 | 40
64 8 8 28 | 26.7 | 32
-->
As revealed by the equation above, AERO provides integrity and
authentication protection that is essentially equivalent to an ideal
message authentication code with a tag length of T' which is slightly
less than T. The following table shows T' as a function of T, using
the default values of W=64 and V=8 with PMIN=16, to three significant
figures. The third column shows the number of bits in the data "on
the wire" required by AERO. The final column shows the delta between
the number of bits on the wire and the equivalent tag size T'.
</t>
<texttable>
<ttcol align="right"> T </ttcol>
<ttcol align="right"> T' </ttcol>
<ttcol align="right"> Data size </ttcol>
<ttcol align="right"> Delta </ttcol>
<c> 128 </c><c> 121 </c><c> 128 </c> <c> 7.0 </c>
<c> 120 </c><c> 121 </c><c> 128 </c> <c> 7.0 </c>
<c> 112 </c><c> 112 </c><c> 120 </c> <c> 8.0 </c>
<c> 104 </c><c> 103 </c><c> 112 </c> <c> 9.0 </c>
<c> 96 </c><c> 94.9 </c><c> 104 </c> <c> 9.1 </c>
<c> 88 </c><c> 86.6 </c><c> 96 </c> <c> 9.4 </c>
<c> 72 </c><c> 70.1 </c><c> 80 </c> <c> 9.9 </c>
<c> 64 </c><c> 61.9 </c><c> 72 </c> <c> 10.1 </c>
<c> 56 </c><c> 53.7 </c><c> 64 </c> <c> 10.3 </c>
<c> 48 </c><c> 45.6 </c><c> 56 </c> <c> 10.4 </c>
<c> 40 </c><c> 37.5 </c><c> 48 </c> <c> 10.5 </c>
<c> 32 </c><c> 29.3 </c><c> 40 </c> <c> 10.7 </c>
<c> 28 </c><c> 25.3 </c><c> 32 </c> <c> 6.7 </c>
</texttable>
<t>
The delta values can be considered to be the data overhead inherent in
AERO, that is, the amount of additional data that must be included in
a message in order to provide the replay protection, sequencing
information, and self-synchronization capability. For higher
authentication strengths, this overhead is roughly one byte;
otherwise, it is slightly higher.
</t>
<t>
When AERO is used over a reliable transport protocol, then the reorder
tolerance parameter W SHOULD be set to one, and the resynchronization
parameter V SHOULD be set to zero. When this is done, the delta
values are about 7 bits smaller, and for a given amount of data
overhead, the probability of a successful forgery is smaller by a
factor of about 1/128.
</t>
<section anchor="authstrength" title="Authentication strength">
<t>
As always, stronger authentication, and thus larger values of T',
should be preferred over weaker authentication, and smaller values
of T'. We recommend the use of T' = 121 (with 128 bits on the wire)
whenever possible. When bandwidth is at a premium, it may be
acceptable to use T' = 53.7 (64 bits on the wire).
</t>
<t>
When the plaintext is audio or video data to be converted to an
analog signal and played out of an audio speaker or video monitor,
it may be acceptable to use even weaker authentication, whenever
the consequences of a single forgery are limited to a localized
"glitch" in the audio or video output. In such cases, an
authentication strength of T' = 25.3 (32 bits on the wire) may be
acceptable, but users are cautioned to verify these criteria before
using such weak authentication. With these parameters, the
likelihood of a successful forgery is one in 32 million.
</t>
</section>
<!--
<c> 8 </c><c> 128 </c><c> 121 </c><c> 128 </c> <c> 8 </c><c> 120
</c><c> 113 </c><c> 120 </c> <c> 8 </c><c> 96 </c><c> 88.9 </c><c> 96
</c> <c> 8 </c><c> 88 </c><c> 81.0 </c><c> 88 </c> <c> 8 </c><c> 64
</c><c> 56.9 </c><c> 64 </c> <c> 8 </c><c> 56 </c><c> 56.9 </c><c> 64
</c> <c> 8 </c><c> 48 </c><c> 47.9 </c><c> 56 </c> <c> 8 </c><c> 32
</c><c> 30.9 </c><c> 40 </c> <c> 8 </c><c> 28 </c><c> 26.7 </c><c> 32
</c>
-->
<!--
7
7
<t>
We assume that an attacker submits decryption queries to the ESN
method that are unique. (This assumption does
not limit the capabilities of the attacker, ...
</t>
-->
<!--
<t>
The security of an EAD cipher is determined by the conventional
indistinguishibility model, in which the attacker is given access to
an encryption oracle and a decryption oracle. The oracles are an
interface to a "black box" containing either a truly random EAD
cipher, or a pseudorandom EAD cipher with a randomly chosen key. The
attacker is allowed to choose a set of queries to the encryption
oracle and a set of queries to the decryption oracle. The encryption
queries consist of (associated data, plaintext) pairs, and the
decryption queries consist of (associated data, ciphertext) pairs.
The encryption oracle returns a ciphertext string, and the decryption
oracle returns a plaintext string.
</t>
<t>
A truly random EAD cipher would
determined by the attacker's
advantage Adv, which is defined as
</t>
<t>
Adv = P[ A | B ] - P[ A | C ]
</t>
-->
</section>
<section title="Length hiding">
<t>
In some applications, it is desirable to hide the length of the
plaintext from an attacker, in order to prevent the attacker from
being able to make inferences about the plaintext based on those
lengths. The plaintext padding scheme defined in this note is not
suitable for this purpose and it MUST NOT be used as such. An
application that seeks to hide plaintext lengths should instead
process the plaintexts with a fragmentation and encoding scheme
prior to encrypting them. Schemes of this sort are out of scope of
this note.
</t>
</section>
<section title="Denial of Service (DoS)">
<t>
An attacker can potentially flood a communications channel with a
set of bogus ciphertext messages in order to consume the
computational resources of the receiver. In this section we review
the vulnerability of AERO to this type of attack.
</t>
<t>
AERO synchronization is robust even in the face of a DoS attack. An
AERO sender and receiver will stay in synchronization unless either
1) the attacker succeeds in forging a message, or 2) a burst of at
least B messages have been lost. The forgery likelihood is
determined by the parameters T, V, and W, and it can be set high
enough that the attacker's chance of success is negligible. A DoS
attack may cause bursts of lost messages, by causing congestion on
communication links. But AERO recovers quickly once that loss is
over.
</t>
<t>
AERO requires that all of the cryptographic processing be done
during the decryption algorithm in order to detect a forgery
attempt. This is in contrast to other authenticated encryption
algorithms (e.g. GCM) that can avoid doing decryption processing,
since the authentication check can be completed before the
encryption starts. When AERO is in use on a communication
environment where the data rate of the communications greatly
exceeds that of AERO decryption, it may be beneficial to use
additional mechanisms that allow the receiver to reject bogus
messages. This could include having a fixed, unpredictable value in
each message in order to foil off-path DoS attacks. To defend
against on-path attackers, cryptographic techniques can be used.
These techniques are beyond the scope of this document.
</t>
</section>
<section anchor="mssecurity" title="Multiple senders">
<t>
<xref target="ms"/> describes the sender uniqueness requirement: a
set of senders sharing the same key are recommended to ensure that
their associated data inputs to the encryption algorithm will be
distinct, for instance by including information in the associated
data that uniquely identifies each sender. If the senders do not
meet this requirement, then the security will degrade somewhat. The
details of this degradation depend on the details of the underlying
encryption method.
</t>
<t>
When a WPRP is used in AERO and the sender uniqueness requirement is
not met, an attacker can recognize when the same exact plaintext
message (A, P) is encrypted by different senders with the same
sequence number. Symbolically, if sender S1 and sender S2 both use
the same associated data value A and plaintext value P in the ith
message in sequence that they are each independently encrypting,
then the resulting ciphertexts will be identical, and an attacker
can infer that the plaintexts are matching. In many real-world
scenarios, it is highly unlikely that distinct senders will each
encrypt the same plaintext value for the same sequence number, and
thus the security degradation will be tolerable. If, however, the
plaintexts are either very short (such as eight or fewer octets) or
very repetitive (there are only a million possible plaintexts, for
instance), then the loss of confidentiality may be unacceptably
high.
</t>
<t>
When the sender uniqueness requirement is not met, the receiver will
be processing messages from two or more senders, while believing it
to be from a single sender. The decryption algorithm will
synchronize with the highest sequence number of any sender, and
reject the messages from other senders, if the highest sequence
number is at least W greater than all other sequence numbers. If the
sequence numbers of the senders are close, then the receiver will
interleave messages from different senders. In the latter case, an
attacker could potentially manipulate what the post-decryption
plaintext looks like by selectively withholding messages from
particular senders. Note that this property is not particular to
AERO; it holds for any authenticated encryption scheme in which
multiple entities are sharing the encryption key, and the receiver
has no way of determining which entity encrypted a particular
ciphertext message.
</t>
<t>
These security properties compare very favorably with those of
conventional authenticated encryption schemes. When the sender
uniqueness requirement is not met with a nonce-based encryption
scheme such as counter mode, CCM, GCM, Salsa or ChaCha, then
essentially all of the confidentiality guarantees are lost. For
nonce-based authentication schemes such as GCM, GMAC, and UMAC, all
of the authentication guarantees are lost.
</t>
</section>
<section title="Sequence number management failure">
<t>
An AERO implementation might accidentally mismanage sequence
numbers, due to faulty logic in the implementation, or due to
external factors such as the cloning of the state of the virtual
machine on which the implementation is running. If this happens,
security will degrade. In order to ensure that the degradation is
not catastrophic, the underlying stateless encryption algorithm
should be robust against nonce misuse, in the sense of <xref target="RFC5297"/>.
</t>
</section>
</section>
<!--
<section title="Discussion"> <t>
</t>
</section>
-->
<section title="Acknowledgements">
<t>
The authors thank Dan Wing, Stefan Lucks, and Brian Weis for
feedback and discussions, and Richard Barnes, Kenny Paterson, and
Robert Moskowitz for suggestions and corrections.
</t>
</section>
</middle>
<back>
<references title="Normative references">
&rfc2119;
&rfc5116;
&rfc2434;
</references>
<references title="Informative references">
<reference anchor="S07">
<front>
<title>
Improving Upon the TET Mode of Operation
</title>
<author initials="P." surname="Sarkar" >
<organization/>
</author>
<date year="2007"/>
</front>
<seriesInfo name="IACR eprint archive "
value="http://eprint.iacr.org/2007/317" />
</reference>
<reference anchor="CS07">
<front>
<title>
HCH: A New Tweakable Enciphering Scheme Using the Hash-Counter-Hash
Approach
</title>
<author initials="D." surname="Chakraborty" >
<organization/>
</author>
<author initials="P." surname="Sarkar" >
<organization/>
</author>
<date year="2007"/>
</front>
<seriesInfo name="IACR eprint archive "
value="http://eprint.iacr.org/2007/28" />
</reference>
<reference anchor="MF07">
<front>
<title>
The Security of the Extended Codebook (XCB) Mode of Operation
</title>
<author initials="D.A." surname="McGrew" fullname="David McGrew">
<organization/>
</author>
<author initials="S.R." surname="Fluhrer" fullname="Scott Fluhrer">
<organization/>
</author>
<date month="August" year="2007"/>
</front>
<seriesInfo name="14th Workshop on Selected Areas in Cryptography (SAC 2007)"
value="http://eprint.iacr.org/2007/298" />
</reference>
<reference anchor="1619.2">
<front>
<title>
IEEE 1619.2-2010: Standard for Wide-Block Encryption for Shared Storage Media
</title>
<author fullname="IEEE Security and Storage Working Group">
<organization></organization>
</author>
<date year="2010"/>
</front>
<seriesInfo name="IEEE Computer Society"
value="https://standards.ieee.org/findstds/standard/1619.2-2010.html" />
</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>
<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 surname="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="IV-GEN">
<front>
<title>
Generation of Deterministic Initialization Vectors (IVs) and Nonces
</title>
<author fullname="David A. McGrew" initials="D." surname="McGrew">
<organization></organization>
</author>
<date month="October" year="2013" />
</front>
<seriesInfo name="IETF Internet Draft"
value="http://www.ietf.org/id/draft-mcgrew-iv-gen-03.txt" />
</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="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 surname="Bellare" initials="M." fullname="Mihir Bellare">
<organization />
</author>
<author surname="Namprempre" initials="C." fullname="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 surname="Rogaway" initials="P." 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;
-->
&rfc4418;
&rfc4771;
<!--
<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>
&rfc4086;
&rfc4107;
-->
<reference anchor="AFFFLMW14">
<front>
<title>
Pipelineable Online Encryption
</title>
<author surname="Abed">
<organization />
</author>
<author surname="Fluhrer">
<organization />
</author>
<author surname="Foley">
<organization />
</author>
<author surname="Forler">
<organization />
</author>
<author surname="Lucks">
<organization />
</author>
<author surname="McGrew">
<organization />
</author>
<author surname="Wenzel">
<organization />
</author>
</front>
<seriesInfo name="Proceedings of the 21st international conference on Fast Software Encryption (FSE 2014)"
value="" />
</reference>
<reference anchor="FFLW11">
<front>
<title>
McOE: a family of almost foolproof on-line authenticated encryption schemes
</title>
<author surname="Fleischmann">
<organization />
</author>
<author surname="Forler">
<organization />
</author>
<author surname="Lucks">
<organization />
</author>
<author surname="Wenzel">
<organization />
</author>
</front>
<seriesInfo name="Proceedings of the 19th international conference on Fast Software Encryption (FSE 2011)"
value="" />
</reference>
<reference anchor="BKN04">
<front>
<title>
Breaking and provably repairing the SSH authenticated
encryption scheme: A case study of the
Encode-then-Encrypt-and-MAC paradigm
</title>
<author surname="Bellare">
<organization />
</author>
<author surname="Kohno">
<organization />
</author>
<author surname="Namprempre">
<organization />
</author>
</front>
<seriesInfo name="ACM Transactions on Information and System Security, 7(2), May 2004."
value="http://homes.cs.washington.edu/~yoshi/papers/SSH/" />
</reference>
&rfc5297;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:19:44 |