Online Authenticated-Encryption and its
Nonce-Reuse Misuse-Resistance
Viet Tung Hoang
1,2
Reza Reyhanitabar
3
Phillip Rogaway
4
Damian Vizár
3
1
Dept. of Computer Science, Georgetown University, USA
2
Dept. of Computer Science, University of Maryland, College Park, USA
3
EPFL, Lausanne, Switzerland
4
Dept. of Computer Science, University of California, Davis, USA
March 8, 2015
Abstract. A definition of online authenticated-encryption (OAE), call it OAE1, was given by Fleischmann,
Forler, and Lucks (2012). It has become a popular definitional target because, despite allowing encryption to
be online, security is supposed to be maintained even if nonces get reused. We argue that this expectation is
effectively wrong. OAE1 security has also been claimed to capture best-possible security for any online-AE
scheme. We claim that this understanding is wrong, too. So motivated, we redefine OAE-security, providing
a radically different formulation, OAE2. The new notion effectively does capture best-possible security for a
user’s choice of plaintext segmentation and ciphertext expansion. It is achievable by simple techniques from
standard tools. Yet even for OAE2, nonce-reuse can still be devastating. The picture to emerge is that no
OAE definition can meaningfully tolerate nonce-reuse, but, at the same time, OAE security ought never have
been understood to turn on this question.
Keywords: Authenticated encryption, CAESAR competition, misuse resistance, nonce reuse, online AE,
symmetric encryption.
1 Introduction
Between nAE and MRAE. With a typical nonce-based authenticated-encryption (nAE) scheme
[48, 50], nonces must never repeat when encrypting a series of messages; if they do, it is possible—and
routine—that all security will be forfeit.
5
To create some breathing room around this rigid requirement,
Rogaway and Shrimpton defined a stronger authenticated-encryption (AE) notion, which they called
misuse-resistant AE (MRAE) [51]. In a scheme achieving this, repeating a nonce has no adverse impact
on authenticity, while privacy is damaged only to the extent that an adversary can detect repetitions
of (𝑁, 𝐴, 𝑀) triples, these variables representing the nonce, associated data (AD), and plaintext.
While it’s easy to construct MRAE schemes [51], any such scheme must share a particular ineffi-
ciency: encryption can’t be online. When we speak of encryption being online we mean that it can be
realized with constant memory while making a single left-to-right pass over the plaintext 𝑀, writing
out the ciphertext 𝐶, also left-to-right, during that pass. The reason an MRAE scheme can’t have
online encryption is simple: the definition entails that every bit of ciphertext depends on every bit of
the plaintext, so one can’t output the first bit of a ciphertext before reading the last bit of plaintext.
Coupled with the constant-memory requirement, single-pass MRAE becomes impossible.
Given this efficiency/security tension, Fleischmann, Forler, and Lucks (FFL) put forward a security
notion [26] that slots between nAE and MRAE. We call it OAE1. Its definition builds on the idea of
an online cipher due to Bellare, Boldyreva, Knudsen, and Namprempre (BBKN) [15]. Both definitions
depend on a constant 𝑛, the blocksize. Let B
𝑛
= {0, 1}
𝑛
denote the set of 𝑛-bit strings, or blocks. An
online cipher is a blockcipher ℰ : 𝒦×B
*
𝑛
→ B
*
𝑛
(meaning each ℰ(𝐾, ·) is a length-preserving permutation)
5
Throughout this paper we ignore an annoying discursive problem surrounding the word nonce. The word is usually
understood to mean something that does not repeat (in some context); if it does repeat, it’s not a nonce. This would make
the phrase nonce repetition a logical absurdity. For a more neutral term, Bernstein has advocated message number [17].
Others use IV (initialization vector). We will stick with nonce for a value that nominally ought not repeat, yet might.
2
where the 𝑖th block of ciphertext depends only on the key and the first 𝑖 blocks of plaintext. An OAE1-
secure AE scheme is an AE scheme where encryption behaves like an (𝑁, 𝐴)-tweaked [40] online cipher
of blocksize 𝑛 followed by a random, (𝑁, 𝐴, 𝑀)-dependent tag.
Problems with OAE1. FFL assert that OAE1 supports online-AE and nonce-reuse security. We
disagree with the second claim, and even the first.
To begin, observe that as the blocksize 𝑛 decreases, OAE1 becomes weaker, in the sense that the
ability to perform a chosen-plaintext attack (CPA) implies the ability to decrypt the ciphertext of an
𝑚-block plaintext with (2
𝑛
− 1)𝑚 encryption queries. Fix a ciphertext 𝐶 = 𝐶
1
· · · 𝐶
𝑚
𝑇 with 𝐶
𝑖
∈ B
𝑛
,
a nonce 𝑁, and an AD 𝐴. Using just an encryption oracle Enc, we want to recover 𝐶’s plaintext
𝑀 = 𝑀
1
· · · 𝑀
𝑚
with 𝑀
𝑖
∈ B
𝑛
. Here’s an attack for 𝑛 = 1. If Enc(𝑁, 𝐴, 0) = 𝐶
1
set 𝑀
1
= 0;
otherwise, set 𝑀
1
= 1. Next, if Enc(𝑁, 𝐴, 𝑀
1
0) = 𝐶
1
𝐶
2
set 𝑀
2
= 0; otherwise, set 𝑀
2
= 1. Next, if
Enc(𝑁, 𝐴, 𝑀
1
𝑀
2
0) = 𝐶
1
𝐶
2
𝐶
3
set 𝑀
3
= 0; otherwise, set 𝑀
3
= 1. And so on, until, after 𝑚 queries, one
recovers 𝑀 . For 𝑛 > 1 generalize this by encrypting 𝑀
1
· · · 𝑀
𝑖−1
𝑀
𝑖
(instead of 𝑀
1
· · · 𝑀
𝑖−1
0) with 𝑀
𝑖
taking on values in B
𝑛
until one matches 𝐶
1
· · · 𝐶
𝑖
or there’s only a single possibility remaining. The
worst-case number of Enc queries becomes (2
𝑛
− 1)𝑚. We call this the trivial attack.
The trivial attack might suggest hope for OAE1 security as long as the blocksize is fairly large,
like 𝑛 = 128. We dash this hope by describing an attack, what we call a chosen-prefix / secret-suffix
(CPSS) attack, that breaks any OAE1-secure scheme, for any 𝑛, in the sense of recovering 𝑆 from given
an oracle for ℰ
𝑁,𝐴
𝐾
(𝐿 ‖ · ‖ 𝑆), for an arbitrary, known 𝐿. See Section 3. The idea was introduced, in a
different setting, with the BEAST attack [25].
While many real-world settings won’t enable a CPSS attack, our own take is that, for a general-
purpose tool, such a weakness effectively refutes any claim of misuse resistance. If the phrase is to
mean anything, it should entail that the basic characteristics of nAE are maintained in the presence of
nonce-reuse. An AE scheme satisfying nAE (employing non-repeating nonces) or MRAE (without that
restriction) would certainly be immune to such an attack.
We next pull back and take a more philosophical view. We argue that the definition of OAE1 fails
in quite basic ways to capture the intuition for what secure online-AE (OAE) ought do. First, schemes
targeting OAE1 conflate the blocksize of the tool being used to construct the scheme and the memory
restrictions or latency requirements that motivate OAE in the first place [57]. These two things are
unrelated and ought to be disentangled. Second, OAE1 fails to define security for plaintexts that aren’t
a multiple of the blocksize. But constructions do just that, encrypting arbitrary bit strings or byte
strings. Third, OAE1 measures privacy against an idealized object that’s an online cipher followed by
a tag. But having such a structure is not only unnecessary for achieving online encryption, but also
undesirable for achieving good security. Finally, while OAE1 aims to ensure that encryption is online,
it ignores decryption. The elision has engendered an additional set of definitions for RUP security,
“releasing unverified plaintext” [6]. We question the utility of online encryption when one still needs
to buffer the entire ciphertext before any portion of the (speculative) plaintext may be disclosed, the
implicit assumption behind OAE1.
An alternative: OAE2. There are environments where online encryption is needed. The designer
of an FPGA or ASIC encryption/decryption engine might be unable to buffer more than a kilobyte of
message. An application like SSH needs to send across a character interactively typed at the keyboard.
Netflix needs to stream a film [43] that is “played” as it is received, never buffering an excessive amount
or incurring excessive delays. A software library might want to support an incremental encryption
and decryption API. Whatever the setting, we think of the plaintext and ciphertext as having been
segmented into a sequence of segments. We don’t control the size of segments—that’s a user’s purview—
and different segments can have different lengths.
Thus the basic problem that OAE2 formalizes involves a (potentially long, even infinite) plaintext 𝑀
that gets segmented by the user to (𝑀
1
, . . . , 𝑀
𝑚
). We must encrypt each segment 𝑀
𝑖
as soon as it arrives,
3
OAE1 (from FFL [26]) OAE2 (new to this paper)
Definitional idea Online cipher followed by a tag Aencrypt each segment
Segmentation Fixed-size blocks of Variable-size segments of
scheme-determined lengths user-determined lengths
Typical block/segment size 5–16 bytes 1–10000 bytes? Not cryptographer’s decision
Ciphertext expansion 𝜏 bits per message (eg, 𝜏 = 128) 𝜏 bits per segment (eg, 𝜏 = 128)
Message space 𝑀 ∈ B
*
𝑛
for blocksize 𝑛 𝑀 ∈{0, 1}
*
(one view)or 𝑀 ∈ {0, 1}
**
(another)
Decryption also online? No, not in general Yes, automatically
Can aencrypt streams? No, messages must end Yes, messages can be conceptually infinite
OK to repeat nonces? No, attacks are always possible No, attacks are always possible
Fig. 1: Approaches to formulating online-AE. It is a thesis of this paper that OAE1 misformulates the desired goal
and wrongly promises nonce-reuse misuse-resistance.
carrying forward only a constant-size state. Thus 𝑀 gets transformed into a segmented ciphertext
(𝐶
1
, . . . , 𝐶
𝑚
). Each 𝐶
𝑖
must enable immediate recovery of 𝑀
𝑖
(the receiver can no more wait for 𝐶’s
completion than the sender can wait for 𝑀 ’s). We don’t insist that |𝐶
𝑖
| = |𝑀
𝑖
|; in fact, the user will
do better to grow each segment, |𝐶
𝑖
| > |𝑀
𝑖
|, to support expedient verification of what has come so far.
See Fig. 1 for a brief comparison of OAE1 and OAE2.
After formulating OAE2, which we do in two equivalent ways, we describe simple means to achieve
it. We don’t view OAE2 as a goal for which one should design a fundamentally new AE scheme; the
preferred approach is to use a conventional AE scheme and wrap it in a higher-level protocol. We
describe two such protocols. The first, CHAIN, can be used to turn an MRAE scheme (e.g., SIV)
into an OAE2 scheme. The second, STREAM, can be used to turn an nAE scheme (e.g., OCB) into
a nonce-based OAE scheme. That aim, nOAE, is identical to OAE2 except for insisting that, on the
encryption side, nonces don’t repeat.
We emphasize that moving from OAE1 to OAE2 does not enable one to safely repeat nonces; an
OAE2-secure scheme will still be susceptible to CPSS attack, for example. In that light, we would not
term an OAE2 scheme misuse resistant. What makes OAE2 “better” than OAE1 is not added robustness
to nonce-reuse (at least none that we know how to convincingly formalize) but a better modeling of the
problem at hand, and a more faithful delivery on the promise of achieving best-possible security for an
online-AE scheme. In view of the fact that, with OAE2, one must still deprecate nonce reuse, we would
view nOAE as the base-level aim for online-AE.
Related work. A crucial idea for moving beyond BBKN’s and FFL’s conceptions of online encryption
is to sever the association of the blocksize of some underlying tool and the quantum of text a user is
ready to operate on. A 2009 technical report of Tsang, Solomakhin, and Smith (TSS) [57] expressed this
insight and provided a definition based on it. TSS explain that AE à la Boldyreva and Taesombut [21]
(or BBKN or FFL, for that matter) “processes and outputs . . . blocks as soon as the next input block
is received” [57, p. 4], whence they ask, “what if the input is smaller than a block?”, even a bit,
6
or
what “if the input is a [segment] . . . of arbitrary length?” TSS maintain that such situations occur in
practice, and they give examples [57, Section 8].
There are major difference in how TSS proceed and how we do. They insist on schemes in which
there is ciphertext expansion only at the beginning and end, and their definition is oriented towards that
assumption. They do not authenticate the segmented plaintext but the string that is their concatenation.
Our formalization of OAE2 lets the adversary run multiple, concurrent sessions of online encryption and
decryption, another novum. In the end, the only commonality is some motivation and syntax. Yet it
6
It is in this sense that one might maintain that the OAE1 definition does not model even encryption being online; the
encrypting party might be unable to output anything, as the current block is incomplete.
4
seems unfortunate that the TSS manuscript escaped greater notice; in our view, it seems more prescient
than alternative lines. For further discussion of prior work, see Appendix B.
A real-world need. Netflix recently described a protocol of theirs, MSL, for streaming video [43].
The movie is broken into variable-length segments and each segment is independently encrypted and
authenticated, with the ordering of the segments itself authenticated. MSL is based on Encrypt-then-
MAC composition, where the encryption is AES-CBC with PKCS#5 padding and the MAC is HMAC-
SHA256. The choice suggests that even in real-time applications, use of a two-pass AE scheme for each
segment can be fine, as long as segments are of appropriate length. MSL resembles an instantiation
of STREAM. The current paper provides foundations for the problem that Netflix faced, offering
definitions and generic solutions with good provable security.
Even before the Netflix announcement, practitioners had publicly asked for such a tool, complaining
that with the current AE schemes one has to wait until the end of a ciphertext before one can release
the decrypted message. Stephen Touset writes: “I asked DJB [Dan Bernstein] [if] he had any intent to
add a streaming API to an authenticated cipher. His response was . . . that one should never release
a decrypted plaintext before verifying the authenticator. However, this got me to thinking. . . . Is it
possible, or even advisable, to mimic a streaming interface?” [56].
2 OAE1 Definition
All OAE definitions of widespread use spring from FFL [26], who married the definition of an online
cipher from Bellare, Boldyreva, Knudsen, and Namprempre [15] with the definition of authenticity of
ciphertexts (also called integrity of ciphertexts) [16,38, 50]. In this section we recall the FFL definition,
staying true to the original exposition as much possible, but necessarily deviating to correct an error.
We call the (corrected) definition OAE1.
Syntax. For any 𝑛 ≥ 1 let B
𝑛
= {0, 1}
𝑛
denote the set of 𝑛-bit blocks. A block-based AE scheme is a
triple 𝛱 = (𝒦, ℰ, 𝒟) where the key space 𝒦 is a nonempty set with an associated distribution and where
the encryption algorithm ℰ and decryption algorithm 𝒟 are deterministic algorithms with signatures
ℰ : 𝒦 × ℋ × B
*
𝑛
→ {0, 1}
*
and 𝒟 : 𝒦 × ℋ × {0, 1}
*
→ B
*
𝑛
∪ {⊥}. The set ℋ associated to 𝛱 is the
header space. FFL assumes that it is ℋ = B
+
𝑛
= 𝒩 × 𝒜 with 𝒩 = B
𝑛
and 𝒜 = B
*
𝑛
the nonce space
and AD space. The value 𝑛 associated to 𝛱 is its blocksize. Note that the message space ℳ of 𝛱 must
be ℳ = B
*
𝑛
and the blocksize 𝑛 will play a central role in the security definition. We demand that
𝒟(𝐾, 𝑁, 𝐴, ℰ(𝐾, 𝑁, 𝐴, 𝑀)) = 𝑀 for all 𝐾 ∈ 𝒦, 𝑁 ∈ 𝒩 , 𝐴 ∈ 𝒜, and 𝑀 ∈ B
*
𝑛
.
To eliminate degeneracies it is important to demand that |ℰ(𝐾, 𝐻, 𝑀 )| ≥ |𝑀| for all 𝐾, 𝐻, 𝑀 and,
additionally, to require that |ℰ(𝐾, 𝐻, 𝑀 )| depends on, at most 𝐻 and |𝑀|. To keep things simple, we
assume that the ciphertext expansion |ℰ(𝐾, 𝐻, 𝑀 )| − |𝑀 | is a constant 𝜏 ≥ 0 rather than an arbitrary
function of 𝐻 and |𝑀 |.
Security. Let OPerm[ 𝑛] be the set of all length-preserving permutations 𝜋 on B
*
𝑛
where 𝑖th block
of 𝜋(𝑀) depends only on the first 𝑖-blocks of 𝑀; more formally, a length-preserving permutation
𝜋 : B
*
𝑛
→ B
*
𝑛
is in OPerm[ 𝑛] if the first |𝑋| bits of 𝜋(𝑋𝑌 ) and 𝜋(𝑋𝑌
′
) coincide for all 𝑋, 𝑌, 𝑌
′
∈ B
*
𝑛
.
Despite its being infinite, one can endow OPerm[𝑛] with the uniform distribution in the natural way.
To sample from this we write 𝜋 ←← OPerm[𝑛].
Fix a block-based AE scheme 𝛱 = (𝒦, ℰ, 𝒟) with ℰ : 𝒦 × ℋ × B
*
𝑛
→ {0, 1}
*
. Then we associate to 𝛱
and an adversary A the real number Adv
oae1
𝛱
(A ) = Pr[A
Real1
⇒ 1] − Pr[A
Ideal1
⇒ 1] where games
Real1 and Ideal1 are defined in Fig. 2. Adversary A may not ask a Dec query (𝐻, 𝐶) after an Enc
query (𝐻, 𝑀) returned 𝐶. Informally, 𝛱 = (𝒦, ℰ, 𝒟) is said to be OAE1 secure if Adv
oae1
𝛱
(A ) is small
for any reasonable A . Alternatively, we can speak of OAE1[𝑛] security to emphasize the central role in
defining security of the scheme’s blocksize 𝑛.
5
initialize Real1
𝛱
𝐾 ←← 𝒦
proc Enc(𝐻, 𝑀 )
if 𝐻 ∈ ℋ or 𝑀 ∈ B
*
𝑛
then
return ⊥
return ℰ(𝐾, 𝐻, 𝑀)
proc Dec(𝐻, 𝐶)
if 𝐻 ∈ ℋ then return ⊥
return 𝒟(𝐾, 𝐻, 𝐶)
initialize Ideal1
𝛱
for 𝐻 ∈ ℋ do 𝜋
𝐻
←← OPerm[𝑛]
for (𝐻, 𝑀 ) ∈ ℋ × B
*
𝑛
do 𝑅
𝐻,𝑀
←← {0, 1}
𝜏
proc Enc(𝐻, 𝑀 )
if 𝐻 ∈ ℋ or 𝑀 ∈ B
*
𝑛
then return ⊥
return 𝜋
𝐻
(𝑀) ‖ 𝑅
𝐻,𝑀
proc Dec(𝐻, 𝐶)
return ⊥
Fig. 2: OAE1 security. Defining security for a block-based AE scheme 𝛱 = (𝒦, ℰ, 𝒟) with header space ℋ, blocksize 𝑛,
and ciphertext expansion 𝜏. See the accompanying text for the definition of OPerm[𝑛].
Discussion. The OAE1 definition effectively says that, with respect to privacy, a ciphertext must
resemble the image of a plaintext under a random online permutation tweaked by the nonce and AD;
followed by a 𝜏 -bit random string, the authentication tag. But the original definition from FFL somehow
omitted the second part [26, Definition 3]. The lapse results in a definition that makes no sense, as ℰ
must be length-increasing to provide authenticity. The problem was large enough that it wasn’t clear to
us what was intended. Follow-on work mostly replicated this [2, 27]. After discussions among ourselves
and checking with one of the FFL authors [41], we concluded that the intended definition is the one we
have given.
LCP leakage. Say that a block-based AE scheme 𝛱 = (𝒦, ℰ, 𝒟) with blocksize 𝑛 is LCP[𝑛] (for
“longest common prefix”) if for all 𝐾, 𝐻, 𝑀 , and 𝑖 ≤ |𝑀|/𝑛, the first 𝑖 blocks of ℰ
𝐻
𝐾
(𝑀) depends only
on the first 𝑖 blocks of 𝑀 . While all schemes we know claiming to be OAE1[𝑛] are also LCP[𝑛], an
OAE1[𝑛]-secure scheme isn’t necessarily LCP[ 𝑛]. This is because the requirement for OAE1[𝑛] security
is to be computationally close to an object that is LCP[𝑛], and being an object computationally close
to something with a property 𝑃 doesn’t mean that it will always have property 𝑃 . Indeed it is easy
to construct an artificial counterexample; for example, starting with a OAE1[𝑛]-secure scheme that is
LCP[𝑛], augment the key with 𝑛 extra bits, 𝐾
′
, and modify encryption so that when the first block of
plaintext coincides with 𝐾
′
, then reverse the bits of the remainder of the plaintext before proceeding.
OAE1 security is only slightly degraded but the scheme is no longer LCP[𝑛]. Still, despite such coun-
terexamples, an OAE1[𝑛]-secure scheme must be close to being LCP[𝑛]. Fix 𝛱 as above and consider
an adversary A that is given an oracle ℰ
𝐾
(·, ·) for 𝐾 ←← 𝒦. Consider A to be successful if it outputs
𝐻 ∈ ℋ and 𝑋, 𝑌, 𝑌
′
∈ B
*
𝑛
such that the first |𝑋|/𝑛 blocks of ℰ
𝐻
𝐾
(𝑋𝑌 ) and ℰ
𝐻
𝐾
(𝑋𝑌
′
) are different (i.e.,
the adversary found non-LCP behavior). Let Adv
lcp
𝛱
(A ) be the probability that A is successful. Then
it’s easy to transform A into an equally efficient adversary B for which Adv
oae1
𝛱
(B) = Adv
lcp
𝛱
(A ).
Because of this, there is no real loss of generality, when discussing OAE1[𝑛] schemes, to assume them
LCP[𝑛]. In the next section we will do so.
3 CPSS Attack
Section 1 described the trivial attack to break OAE1-secure schemes with too small a blocksize. We
now describe a different fixed-header CPA attack, this one working for any blocksize. We call the attack
a chosen-prefix, secret-suffix (CPSS) attack. The attack is simple, yet devastating. It is inspired by the
well-known BEAST (Browser Exploit Against SSL/TLS) attack [25].
Let 𝛱 = (𝒦, ℰ, 𝒟) be a block-based AE scheme with blocksize 𝑛 satisfying LCP[𝑛]. We consider a
setting where messages 𝑀 = 𝑃 ‖ 𝑆 that get encrypted can be logically divided into a prefix 𝑃 that is
controlled by an adversary, then a suffix 𝑆 that is secret, fixed, and not under the adversary’s control.
The adversary wants to learn 𝑆. We provide it the ability to obtain an encryption of ℰ
𝐻
𝐾
(𝑃 ‖ 𝑆) for
![Fig. 8: The STREAM construction for nOAE. Encryption scheme 𝛱 = (K,E,D) secure as an nAE with ciphertext expansion 𝜏 is turned into a segmented-AE scheme 𝛱 ′ = (𝒦, ℰ ,𝒟) = STREAM[𝛱, ⟨·⟩] with key space 𝒦 = K.](/figures/fig-8-the-stream-construction-for-noae-encryption-scheme-k-e-2cccedxe.webp)
![Fig. 7:The CHAIN construction for OAE2. Top: Encryption scheme 𝛱 = (K,E,D), secure as a PRI with expansion 𝜏 , is turned into a segmented-AE scheme CHAIN[𝛱, 𝑛] = (𝒦, ℰ ,𝒟) with 𝒦 = K. Bottom: Illustration of segmented encryption where each segment of (𝑀1, 𝑀2, 𝑀3) has at least 𝑛 bits. The trapezoid represents truncation to 𝑛 bits.](/figures/fig-7-the-chain-construction-for-oae2-top-encryption-scheme-1z00xkxp.webp)