Boosting Authenticated Encryption Robustness with Minimal Modifications

Abstract

Secure and highly efficient authenticated encryption (AE) algorithms which achieve data confidentiality and authenticity in the symmetric-key setting have existed for well over a decade. By all conventional measures, AES-OCB seems to be the AE algorithm of choice on any platform with AES-NI: it has a proof showing it is secure assuming AES is, and it is one of the fastest out of all such algorithms. However, algorithms such as AES-GCM and ChaCha20+Poly1305 have seen more widespread adoption, even though they will likely never outperform AES-OCB on platforms with AES-NI. Given the fact that changing algorithms is a long and costly process, some have set out to maximize the security that can be achieved with the already deployed algorithms, without sacrificing efficiency: ChaCha20+Poly1305 already improves over GCM in how it authenticates, GCM-SIV uses GCM’s underlying components to provide nonce misuse resistance, and TLS1.3 introduces a randomized nonce in order to improve GCM’s multi-user security. We continue this line of work by looking more closely at GCM and ChaCha20+Poly1305 to see what robustness they already provide over algorithms such as OCB, and whether minor variants of the algorithms can be used for applications where defense in depth is critical. We formalize and illustrate how GCM and ChaCha20+Poly1305 offer varying degrees of resilience to nonce misuse, as they can recover quickly from repeated nonces, as opposed to OCB, which loses all security. More surprisingly, by introducing minor tweaks such as an additional XOR, we can create a GCM variant which provides security even when unverified plaintext is released.

1 Introduction

Authenticated encryption (AE) is well established within the research community as the method to achieve confidentiality and authenticity using symmetric keys. Initially introduced as a response to a need in practice [6, 7], it has caught on in recent years. As a result, AE is used in many different environments, each with their own security and efficiency requirements. For this reason, the ongoing CAESAR competition [20], which aims to identify the next generation of authenticated encryption schemes, drafted three use cases as guides to what AE schemes should target: lightweight, high-performance, and defense in depth.

Within the high-performance category, OCB [43, 64, 65] is one of the most competitive AE schemes. Over ten years old, it is well known for its speed, and theoretically achieves the best performance when measured in block cipher calls. Although OCB has been standardized [1, 44], adoption has remained limited, for which its patents are usually assumed to be the main cause.

Instead, GCM [49] was chosen as the baseline algorithm with which to compare in the CAESAR competition. GCM is widely adopted and standardized [1, 24], and although it remains slower than OCB due to the additional universal hash on the output, it is getting more competitive as a result of improved hardware support [30]. ChaCha20+Poly1305 [12, 13, 56] is a popular alternative for settings where AES-NI is not implemented.

OCB, GCM, and ChaCha20+Poly1305 all target the high-performance category. Other than the fact that GCM and ChaCha20+Poly1305 are already widely adopted, and setting aside differences between using AES versus ChaCha20, from a conventional point of view there seems to be little reason to prefer them over OCB.

1.1 Robust Algorithms

The increased adoption of AE has been accompanied by an improved understanding of the limits of AE security within the research community. Even though OCB, GCM, and ChaCha20+Poly1305 are secure as proved in the conventional models (relative to their underlying primitives), questions often arise as to how robust they are once one of the assumptions in those models no longer holds. Already in 2002, Ferguson [25] pointed out that with a birthday bound attack on OCB one can mount forgeries, and Joux [42] illustrated with his “forbidden attack” how one can similarly construct forgeries for GCM after a repeated nonce. Furthermore, many have expressed concerns with the improved effectiveness of multi-key brute-force attacks [14, 16, 17, 21, 28] when applied to widely deployed algorithms.

Given the fact that modifying and deploying algorithms requires significant effort, and that the longer algorithms are used, the more their components are optimized, there has been interest in finding minimal modifications to deployed algorithms so that they are robust to settings which break one of the assumptions of the conventional security definitions. For example, TLS added extra nonce randomization to combat easier key-recovery attacks in the multi-key setting, which was later analyzed by Bellare and Tackmann [11]. The combination of ChaCha20+Poly1305 is neither a direct application of Encrypt-then-MAC [6] nor a copy of GCM: the authentication key used for Poly1305 is changed for every message, thereby preventing attacks which make GCM fragile. Going a step further, worries about nonce misuse in GCM have led Gueron and Lindell to use the components underlying GCM in order to create GCM-SIV [31], an algorithm that provides best possible security even when nonces are repeated. The common theme among these modifications is to squeeze as much security out of the schemes without sacrificing efficiency.

1.2 Release of Unverified Plaintext

Previous modifications have focused on providing additional security in the multi-key setting, or when nonces are repeated. However, other robust security properties, such as security with variable-length tags [63], under distinguishable decryption failures [19], or under release of unverified plaintext [3] are equally desirable. The CAESAR competition’s use case describing defense in depth lists authenticity and limited confidentiality damage from release of unverified plaintexts (RUP) as desirable properties [15].

One of the advantages of schemes secure under release of unverified plaintext is that they provide another line of defense with faulty implementations: if an implementation for whatever reason fails to check authenticity, then RUP-confidentiality guarantees that if the ciphertext did not originate from the sender or was modified en route, the resulting decrypted plaintext will look like garbage. Furthermore, there are settings where a RUP-secure AE scheme provides desirable properties beyond confidentiality and authenticity; in Appendix C we explain informally how our construction can be used to efficiently prevent the crypto-tagging attack in Tor, which is an attack on user anonymity.

State-of-the-art research might give the impression that achieving RUP security by minimally modifying existing schemes is out of reach: all designs providing such security either require significant changes, a completely new design, or an additional pass, making the schemes slower and adding design complexity. This is because so far the only solutions provided are essentially variable-input-length (VIL) ciphers [8], which can be viewed as block ciphers that can process arbitrarily long messages. However, VIL ciphers are “heavy” constructions, requiring often three or more passes over the plaintext in order to ensure sufficient mixing, or relying on subtle design choices to achieve security.

1.3 Contributions

We continue the line of research on robust AE design by exploring properties and variants of OCB, GCM, and ChaCha20+Poly1305 which go beyond the conventional view of AE.

Our first contribution focuses on analyzing the difference in nonce robustness provided by OCB, GCM, and ChaCha20+Poly1305, to provide a framework complementing the work of others [18, 25, 42, 53]. The conventional nonce misuse models are very black and white about security: GCM and ChaCha20+Poly1305 do not provide security under nonce misuse since an adversary can determine the XOR of two plaintexts when both are encrypted under the same nonce. However, what the conventional security models do not capture is that this insecurity affects only the involved plaintexts and does not “spill” onto others. If, for example, a faulty implementation repeats a nonce for a pair of plaintexts and then changes it correctly, confidentiality is only compromised for the plaintexts in the pair, and not for future plaintexts. In some sense, GCM (with 96 bit nonces) and ChaCha20+Poly1305 allow one to gracefully recover from re-used nonces by making them unique again, leading us to formalize such a definition, nonce-misuse resilience: plaintexts encrypted under unique nonces remain compartmentalized even when other plaintexts are compromised.

Within this model we establish that OCB is not resilient to nonce misuse, confirm that GCM with 96 bit nonces only provides confidentiality resilience, and that ChaCha20+Poly1305 provides both authenticity and confidentiality resilience, thereby formally showing that ChaCha20+Poly1305’s choice to depart from both the Encrypt-then-MAC and GCM designs boosts robustness to nonce misuse. Inspired by this result, one can also tweak GCM to achieve the same level of nonce misuse resilience by applying Minematsu and Iwata’s composition [53].

Our second, more surprising contribution is a minor modification to GCM which achieves both RUP confidentiality and authenticity, which neither OCB, GCM, nor ChaCha20+Poly1305 currently provide. Our design approach is generic, meaning it can add RUP security to a general class of encryption schemes. The core idea is to use a digest of the ciphertext to “hide” the nonce in such a way that recovering it properly requires that no change was made to the ciphertext. As a result, if a change did occur, it would affect the nonce, which, when used by the decryption algorithm, would decrypt the ciphertext into meaningless data.

2 Related Work

Our approach to analyzing nonce misuse differs from the line of research on online nonce misuse resistance [4, 27, 36], which seeks to analyze schemes which are not able to provide the best possible robustness to nonce misuse [66], but are able to guarantee more than nonce misuse resilience. Böck, Zauner, Devlin, Somorovsky, and Jovanovic [18] investigate the practical applicability of nonce-misusing attacks in TLS by searching for servers which repeat nonces with GCM.

Besides nonce misuse, another extension to the basic AE security model considers what happens when decryption algorithms may output multiple decryption errors [19]. Further research explored the security of known AE schemes when their decryption algorithms release partially decrypted plaintext before verification is complete [3], also known as the release of unverified plaintext (RUP) model. Both the multiple decryption error and RUP models were unified by Barwell, Page, and Stam [5] in the subtle AE framework, by using a “leakage” function which captures information leaked via a side channel. The “leakage” function represents any information that can be received through additional channels. Hoang, Krovetz, and Rogaway introduce the concept of “Robust AE” (RAE) [35] which formalizes one of the strongest types of security that an AE scheme can satisfy. Our use of the term “robust” describes a gradient, in which RAE represents the most robust form of AE, and conventional definitions the most basic form.

Imamura, Minematsu, and Iwata [37] show that ChaCha20+Poly1305 maintains authenticity in the RUP setting.

We follow Shrimpton and Terashima [71] in taking a modular approach to the problem of adding RUP security to encryption schemes, by first providing a solution in the most general form possible, and then providing an instantiation. Furthermore, our construction is similar to the lower half of Shrimpton and Terashima’s PIV construction. However, their goal is to achieve something similar to a VIL cipher, which we argue might be overkill in some scenarios. Note that combining SIV [66] with our construction would result in a solution very similar to PIV. RIV [2] is another construction which takes a modular approach in designing a robust AE scheme.

For a survey on ways to construct VIL ciphers, see Shrimpton and Terashima’s paper [71]. All the previous methods are generic approaches to designing VIL ciphers, although there are dedicated approaches as well, such as AEZ [35], which in fact aims for RAE.

Hirose, Sasaki, and Yasuda [33] presented a construction similar to ours. However, their construction only accounts for changes over the tag, rather than the entire ciphertext, hence their solution only provides limited robustness and would, for example, not prevent the Tor crypto-tagging attack described in Appendix C. In recent work, Hirose, Sasaki, and Yasuda [34] introduce constructions which do account for changes over the entire ciphertext, and focus on formalizing how such AE constructions make verification unskippable.

3 Preliminaries

3.1 Notation

The set of strings of length not greater than x bits is $\left\{ 0,1\right\} ^{\le x}$, and the set of strings of arbitrary length is $\left\{ 0,1\right\} ^*$. Unless specified otherwise, all sets are subsets of $\left\{ 0,1\right\} ^*$. If $X,Y \in \left\{ 0,1\right\} ^*$, then $\left|X\right|$ is the length of X, and $X\parallel Y$ and XY denote the concatenation of X and Y.

Let $\varepsilon$ denote the empty string, and let $0^n$ denote the n-bit string consisting of only zeros. Given a block size n, the function $\mathsf {len}_{n}(X)$ represents the length of X modulo $2^n$ as an n-bit string, and $X0^{*n}$ is X padded on the right with 0-bits to get a string of length a multiple of n. If $X\in \left\{ 0,1\right\} ^*$, then $\left|X\right|_n = \lceil \left|X\right|/n \rceil$ is X’s length in n-bit blocks. The operation

$$\begin{aligned} X[1]X[2]\cdots X[x]\xleftarrow {n}X \end{aligned}$$

(1)

denotes splitting X into substrings such that $\left|X[i]\right| = n$ for $i = 1,\ldots , x-1$, $0 < \left|X[x]\right| \le n$, and $X[1]\Vert X[2]\Vert \cdots \Vert X[x] = X$.

The set of n-bit strings is also viewed as the finite field $GF(2^n)$, by mapping $a_{n-1}\ldots a_1a_0$ to the polynomial $a(\texttt {x}) = a_{n-1} + a_{n-2}{} \texttt {x} + \cdots + a_1\texttt {x}^{n-1} + a_0\texttt {x}^{n-1} \in GF(2)[\texttt {x}]$, and fixing an irreducible polynomial which defines multiplication in the field. For $n = 128$, the irreducible polynomial is $1 + \texttt {x} + \texttt {x}^2 + \texttt {x}^7 + \texttt {x}^{128}$, the one used for GCM.

The function $\mathsf {int}(Y)$ maps the j bit string $Y = a_{j-1}\ldots a_1a_0$ to the integer $i = a_{j-1}2^{j-1}+\cdots + a_12 + a_0$, and $\mathsf {str}_{j}(i)$ maps the integer $i = a_{j-1}2^{j-1} + \cdots + a_12 + a_0 < 2^{j}$ to the j bit string $a_{j-1}\ldots a_1a_0$. Let $\mathsf {inc}_{m}(X)$ denote the function which adds one modulo $2^{m}$ to X when viewed as an integer:

$$\begin{aligned} \mathsf {inc}_{m}(X) :=\mathsf {str}_{m}(\mathsf {int}(X) + 1 \bmod {2^{m}})\,. \end{aligned}$$

Define $\mathsf {msb}_{j}(X)$ to be the function that returns the j most significant bits of X, and $\mathsf {lsb}_{j}(X)$ the j least significant bits.

For a keyed function defined on a domain $\mathsf {K}\times \mathsf {X}$, we write F(K, X) and $F_K(X)$ interchangeably. If the function has three inputs, $\mathsf {K}\times \mathsf {N}\times \mathsf {X}$, then the second input will often be written as a superscript, $F(K,N,X) = F_K^N(X)$. If $E:\left\{ 0,1\right\} ^{n}\rightarrow \left\{ 0,1\right\} ^m$ is a function, then the notation

$$\begin{aligned} F\leftarrow E(C\parallel \cdot ) \end{aligned}$$

(2)

defines F to be the function from $\left\{ 0,1\right\} ^{n-\left|C\right|}$ to $\left\{ 0,1\right\} ^m$ which maps an element $X\in \left\{ 0,1\right\} ^{n-\left|C\right|}$ to $E(C\parallel X)$.

The expression $a \mathop {=}\limits ^{?} b$ evaluates to $\top$ if a equals b, and $\bot$ otherwise.

3.2 Adversaries and Advantages

An adversary $\mathbf {A}$ is an algorithm which interacts with an oracle O. Let $\mathbf {A}^{O} = 1$ be the event that $\mathbf {A}$ outputs 1 when interacting with O, then define

(3)

which is the advantage of $\mathbf {A}$ in distinguishing f from g, where f and g are viewed as random variables. The notation can be extended to multiple oracles by setting $O = (O_1,\ldots ,O_\ell )$.

We assume that all keyed functions do not change their output length under different keys, that is, $\left|F_K(X)\right|$ is the same for all $K\in \mathsf {K}$. Given a keyed function F, define $\$_F$ to be the algorithm which, given X as input, outputs a string chosen uniformly at random from the set of strings of length $\left|F_K(X)\right|$ for any key K. When given the same input, $\$_F$ returns the same output. Often $\$_F$ is called a random oracle.

3.3 Authenticated Encryption Schemes

The syntax for conventional authenticated encryption (AE) schemes specifies an encryption and decryption algorithm, where the decryption algorithm may output either plaintext or a single, pre-defined error symbol. Formally, an AE scheme is a tuple of functions — encryption $\mathsf {Enc}$ and decryption $\mathsf {Dec}$ — where

$$\begin{aligned} \mathsf {Enc}&: \mathsf {K}\times \mathsf {N}\times \mathsf {M}\rightarrow \mathsf {C}\,,\end{aligned}$$

(4)

$$\begin{aligned} \mathsf {Dec}&: \mathsf {K}\times \mathsf {N}\times \mathsf {C}\rightarrow \mathsf {M}\cup \left\{ \bot \right\} \,, \end{aligned}$$

(5)

with $\mathsf {K}$ the keys, $\mathsf {N}$ the nonces, $\mathsf {M}$ the messages, $\mathsf {C}$ the ciphertexts, and $\bot$ an error symbol not contained in $\mathsf {M}$, which represents verification failure. It must be the case that for all $K\in \mathsf {K}$, $N\in \mathsf {N}$, and $M\in \mathsf {M}$,

$$\begin{aligned} \mathsf {Dec}_K^N(\mathsf {Enc}_K^N(M)) = M\quad \,. \end{aligned}$$

(6)

AE schemes must provide both chosen-ciphertext confidentiality and authenticity. The AE advantage of adversary $\mathbf {A}$ against $\varPi = (\mathsf {Enc},\mathsf {Dec})$ is

$$\begin{aligned} \mathsf {AE}_\varPi (\mathbf {A}):=\mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathsf {Enc}_K,\mathsf {Dec}_K\,;\,\$_\mathsf {Enc},\bot \right) \,, \end{aligned}$$

(7)

where $\mathbf {A}$ is nonce-respecting, meaning the same nonce is never queried twice to $\mathsf {Enc}$. Nonces may be repeated with $\mathsf {Dec}$. Furthermore, $\mathbf {A}$ cannot use the output of an $O_1^N$ query as the input to an $O_2^N$ with the same nonce N, otherwise such queries result in trivial wins.

4 Resilience to Nonce Misuse

Rogaway and Shrimpton [66, 67] formalize the best possible security when adversaries may re-use nonces. They illustrate how such nonce misuse resistance can be achieved using the construction SIV, which was later the inspiration for GCM-SIV [31].

Finding attacks against OCB, GCM, and ChaCha20+Poly1305 which exploit repeated nonces is relatively straightforward. When nonces are repeated, OCB is not much better than ECB mode [57] since one can easily identify when plaintext blocks are repeated across messages in the same block position. In GCM, keystreams are tied to nonces, hence all messages encrypted with the same nonce will use the same keystream, allowing one to recover the XOR of plaintexts; furthermore, authenticity is broken using Joux’s forbidden attack [42]. ChaCha20+Poly1305 suffers from similar attacks as GCM. However, looking more closely at the nonce misusing attacks, one can see that the three algorithms behave very differently.

For a description of OCB, GCM, and ChaCha20+Poly1305, and the notation we use see Appendices A.1, A.2, and A.3, respectively.

4.1 OCB Attacks

OCB computes two intermediate keys L and R, which it uses to mask the block cipher inputs and outputs. The value L is computed as the output of the block cipher when given $0^n$ as input, $L :=E_K(0^n)$, and remains fixed per key. The value R changes per nonce, and is computed by encrypting $L\oplus N$ under the block cipher. Finally, the masks are computed as $\gamma _i\cdot L\oplus R$.

Ferguson [25] illustrates how to recover the intermediate key L by finding a collision using a birthday-bound attack, and subsequently shows how to perform forgeries with L for any nonce. In fact, a chosen-plaintext confidentiality attack can be performed as well, by XORing the sequence $(\gamma _1\cdot L, \gamma _2\cdot L, \ldots , \gamma _m\cdot L)$ to the plaintext and ciphertext in order to remove dependence on L. This compromises OCB’s confidentiality under any nonce N since repeated plaintext blocks in the same message will encrypt to the same ciphertext block. Below we show how to recover L using a nonce-repeating attack.

Fig. 1.

An illustration of two queries which would form the first step of the OCB attack. In both cases $R = E_K(L\oplus N)$.

Our attack needs to repeat a particular nonce four times, and works best when $\tau = n$. First, encrypt an arbitrary full-block message $M_1$ of block length m under nonce N. Receive the corresponding tag $T_1$ and let $S_1$ denote the checksum used to generate $T_1$, so that $T_1 = E_K(S_1\oplus Z[m])$, where $Z[m] = \gamma _mL\oplus R$. Encrypt another message $M_2$ of length greater than m blocks under the same nonce N, with the mth block of $M_2$ equal to $M_2[m] = S_1$. The two queries are depicted in Fig. 1. Note that the corresponding ciphertext block $C_2[m]$ equals

$$\begin{aligned} E_K(S_1\oplus Z[m])\oplus Z[m]\,, \end{aligned}$$

(8)

and so

$$\begin{aligned} C_2[m]\oplus T_1 = Z[m] = \gamma _mL\oplus R\,. \end{aligned}$$

(9)

Encrypt another two messages $M_1'$ and $M_2'$ under nonce N where $M_1'$ has length $m'\ne m$, performing the same steps as above to receive $T'_1$ and $C_2[m']$ such that

$$\begin{aligned} C_2[m']\oplus T_1' = Z[m'] = \gamma _{m'}L\oplus R\,. \end{aligned}$$

(10)

Then L can be recovered from

$$\begin{aligned} C_2[m]\oplus T_1\oplus C_2[m']\oplus T_1' = (\gamma _m\oplus \gamma _{m'})L\,. \end{aligned}$$

(11)

4.2 Chosen-Plaintext Confidentiality

Although the above attack against OCB requires a nonce to be repeated four times, once those repetitions have occurred, OCB can no longer guarantee security. As already observed by Joux [42], one cannot apply a similar confidentiality attack to GCM, since every new nonce generates a new, roughly independent keystream, and no information can be determined from the plaintext without knowing anything about the keystream. The intuition that no information about the plaintext can be determined from other keystreams can be formalized with the following definition.

Definition 1

Let $\mathbf {A}$ be an adversary and $(\mathsf {Enc},\mathsf {Dec})$ an AE scheme, then the CPA resilience advantage of $\mathbf {A}$ against $(\mathsf {Enc},\mathsf {Dec})$ is defined as

$$\begin{aligned} \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathsf {Enc}_K, \mathsf {Enc}_K\,;\,\$_\mathsf {Enc}, \mathsf {Enc}_K\right) \,, \end{aligned}$$

(12)

where $\mathbf {A}$ may re-use nonces with $O_2$, but it may not re-use nonces with $O_1$, nor may it use a nonce already queried to $O_2$ for an $O_1$-query and vice versa.

The above definition allows adversaries to perform nonce-reusing attacks with $\mathsf {Enc}_K$, but forces the adversary to win by distinguishing $\mathsf {Enc}_K$ from $\$_\mathsf {Enc}$ using a nonce-respecting attack, thereby capturing the intuition that a scheme which provides confidentiality resilience to nonce misuse must maintain confidentiality for properly generated nonces, even if the attacker is given the power to re-use other nonces. Note that the form of our definition follows the framework of Barwell, Page, and Stam [5], by separately providing oracles representing the adversary’s goal ($\mathsf {Enc}_K$ versus $\$_\mathsf {Enc}$), as well as oracles representing the adversary’s power (the second $\mathsf {Enc}_K$).

In order for schemes to be secure according to the above definition, they must ensure that encryption under one nonce is roughly independent from encryption under another, even if adversaries may gain information by re-using nonces with the encryption oracle. Proving that GCM with 96 bit nonces satisfies this definition up to the birthday bound is straightforward. First note that adversaries which only have access to GCM encryption are essentially interacting with a stream cipher, CTR mode, since unless a nonce is repeated, no two block cipher calls are ever the same. This fact holds even if $E_K(0^n)$ is released to the adversary, since this value is never output by the underlying CTR mode. Then, after applying a PRP-PRF switch, the keystreams generated by the underlying CTR mode under different nonces are independent of each other and uniformly distributed. Therefore interacting with $(\mathsf {Enc}_K,\mathsf {Enc}_K)$ is indistinguishable from interacting with $(\$_\mathsf {Enc}, \mathsf {Enc}_K)$. Similar reasoning applies to ChaCha20, assuming the underlying ChaCha20 block function is a good PRF.

Furthermore, OCB does not provide security according to the above definition, because an adversary can make nonce-repeating queries to $\mathsf {Enc}_K$ via its $O_2$ oracle to recover L, and can then perform a confidentiality attack with its other oracle. Similarly, GCM with non-96 bit nonces does not provide nonce resilient confidentiality: since adversaries can recover $E_K(0^n) = L$ (e.g. using Joux’s forbidden attack [42]), they can manipulate the counters used in the underlying CTR mode to perform a confidentiality attack, since $\mathsf {GHASH}_L$ is applied to the nonce before using it in CTR mode (see e.g. Fig. 5).

4.3 Authenticity

Unlike confidentiality, if a nonce is repeated with GCM, then attackers can recover the authentication key, allowing one to construct forgeries for arbitrary nonces, as illustrated by Joux [42]. Therefore, even though 96-bit-nonce GCM is resilient to nonce misuse when considering chosen plaintext confidentiality attacks, it is not resilient with respect to authenticity. Similarly, OCB is not resilient to nonce misuse with respect to authenticity.

With ChaCha20+Poly1305, authentication keys are changed with every nonce, hence even if a nonce is repeated and the authentication key recovered, an adversary will only be able to forge ciphertexts under the compromised nonce. Such authentication resilience can be formalized as follows.

Definition 2

Let $\mathbf {A}$ be an adversary and $(\mathsf {Enc},\mathsf {Dec})$ an AE scheme, then the authenticity resilience advantage of $\mathbf {A}$ against $(\mathsf {Enc},\mathsf {Dec})$ is

$$\begin{aligned} \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathsf {Enc}_K, \mathsf {Dec}_K\,;\,\mathsf {Enc}_K,\bot \right) \,, \end{aligned}$$

(13)

where if a nonce is used twice with $O_1$, then it cannot be used in an $O_2$ query, and adversaries may not query $O_1^N(M) = C$ followed by $O_2^N(C)$.

Here the $\mathsf {Enc}_K$ oracle is the adversary’s power, since it may repeat nonces with that oracle. The challenge of the adversary is to distinguish $\mathsf {Dec}_K$ and $\bot$, by constructing a forgery with a nonce which has not been repeated to $\mathsf {Enc}_K$.

The only difference between the above definition and the conventional definition of authenticity is in the restrictions on the adversary: in the conventional definition adversaries must be nonce-respecting, whereas in this definition they may repeat nonces, but may not use repeated nonces to construct forgeries.

One way for schemes to provide authenticity resilience is to ensure that tags verified during decryption under one nonce are independent of verification under another. For example, assuming that the ChaCha20 block function behaves as a PRF, each keystream generated by ChaCha20 under one nonce is independent of the keystreams generated under different nonces, since, as was the case with 96-bit-nonce GCM, no two block function calls are the same. Furthermore, Poly1305 is keyed using the output of the keystream. This means that, after replacing the ChaCha20 block function by a uniformly random function, each nonce picks a different, independently distributed instance of ChaCha20+Poly1305. In particular, tag production and verification under one nonce is independent of other nonces. Say that an adversary submits a decryption query (N, C). If N was never queried to any previous $\mathsf {Enc}_K$ query, then tag verification is independent of all previous $\mathsf {Enc}_K$ queries, and it is unlikely that a forgery will be successful. Even if N was queried previously to $\mathsf {Enc}_K$, then it could have only been queried once to $\mathsf {Enc}_K$, and tag verification will be independent of all other $\mathsf {Enc}_K$ queries, meaning the adversary will have no better chance of attacking the scheme than if it had been nonce-respecting.

OCB and GCM do not satisfy the above definition because an adversary can use the $\mathsf {Enc}_K$ oracle to recover intermediate keys, and perform forgeries. However, there is an easy way for 96-bit-nonce GCM to mimic ChaCha20+Poly1305 such that it does become resilient to nonce re-use: produce an additional keystream block with its underlying CTR mode, and use the output of that block as the authentication key for each nonce. Minematsu and Iwata [53] consider a general version of this construction written in terms of a variable-output-length PRF and a MAC, and by replacing the PRF with CTR mode and the MAC with GHASH, one can construct a variant of GCM which provides authenticity resilience under nonce misuse, with security justification following along the lines of ChaCha20+Poly1305.

4.4 Chosen-Ciphertext Confidentiality

Much like in the conventional settings, schemes which achieve both chosen-plaintext confidentiality and authenticity resilience, achieve chosen-ciphertext confidentiality resilience, as defined below.

Definition 3

The CCA confidentiality resilience advantage of $\mathbf {A}$ against $(\mathsf {Enc},\mathsf {Dec})$ is

$$\begin{aligned} \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathsf {Enc}_K, \mathsf {Enc}_K, \mathsf {Dec}_K\,;\,\$, \mathsf {Enc}_K, \bot \right) \,, \end{aligned}$$

(14)

where nonces may not be repeated with queries to $O_1$, a nonce used twice with $O_2$ cannot be used for an $O_3$ query, a query $O_1^N(M) = C$ or $O_2^N(M) = C$ may not be followed by $O_3^N(C)$, and finally a nonce N used to query $O_1^N$ may not be re-used to query $O_2^N$, and vice versa.

The fact that CPA confidentiality and authenticity resilience imply the above definition follows from a straightforward application of the triangle inequality:

$$\begin{aligned} \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathsf {Enc}_K, \mathsf {Enc}_K, \mathsf {Dec}_K\,;\,\$, \mathsf {Enc}_K, \bot \right)&\le \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathsf {Enc}_K,\mathsf {Enc}_K,\mathsf {Dec}_K\,;\,\mathsf {Enc}_K,\mathsf {Enc}_K,\bot \right) \end{aligned}$$

(15)

$$\begin{aligned}&+\mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathsf {Enc}_K,\mathsf {Enc}_K,\bot \,;\,\$,\mathsf {Enc}_K,\bot \right) \end{aligned}$$

(16)

The first term on the right hand side can be bounded above by authenticity of $(\mathsf {Enc},\mathsf {Dec})$, and the second term by confidentiality.

5 Adding RUP Security to Encryption Schemes

In this section we introduce our generic method of adding RUP security to a class of encryption schemes. Following Shrimpton and Terashima [71], we take a modular approach in designing our construction. We start by describing the generic components from which the construction will be made, namely tweakable block ciphers and encryption schemes, and the security requirements they must satisfy, $\mathsf {SPRP}$ and $\mathsf {SRND}$ [32], respectively. The advantage of this approach is that the sufficient conditions to achieve security under release of unverified plaintext are made explicit, and then, depending upon the available primitives, different instantiations of the construction can be considered without resorting to new proofs.

Following a discussion of the components, we describe the construction, and discuss informally why it enhances the security of the underlying encryption scheme. The generic construction achieves $\mathsf {RUPAE}$, meaning it provides both authenticity and confidentiality even if unverified plaintext is released. A formal security argument for the construction is given in Appendix B. Finally we complete the section by discussing an instantiation, GCM-RUP, which uses GCM’s components to create a scheme which provides RUP-security.

5.1 Definitions

Following the RUP-model [3], we focus on designing separated AE schemes, where the decryption algorithm is split into plaintext computation and verification algorithms, to ensure that the decryption algorithm does not “hide” weaknesses behind the error symbol. Furthermore, our construction will communicate nonces in-band, meaning it will encrypt them and consider them as part of the ciphertext. As a result, the nonce no longer needs to be synchronized or communicated explicitly, as sufficient information is contained in the value S. This changes the syntax slightly, since now the decryption and verification algorithms no longer accept an explicit nonce input.

Formally, a separated AE scheme which communicates nonces in-band is a triplet of functions — encryption $\mathsf {SEnc}$, decryption $\mathsf {SDec}$, and verification $\mathsf {SVer}$ — where

$$\begin{aligned} \mathsf {SEnc}&: \mathsf {K}\times \mathsf {N}\times \mathsf {M}\rightarrow \mathsf {C}\,,\end{aligned}$$

(17)

$$\begin{aligned} \mathsf {SDec}&: \mathsf {K}\times \mathsf {C}\rightarrow \mathsf {M}\,,\end{aligned}$$

(18)

$$\begin{aligned} \mathsf {SVer}&: \mathsf {K}\times \mathsf {C}\rightarrow \left\{ \bot ,\top \right\} \,. \end{aligned}$$

(19)

with $\mathsf {K}$ the keys, $\mathsf {N}$ the nonces, $\mathsf {M}$ the messages, and $\mathsf {C}$ the ciphertexts. Recall that the symbols $\top$ and $\bot$ represent success and failure of verification, respectively, and we assume that neither are elements of $\mathsf {M}$. It must be the case that for all $K\in \mathsf {K}$, $N\in \mathsf {N}$, and $M\in \mathsf {M}$,

$$\begin{aligned} \mathsf {SDec}_K(\mathsf {SEnc}_K^N(M)) = M\quad \text { and }\quad \mathsf {SVer}_K(\mathsf {SEnc}_K^N(M)) = \top \,. \end{aligned}$$

(20)

From a separated AE scheme $(\mathsf {SEnc},\mathsf {SDec},\mathsf {SVer})$ one can reconstruct the following conventional AE scheme $(\mathsf {AEnc},\mathsf {ADec})$:

$$\begin{aligned} \mathsf {AEnc}_K^N(M)&:=\mathsf {SEnc}_K^N(M) \end{aligned}$$

(21)

$$\begin{aligned} \mathsf {ADec}_K(C)&:={\left\{ \begin{array}{ll} \mathsf {SDec}_K(C) &{} \text { if }\mathsf {SVer}_K(C) = \top \\ \bot &{} \text { otherwise }\,, \end{array}\right. } \end{aligned}$$

(22)

where we assume that the AE scheme communicates nonces in-band as well.

Separated AE schemes must provide both chosen-ciphertext confidentiality and authenticity. Both of these security aspects are captured in the RUPAE measure of Barwell, Page, and Stam [5]. We adopt a stronger version of their definition, by requiring the decryption algorithm to look “random” as well. Let $\varPi$ denote a separated AE scheme $(\mathsf {SEnc},\mathsf {SDec},\mathsf {SVer})$, then the RUPAE-advantage of adversary $\mathbf {A}$ against $\varPi$ is

$$\begin{aligned} \mathsf {RUPAE}_\varPi (\mathbf {A}):=\mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathsf {SEnc}_K,\mathsf {SDec}_K,\mathsf {SVer}_K\,;\,\$_\mathsf {SEnc},\$_\mathsf {SDec},\bot \right) \,, \end{aligned}$$

(23)

where $\mathbf {A}$ is nonce-respecting, meaning the same nonce is never queried twice to $\mathsf {SEnc}$. Nonces may be repeated with $\mathsf {SDec}$ and $\mathsf {SVer}$. Furthermore, $\mathbf {A}$ cannot use the output of an $O_1^N$ query as the input to an $O_2^N$ or $O_3^N$ query with the same nonce N, otherwise such queries result in trivial wins.

5.2 Generic Construction

Components. A tweakable block cipher [47] is a pair of functions $(\mathsf {E},\mathsf {D})$, with

$$\begin{aligned} \mathsf {E}&: \mathsf {K}\times \mathsf {T}\times \mathsf {X}\rightarrow \mathsf {X}\end{aligned}$$

(24)

$$\begin{aligned} \mathsf {D}&: \mathsf {K}\times \mathsf {T}\times \mathsf {X}\rightarrow \mathsf {X}\,, \end{aligned}$$

(25)

where $\mathsf {K}$ is the key space, $\mathsf {T}$ the tweak space, and $\mathsf {X}$ the domain, where $\mathsf {X}= \left\{ 0,1\right\} ^x$ is a set of strings of a particular length. For all $K\in \mathsf {K}$ and $T\in \mathsf {T}$ it must be the case that $\mathsf {E}_K^T$ is a permutation with $\mathsf {D}_K^T$ as inverse. We will need to measure the $\mathsf {SPRP}$ quality of the tweakable block cipher, which is defined as

$$\begin{aligned} \mathsf {SPRP}(\mathbf {A}) :=\mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathsf {E}_K,\mathsf {D}_K\,;\,\pi ,\pi ^{-1}\right) \,, \end{aligned}$$

(26)

where K is chosen uniformly at random from $\mathsf {K}$, and $(\pi ,\pi ^{-1})$ is a family of independent, uniformly distributed random permutations over $\mathsf {X}$ indexed by $\mathsf {T}$.

Although Liskov, Rivest, and Wagner [47] introduced the concept of finite-tweak-length (FTL) block ciphers, for our construction we need tweakable block ciphers that can process variable tweak lengths (VTL). Starting from an FTL block cipher, one can construct a VTL block cipher by compressing the tweak using a universal hash function, and using the resulting output as the tweak for the FTL block cipher, as explained by Coron et al. [22]. Minematsu and Iwata [54] introduce the XTX construction which extends tweak length while minimizing security loss.

There are a few dedicated constructions of FTL block ciphers: the hash function SKEIN [26] contains an underlying tweakable block cipher, the CAESAR competition candidates Joltik [41] and Deoxys [40] also developed new tweakable block ciphers, and the TWEAKEY framework [39] tackles the problem of designing tweakable block ciphers in general. Besides dedicated constructions, there are also constructions of tweakable block ciphers using regular block ciphers; see for example Rogaway’s XE and XEX constructions [64], Minematsu’s beyond-birthday bound construction [52], Landecker, Shrimpton, and Terashima’s $\mathsf {CLRW2}$ construction [45], and Mennink’s beyond-birthday bound constructions [51].

An encryption scheme $(\mathsf {Enc},\mathsf {Dec})$ is a separated AE scheme without $\mathsf {SVer}$. The basic security requirement for encryption schemes is chosen-plaintext confidentiality, but this is not sufficient for our purpose. In particular, a mode like CBC [55] will not work, since during decryption a change in the nonce will only affect the first decrypted plaintext block. We need encryption schemes where during decryption a change in the nonce will result in the entire plaintext changing. Modes such as CTR [55], OFB [55], and the encryption of OCB [43, 64, 65] suffice. In particular, it is necessary that both encryption and decryption algorithms give uniform random output when distinct nonces are input across both encryption and decryption. For example, with CTR mode, decryption is the same as encryption, and if nonces are never repeated across both algorithms then its output will always look uniformly random.

We use Shrimpton and Terashima’s [71] $\mathsf {SRND}$ measure for encryption schemes, which was introduced by Halevi and Rogaway [32]:

$$\begin{aligned} \mathsf {SRND}(\mathbf {A}) :=\mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathsf {Enc}_K,\mathsf {Dec}_K\,;\,\$_\mathsf {Enc},\$_\mathsf {Dec}\right) , \end{aligned}$$

(27)

where K is chosen uniformly at random from $\mathsf {K}$, and $\mathbf {A}$ must use a different nonce for every query it makes, to both of its oracles.

Description. Let $(\mathsf {Enc},\mathsf {Dec})$ be an encryption scheme with key space $\mathsf {K}$, nonce space $\mathsf {N}$, message space $\mathsf {M}$, and ciphertext space $\mathsf {C}$. Let $(\mathsf {E},\mathsf {D})$ be a tweakable block cipher with $\mathsf {T}= \mathsf {N}\times \mathsf {C}$, $\mathsf {X}= \mathsf {N}$, and key space $\mathsf {K}$. Let $\alpha \in \left\{ 0,1\right\} ^\tau$ be some pre-defined constant. Then define the separated AE scheme $(\mathsf {SEnc},\mathsf {SDec},\mathsf {SVer})$ as follows. The key space is $\mathsf {K}^2$, with keys denoted by (K, L), the nonce space is $\mathsf {N}$, the message space is $\mathsf {M}$, and the ciphertext space is $\mathsf {N}\times \mathsf {C}$:

$$\begin{aligned} \mathsf {SEnc}_{K,L}^N(M)&:=\Big (\mathsf {E}_L^{C}(N), C\Big ) \end{aligned}$$

(28)

$$\begin{aligned}&\text {with } C :=\mathsf {Enc}_K^N(\alpha \parallel M)\end{aligned}$$

(29)

$$\begin{aligned} \mathsf {SDec}_{K,L}(S, C)&:=\mathsf {lsb}_{\left|C\right|-\tau }\left( \mathsf {Dec}_K^{N'}(C)\right) \end{aligned}$$

(30)

$$\begin{aligned}&\text {with } N':=\mathsf {D}_L^{C}(S)\end{aligned}$$

(31)

$$\begin{aligned} \mathsf {SVer}_{K,L}(S, C)&:=\left( \mathsf {msb}_{\tau }\left( \mathsf {Dec}_K^{N'}(C)\right) \mathop {=}\limits ^{?} \alpha \right) \,. \end{aligned}$$

(32)

The construction is depicted in Fig. 2.

Fig. 2.

Adding RUP security to an existing encryption scheme. The circles indicate duplication of the value.

The construction adds robustness to the encryption scheme $(\mathsf {Enc},\mathsf {Dec})$ by compressing the ciphertext via the tweak of the tweakable block cipher, and using that information to encrypt the nonce. As a result, during decryption, if any bit of the ciphertext is modified, then the ciphertext will result in a different tweak with essentially probability one, and the tweakable block cipher will decrypt the nonce into some random value, which is used as the new nonce for $\mathsf {Dec}$. By assumption, $\mathsf {Dec}$ will output garbage, or more precisely, plaintext which is unrelated to any other plaintext queried.

Similarly, if the ciphertext is kept the same, and the encrypted nonce, S, is modified, then the tweakable block cipher will be queried on an input for which it has not been queried on before with the given tweak computed from the ciphertext. As a result, the decryption of S will be random, and $\mathsf {Dec}$’s output will look random as well.

With respect to authenticity, our construction follows the encode-then-encipher paradigm [9], which uses redundancy in the plaintext in order to guarantee authenticity. The level of authenticity is determined by the length of the constant $\alpha$: if verification can be removed, then $\alpha$’s length is set to zero. However, the only requirement from $\alpha$ is to be known to both sides, and users may use any predictable bits already present in the plaintext.

5.3 GCM-RUP

We illustrate an instantiation of the construction using familiar primitives, namely those used to construct GCM [49, 50]. The resulting instantiation uses three independent keys, but only makes three minor modifications to AES-GCM in order to achieve RUP security:

• 1. the plaintext is prepended by a string of zero bits of length $\tau$,

• 2. the nonce N instead of $\mathsf {GHASH}(\varepsilon , N)$ is used to generate the mask for the polynomial hash, and

• 3. the output of $\mathsf {GHASH}$ is XORed with the nonce before it is encrypted.

See Fig. 3 for an illustration.

Fig. 3.

Instantiation of our construction using GCM’s components. Changes from GCM are indicated using a dashed pattern, and the dotted boxes point out the underlying encryption scheme and tweakable block cipher. Filled circles indicate duplication of the values. $\mathsf {GH}$ is $\mathsf {GHASH}$, and $/_m$ indicates the number of bits on a wire. The value L is $E_{K_1}(0^n)$, and A represents associated data.

Appendix A.2 contains a description of the GCM components that we use to describe the instantiation, including the function $\mathsf {GHASH}$, defined in Algorithm 3, and CTR mode, defined in Algorithm 4. Note that our formalization above did not include associated data, whereas GCM-RUP does, however it is straightforward to extend the definitions and generic construction to include it.

Since the generic construction’s security relies on generating random nonce input during decryption, in order to maintain security up to the birthday bound on the block size, as is the case with GCM, the nonce size in the instantiation is fixed to be the same as the block size. The encryption scheme underlying the instantiation, $(\mathsf {Enc},\mathsf {Dec})$, is the same as GCM without authentication, or in other words CTR mode, therefore $\mathsf {Enc}$ and $\mathsf {Dec}$ are identical, and so the $\mathsf {SRND}$ quality of $(\mathsf {Enc},\mathsf {Dec})$ can be measured by looking only at $\mathsf {Enc}$-queries. This allows us to use the GCM confidentiality result of Niwa et al. [58, 59], which gives $(\mathsf {Enc},\mathsf {Dec})$ an $\mathsf {SRND}$-bound of

$$\begin{aligned} \frac{0.5(\sigma +q+d+1)^2}{2^n} + \frac{64\cdot q(\sigma +q+d)}{2^n}\,, \end{aligned}$$

(33)

where $\sigma$ is the total number of blocks queried, q the number of $\mathsf {Enc}$ queries, d the number of $\mathsf {Dec}$ queries, and the nonce length is n bits, which is the block size as well.

Security of the underlying tweakable block cipher follows from the XTX construction of Minematsu and Iwata [54], where we extend the tweak space of a block cipher to arbitrary tweak size by XORing $\mathsf {GHASH}$ to both the input and output of the block cipher. Hence the $\mathsf {SPRP}$-quality of the underlying tweakable block cipher is

$$\begin{aligned} \frac{q^2(\ell +1)}{2^n}\,, \end{aligned}$$

(34)

where q is the total number of queries made to the tweakable block cipher, and $\ell$ is the maximal tweak length, or in other words, the maximal ciphertext and associated data length in blocks.

Putting together the results along with the result of Appendix B, we get the following bound for the instantiation.

Theorem 1

Let $\mathbf {A}$ be a RUPAE-adversary against the instantiation making at most q $\mathsf {SEnc}$ queries, and v $\mathsf {SDec}$ and $\mathsf {SVer}$ queries. Say that at most $\sigma$ blocks are queried, with $\ell$ the maximum ciphertext and associated data block length of any query, then $\mathbf {A}$’s advantage is at most

(35)

If $q+v\le 2^{n-1}$, then since $q+v\le \sigma$, the bound can be simplified to

$$\begin{aligned} \frac{3\cdot 64\cdot \sigma ^2}{2^n} + \frac{\sigma ^2(\ell +1)}{2^n}\,, \end{aligned}$$

(36)

which is similar to GCM’s security bounds [38, 58].

Appendices

A     Algorithm Descriptions

In this section we provide descriptions of OCB, GCM, and ChaCha20+Poly1305. The descriptions are only given to the level of detail sufficient for the paper. The notation is borrowed various sources: the description of OCB by Rogaway, Bellare, and Black [65], the description of GCM by Iwata, Ohashi, and Minematsu [38], and the documents by Procter analyzing ChaCha20+Poly1305 [61, 62].

1.1 A.1    OCB

In this section we describe the OCB mode of operation [43, 64, 65]. We focus on OCB version 1 [65], however our results extend to all versions of OCB. We do not include associated data as we do not need it for the OCB attacks. The reference used for the figure, pseudocode, and notation below is from [65]. Let $E:\mathsf {K}\times \left\{ 0,1\right\} ^n\rightarrow \left\{ 0,1\right\} ^n$ be a block cipher and let $\tau$ denote the tag length, which is an integer between 0 and n. Let $\gamma _1,\gamma _2,\ldots$ be constants, whose values depend on the version of OCB used; for example, in OCB1 [65] these are Gray codes. Then Algorithm 2 gives pseudocode describing OCB encryption, and Fig. 4 provides an accompanying diagram.

1.2 A.2    GCM

In this section we describe the GCM mode of operation [49, 50] with nonces of 128 bit length. We let $E:\left\{ 0,1\right\} ^{128}\times \left\{ 0,1\right\} ^{128}\rightarrow \left\{ 0,1\right\} ^{128}$ denote a block cipher. The function $\mathsf {GHASH}$ is defined in Algorithm 3. Algorithm 5 provides pseudocode for GCM encryption, which also uses the keystream generator CTR mode in Algorithm 4. See Fig. 5 for an illustration.

Fig. 4.

The OCB mode of operation applied to a plaintext of length at most three blocks. The value L is $E_K(0^n)$ and $Z[3]' = Z[3]\oplus L\cdot \texttt {x}^{-1}$.

Fig. 5.

The GCM mode of operation with 128 bit nonces. $\mathsf {GH}$ is $\mathsf {GHASH}$ and $/_m$ indicates the number of bits on a wire. The value L is $E_{K}(\mathsf {str}_{n}(0))$.

1.3 A.3     ChaCha20+Poly1305

Our description of ChaCha20+Poly1305 is taken from the RFC [56] describing it, as well as Procter’s analysis [61, 62]. The combination of ChaCha20 [13] and Poly1305 [12] is similar to that of GCM, with the main differences being the fact that block cipher calls are replaced by ChaCha20’s block function calls, and the key for Poly1305 is generated differently.

The ChaCha20 block function is denoted by

$$\begin{aligned} \mathsf {CC}:\left\{ 0,1\right\} ^{256}\times \left\{ 0,1\right\} ^{32}\times \left\{ 0,1\right\} ^{96}\rightarrow \left\{ 0,1\right\} ^{512}\,, \end{aligned}$$

(37)

which operates on keys of length 256 bits, a block number of length 32 bits, a nonce of length 96 bits, and with an output of size 512 bits. The Poly1305 universal hash function is denoted by

$$\begin{aligned} \mathsf {Poly}: \left\{ 0,1\right\} ^{128}\times \left\{ 0,1\right\} ^*\rightarrow \left\{ 0,1\right\} ^{128}\,. \end{aligned}$$

(38)

The description of ChaCha20+Poly1305 encryption is given in Algorithm 6.

B     Formal Security Argument For The Generic Construction

We start by defining two reductions which use an adversary $\mathbf {A}$ playing the $\mathsf {RUPAE}$ game against the construction $\mathbb {S} = (\mathsf {SEnc},\mathsf {SDec},\mathsf {SVer})$. Let $\mathbb {B} = (\mathsf {E},\mathsf {D})$ denote the tweakable block cipher and $\mathbb {E} = (\mathsf {Enc},\mathsf {Dec})$ the encryption scheme. Furthermore, let $\$_{\mathbb {S}} = (\$_\mathsf {SEnc},\$_\mathsf {SDec},\bot )$, $\$_{\mathbb {B}} :=(\pi ,\pi ^{-1})$, where $(\pi ,\pi ^{-1})$ is from the definition of $\mathsf {SPRP}$ security in Eq. (26), and $\$_{\mathbb {E}} :=(\$_\mathsf {Enc},\$_\mathsf {Dec})$. Then we define the following two reductions:

• 1. A reduction $\mathbf {B}\langle \mathbf {A}\rangle$ to the $\mathsf {SPRP}$ quality of the tweakable block cipher $\mathbb {B}$, meaning $\mathbf {B}\langle \mathbf {A}\rangle$ will attempt to distinguish $\mathbb {B}$ from $\$_{\mathbb {B}}$, using $\mathbf {A}$, an algorithm which is expecting either $\mathbb {S}$ or $\$_{\mathbb {S}}$. The reduction $\mathbf {B}$ generates a key K independently, and uses K to simulate the encryption scheme $\mathbb {E}$. Then, $\mathbf {B}$ runs $\mathbf {A}$, and responds to $\mathbf {A}$’s queries by reconstructing $\mathbb {S}$ using its own oracles, either $\mathbb {B}$ or $\$_{\mathbb {B}}$, and the simulated $\mathbb {E}$.

• 2. A reduction $\mathbf {C}\langle \mathbf {A}\rangle$ to the $\mathsf {SRND}$ quality of the encryption scheme $\mathbb {E}$. In contrast with $\mathbf {B}$, the reduction $\mathbf {C}$ simulates $\$_{\mathbb {B}}$ instead of $\mathbb {B}$. Then using its own oracles, either $\mathbb {E}$ or $\$_{\mathbb {E}}$, and $\$_{\mathbb {B}}$, $\mathbf {C}$ reconstructs $\mathbb {S}$.

Theorem 2

The advantage of any nonce-respecting RUPAE adversary $\mathbf {A}$ attempting to distinguish $\mathbb {S}$ from $\$_{\mathbb {S}}$, making at most q $\mathsf {SEnc}$ queries, and at most v $\mathsf {SDec}$ and $\mathsf {SVer}$ queries, is bounded above by

$$\begin{aligned} 2\frac{v(q+v)}{\left|\mathsf {N}\right| - q - v} + \frac{v}{2^\tau } + \mathsf {SPRP}_{\mathbb {B}}(\mathbf {B}\langle \mathbf {A}\rangle ) + \mathsf {SRND}_{\mathbb {E}}(\mathbf {C}\langle \mathbf {A}\rangle ) \,. \end{aligned}$$

(39)

Proof

Let $\mathbb {S}[\varPi ,\varSigma ]$ denote $\mathbb {S}$ using $\varPi$ as tweakable block cipher and $\varSigma$ as encryption scheme. By definition, we seek to bound

$$\begin{aligned} \mathsf {RUPAE}(\mathbf {A}) = \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathbb {S}[\mathbb {B},\mathbb {E}]\,;\,\$_{\mathbb {S}}\right) \,. \end{aligned}$$

(40)

Applying the triangle inequality, we get

$$\begin{aligned} \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathbb {S}[\mathbb {B},\mathbb {E}]\,;\,\$_{\mathbb {S}}\right) \le \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathbb {S}[\mathbb {B},\mathbb {E}]\,;\,\mathbb {S}[\$_{\mathbb {B}},\mathbb {E}]\right) +\mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathbb {S}[\$_{\mathbb {B}},\mathbb {E}]\,;\,\$_{\mathbb {S}}\right) \end{aligned}$$

(41)

Using reduction $\mathbf {B}\langle \mathbf {A}\rangle$, we know that

$$\begin{aligned} \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathbb {S}[\mathbb {B},\mathbb {E}]\,;\,\mathbb {S}[\$_{\mathbb {B}},\mathbb {E}]\right) \le \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {B}\langle \mathbf {A}\rangle }\left( \mathbb {B}\,;\,\$_{\mathbb {B}}\right) \,. \end{aligned}$$

(42)

Therefore we can focus on

$$\begin{aligned} \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathbb {S}[\$_{\mathbb {B}},\mathbb {E}]\,;\,\$_{\mathbb {S}}\right) \end{aligned}$$

(43)

which in turn is bounded above by

$$\begin{aligned} \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathbb {S}[\$_{\mathbb {B}},\mathbb {E}]\,;\,\mathbb {S}[\$_{\mathbb {B}},\$_{\mathbb {E}}]\right) + \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathbb {S}[\$_{\mathbb {B}},\$_{\mathbb {E}}]\,;\,\$_{\mathbb {S}}\right) \,. \end{aligned}$$

(44)

The analysis of these two remaining terms relies on computing the probability that $\mathbf {A}$ makes a query which results in a nonce collision during a decryption query, thereby violating the $\mathsf {SRND}$ game’s requirement. In the analysis below, we find that the probability of such an occurence is at most

$$\begin{aligned} \varepsilon :=\frac{v(q+v)}{\left|\mathsf {N}\right|-q-v}\,. \end{aligned}$$

(45)

Therefore, using the reduction $\mathbf {C}\langle \mathbf {A}\rangle$ we know that the first term of Eq. (44) is bounded by

$$\begin{aligned} \varepsilon + \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {C}\langle \mathbf {A}\rangle }\left( \mathbb {E}\,;\,\$_{\mathbb {E}}\right) \,, \end{aligned}$$

(46)

and the bound for

$$\begin{aligned} \mathop {{{\mathrm{\Delta }}}}\limits _{\mathbf {A}}\left( \mathbb {S}[\$_{\mathbb {B}},\$_{\mathbb {E}}]\,;\,\$_{\mathbb {S}}\right) \end{aligned}$$

(47)

is given below.

Say that $\mathbf {A}$ generates $\mathsf {SEnc}$ inputs $(N_1,M_1)$, $(N_2,M_2)$, ..., $(N_q,M_q)$, and $\mathsf {SDec}$ and $\mathsf {SVer}$ inputs $(S_1,C_1)$, $(S_2,C_2)$, ..., $(S_v,C_v)$, where $(S_i,C_i)$ could be the input to either an $\mathsf {SDec}$ or $\mathsf {SVer}$ query. Let $N^*_i$ denote the nonce input to $\$_\mathsf {Dec}$ resulting from the query $(S_i,C_i)$, that is

$$\begin{aligned} N^*_i = \pi ^{-1,C_i}(S_i)\,. \end{aligned}$$

(48)

Similarly, define $M_i^*$ and $\alpha _i^*$ such that

$$\begin{aligned} \alpha _i^*\Vert M_i^* = \$_\mathsf {Dec}^{N_i^*}(C_i)\,. \end{aligned}$$

(49)

We call $N_i^*$, $M_i^*$, and $\alpha _i^*$ the “decrypted” nonces, plaintexts, and constants, respectively.

If the nonces $N_i$ and $N_j^*$ are distinct from each other then the $\mathsf {SRND}$ game’s requirement is respected, hence $\$_{\mathbb {E}}$ will always give uniformly distributed and independent output. Let $\mathsf {event}$ denote the event that either $N_i = N_j$ for $1\le i < j \le q$, or $N_i^* = N_j^*$ for $1\le i< j\le v$, or $N_i = N_j^*$ for $1\le i\le q$ and $1\le j\le v$. Then, by the fundamental lemma of game playing [10], Eq. (47) can be bounded by

(50)

where $\overline{\mathsf {event}}$ is the negation of $\mathsf {event}$. Given $\overline{\mathsf {event}}$, the nonce input to $\$_\mathsf {Dec}$ will always be distinct, hence the $\alpha _i^*$ are independent and uniformly distributed, which means the quantity on the right is bounded above by $v/2^\tau$.

Therefore we focus on the probability of $\mathsf {event}$, i.e. that there is a collision in the $N_i$ and $N_j^*$. By hypothesis, $\mathbf {A}$ is nonce-respecting, hence we know that $N_i\ne N_j$ for $1\le i < j\le q$. Therefore we focus on the case that a decrypted nonce collides with some $N_i$, or another decrypted nonce.

Consider the query $(S_i,C_i)$ associated to the ith decrypted nonce $N_i^*$, and say that $\mathsf {event}$ has not yet been triggered. Let $(N_j,M_j)$ be a previous $\mathsf {SEnc}$ query, and $(S_j,C_j)$ its corresponding output. By hypothesis, $(S_j,C_j)\ne (S_i,C_i)$. If $C_j\ne C_i$, then the tweak input to $(\pi ,\pi ^{-1})$ will be different for the $\mathsf {SEnc}$ and $\mathsf {SDec}$ or $\mathsf {SVer}$ queries, hence the probability that $N_i^*$ collides with $N_j$ is at most $1/\left|\mathsf {N}\right|$. If $C_j = C_i$, then $S_j\ne S_i$, which means that $(\pi ,\pi ^{-1})$ is queried under the same tweak for both the $\mathsf {SEnc}$ and $\mathsf {SDec}$ or $\mathsf {SVer}$ queries. However, the probability that

$$\begin{aligned} N_j = \pi ^{-1,C_j}(S_j) = \pi ^{-1,C_i}(S_i) = N_i^* \end{aligned}$$

(51)

is at most $1/(\left|\mathsf {N}\right| - q - v)$.

Now consider the probability that an $\mathsf {SEnc}$ query $(N_i,M_i)$ is such that $N_i$ equals $N_j^*$ for some previous $\mathsf {SDec}$ or $\mathsf {SVer}$ query. Since the adversary’s view is independent of $N_j^*$, it can guess $N_j^*$ with probability at most $1/(\left|\mathsf {N}\right| - q - v)$. Therefore, the probability that a decrypted nonce collides with some nonce $N_j$ is at most

$$\begin{aligned} \frac{qv}{\left|\mathsf {N}\right| - q - v}\,. \end{aligned}$$

(52)

Given that no decrypted nonces collide with any nonce $N_j$, we are left with the event that two decrypted nonces collide with each other. However, similar reasoning as above shows that this probability is bounded above by

$$\begin{aligned} \frac{v^2}{\left|\mathsf {N}\right| - q - v}\,, \end{aligned}$$

(53)

Putting the above computations together, if $\mathbf {A}$ makes q $\mathsf {SEnc}$ queries, and v $\mathsf {SDec}$ and $\mathsf {SVer}$ queries, then Eq. (47) is bounded above by

$$\begin{aligned} \frac{v(q + v)}{\left|\mathsf {N}\right| - q-v} + \frac{v}{2^\tau }\,. \end{aligned}$$

(54)

   $\square$

C     Application to Tor

The advantage in coming up with new, robust AE schemes is that they can then be used for applications which go beyond the traditional goals of ensuring data confidentiality and authenticity between two communicating parties. Consider for example Tor [23], which uses CTR mode [55] to ensure anonymity. CTR mode is a basic encryption scheme which provides data confidentiality, and no authenticity. In particular, its decryption algorithm provides no robustness to changes in its ciphertext: a change in the ith bit of ciphertext will result in the same change to the ith bit of the resulting plaintext. This property enables the crypto-tagging attack [73] against Tor, which breaches anonymity. Using an RAE [35] or encode-then-encipher [9, 71] scheme prevents the crypto-tagging attack, and potentially introduces a new level of robustness to Tor’s anonymity. Hence, the Tor community has initiated a search for replacements for CTR mode [48].

However, replacing CTR mode with known robust solutions not only comes at an efficiency cost, but also increased design, and hence implementation, complexity. This is because so far the only solutions provided for full robustness are essentially variable-input-length (VIL) ciphers [8], which can be viewed as block ciphers that can process arbitrarily long messages. However, VIL ciphers are “heavy” constructions, requiring often three or more passes over the plaintext in order to ensure sufficient mixing, or relying on subtle design choices to achieve security.

We now outline how our construction can be used in Tor to avoid the crypto-tagging attack [73]. Our intention is not to provide a detailed description, but to give a high-level overview.

1.1 C.1    Tor

Tor [23] is a circuit-based low-latency anonymous communication service. The core idea underlying Tor is onion routing, a distributed overlay network designed to anonymize TCP-based applications, presented by Syverson, Reed and Goldschlag in [72].

Generally speaking, Tor communication is encrypted and relayed by nodes in the Tor-network via circuits. When building circuits, clients exchange keys with several nodes, usually 3, where each node only knows its predecessor and successor.

Clients prepare messages using multiple layers of encryption. First, the message is encrypted using the key and nonce shared with the circuit’s last node. The resulting ciphertext is then encrypted again with the keys and nonce of the one-before-last node. This process is repeated for each node, until the first node’s key is used.

The output of the multi-layered encryption is then sent from the client to the first node, which decrypts one layer, and forwards the result to the next node. In every step, another layer of encryption is removed, and the message is passed forward, until it reaches the last node. The last node authenticates and forwards the message to the intended recipient outside of the Tor network.

1.2 C.2     The Crypto-tagging Attack

By design, the Tor protocol offers an end-to-end integrity check, which the exit node does by computing a SHA-1 digest of the decrypted message. Such a check prevents e.g., attacks by rogue nodes which “tag” the encrypted message, and then search outbound communication for the corresponding corrupted traffic.

In 2012, an anonymous email was sent to the Tor developers mailing list describing the crypto-tagging attack [73]. In this attack, two nodes, the entry and exit nodes, collude by tagging and untagging messages upon entry and exit to the network, respectively, thereby making the changes transparent to all other parties.¹ Due to the mode of operation used for encryption, CTR mode, the location of corrupt bits introduced at the entry to the network are maintained through all decryptions, and can be removed by the exit node by just knowing their location. Furthermore, since the integrity check is only performed by the exit node, the corruption cannot be detected by intermediate nodes in the circuit. Moreover, the attack is amplified by the fact that if only one of the nodes (i.e., either the entry node or the exit node) is malicious, the tagged message cannot be verified, and the circuit is destroyed. Any new circuit where only one of the nodes is malicious will also be destroyed, thus biasing the set of possible circuits towards compromised ones.

An obvious solution to this problem is to add an authentication tag to each layer of the encryption, allowing intermediate nodes to verify the data passed through them and act according to some policy. However, in the discussion following the attack, such a solution was ruled out due to two main problems: (i) by adding authentication tags, the available bandwidth for sending messages is reduced, and (ii) the circuit’s length could be revealed, an undesirable property in such systems.

1.3 C.3     Avoiding the Attack

We propose a different approach allowing intermediate nodes to release unverified plaintext, using the generic construction proposed in Sect. 5. The only change from the above procedure for preparing the message is how the nonces are chosen.

As before, clients start by encrypting the plaintext with the key and nonce of the last node using CTR mode. Then, the ciphertext is compressed and used as a tweak for the encryption of the nonce as per Fig. 2. Afterwards, the encrypted nonce, S, is used as the nonce for the next layer of encryption, i.e., with the keys of the one-before last node. This is repeated for each node of the circuit all the way to the first one. The result is a multi-layered application of our construction where the first layer receives the nonce and the plaintext as input, and each subsequent layer receives the previous layer’s output. The new RUP secure layered encryption mode of operation is presented in Fig. 6, where each layer can be realized using e.g., the robust version of GCM presented in Sect. 5.3 with $\left|\alpha \right| = 0$.

Fig. 6.

A RUP secure 3-node layered encryption. The three layers are distinguished by their keys: $(K_1,L_1), (K_2,L_2)$, and $(K_3,L_3)$.

When the message is ready, the client sends the ciphertext, along with the 3-times encrypted nonce to the first node. The first node uses the decryption algorithm as per Fig. 2 to remove the outermost encryption, and forwards the result, as well as the now 2-times encrypted nonce, to the next node. After the last layer of encryption has been removed by the last node, it authenticates the message and sends it to the intended recipient.

The security against an adversary trying to mount the crypto-tagging attack comes from the fact that any change to the ciphertext will affect the entire message, effectively decrypting it to garbage. In other words, once decrypted by a non-colluding node, the crypto-tag corrupts the nonce, which will then be used to decrypt the message into garbage. Using the Tor terminology, by the time the message reaches the exit node, the crypto-tag can no longer be removed and the message is unrecognizable and should thus be dropped and the circuit is torn down.

For example, consider a circuit with three nodes, and say that $(S_1,C_1)$, $(S_2,C_2)$, and $(S_3,C_3)$ are the outputs of the first, second, and third layers of encryption, respectively. In particular, the client uses (N, P) to produce $(S_1,C_1)$, then $(S_1,C_1)$ to produce $(S_2,C_2)$, and $(S_2,C_2)$ to produce $(S_3,C_3)$. Finally, $(S_3,C_3)$ is sent to the first node. Say that the first node is malicious, namely it decrypts $(S_3,C_3)$ and obtains $(S_2,C_2)$, then proceeds to tag $(S_2,C_2)$ and passes $(S_2',C_2')$ instead of $(S_2,C_2)$ as it is supposed to do. Then, assuming the second node is honest, it will follow the protocol and decrypt $(S_2',C_2')$. However, by the properties of our construction, we know that the decryption will be random since $(S_2,C_2) \ne (S_2',C_2')$, and in particular, the first node will not be able to predict anything about $(S_1',C_1')$, i.e., the decryption of $(S_2',C_2')$. As a result, the second node will pass $(S_1',C_1')$ to the third node, and the third node will not be able to conclude anything, regardless of whether it shares information with the first node or not. In particular, it would not be able to conclude the source and the destination of the message.

The disadvantage to our approach is that 16 extra bytes must be expropriated to send the encrypted nonce S. However, unlike adding per-hop authentication tags, the reduction in available bandwidth to send messages is fixed, and does not change according to the circuit length. Furthermore, the solution can be built efficiently using familiar components, and is simple enough to allow for fast deployment.