Keywords

1 Introduction

Authenticated encryption is a very useful cryptographic primitive that provides both privacy and authenticity when sending data. It is a handy component for many security engineers and protocol designers as it avoids for example the classical threat of a misinterpretation of the privacy-only security provided by a simple encryption mode. The encryption algorithm usually takes as input a plaintext P, some public associated data AD, a public nonce value IV, a secret key K, and it outputs a ciphertext C and a tag value T. Conversely, the decryption algorithm usually takes as input a ciphertext C, a tag value T, some public associated data AD, a public nonce value IV, a secret key K, and outputs either the original plaintext P or an error flag if the authentication process is not valid. Using an encryption scheme for the privacy part and a MAC for the authenticity part is a possible way to obtain authenticated encryption, but the goal of the ongoing CAESAR competition [5] is to push to the industry a single primitive providing both properties at the same time, with a single core function, which would potentially permit faster and simpler solutions.

JAMBU is an nonce-based authenticated encryption operating mode proposed by Wu and Huang [14], that can be instantiated with any block cipher. Yet, the submission AES-JAMBU to the CAESAR competition uses AES-128  [6] as internal block cipher. The main advantage of JAMBU mode is its low memory requirement, which places it in the group of lightweight authenticated encryption modes. Indeed, when instantiated with a 2n-bit block cipher and without counting the memory needed to store the secret key, JAMBU will only require to maintain a 3n-bit internal state, where classical authenticated encryption modes like OCB  [9, 11] would require a 6n-bit internal state or even more. In terms of speed performances, AES-JAMBU is reasonably fast, being about twice slower than AES-CBC  [13] (but much slower than OCB since the calls to the internal cipher cannot be parallelized).

The security claims of JAMBU are given in the CAESAR competition submission document [14]. When instantiated with a 2n-bit block cipher, JAMBU processes plaintext blocks of n bits and eventually outputs an n-bit tag T. When the nonce is not reused, JAMBU is claimed to provide 2n-bit security for confidentiality and n-bit security for authentication. When the nonce is misused (i.e. several encryptions can be performed with the same nonce), JAMBU is claimed to remain reasonably strong. More precisely, in that scenario, the confidentiality of JAMBU is supposed to be only partially compromised as the authors claim that “it only leaks the information of the first block or the common prefix of the message”. Regarding authentication in the nonce-misuse scenario, the authors remain vague, only mentioning that “the integrity of JAMBU will be less secure but not completely compromised”.

Our Contribution. In this article, we first describe a very practical attack on JAMBU that breaks its confidentiality claim in the nonce-misuse scenario. More precisely, with only \(2^{n/2}\) encryption queries and computing time (which amounts to \(2^{32}\) for AES-JAMBU), we are able to predict the value of a ciphertext block corresponding to a chosen plaintext whose prefix has never been queried to the encryption oracle before, which invalidates the designers’ 2n-bit security claim.

Our attack works by trying to force a zero-difference on the input of one of the internal block cipher calls of JAMBU. Normally, forcing such a collision on a 2n-bit value should require \(2^n\) computations, but thanks to a divide-and-conquer technique, we are able to divide this event in two subparts, for a total cost of \(2^{n/2}\) computations. Having a collision on one of the internal block cipher calls will render this particular JAMBU round totally linear with regards to differences, and will eventually allow us to predict a ciphertext block for the next round.

Then, because of the rather small tag size of JAMBU, we are able to extend our technique to the more interesting case of a nonce-respecting attacker. More precisely, with \(2^{3n/2}\) computations (which amounts to \(2^{96}\) for AES-JAMBU), one can break JAMBU ’s confidentiality in the adaptive chosen-ciphertext model, with message prefixes not previously queried.

We first describe JAMBU authenticated encryption mode in Sect. 2 and then explain our nonce-misuse scenario attack in Sect. 3, while the nonce-respecting attack will be presented in Sect. 4. Finally, in order to confirm our claims, we have implemented the nonce-misuse attack on AES-JAMBU as detailed in Sect. 5. We remark that our techniques will work independently of the cipher instantiating the JAMBU mode, yet in the rest of this article we will focus on AES-JAMBU for ease of description.

2 The JAMBU Authenticated Encryption Scheme

2.1 Description of JAMBU

JAMBU uses a k-bit secret key K and an n-bit public nonce value IV to authenticate a variable length associated data AD and to encrypt and authenticate a variable length plaintext P. It produces a ciphertext C, which has the same bit length with plaintext, and an n-bit tag T.

The encryption process of JAMBU consists of 5 phases as described below: padding, initialization, processing of the associated data, processing of the plaintext, and finalization/tag generation. The computation structure is illustrated in Figs. 1, 2 and 3, where each line represents an n-bit value. We will represent the 3n-bit internal state of JAMBU by the variables \((S_i,\,R_i)\) with \(S_i=(U_i,V_i)\), where \(R_i\), \(U_i\) and \(V_i\) are n-bit values. We will denote by \(E_K\) the internal cipher using the secret key K.

Padding. First, the associated data AD is padded with 10* padding: a ‘1’ bit is appended to the data, followed by the least number of ‘0’ bits (possibly none) to make the length of the padded associated data become a multiple of n bits. Then, the same padding method is applied to the plaintext.

Initialization. As depicted in Fig. 1, JAMBU uses an n-bit public nonce value IV to initialize the internal state: \(S_0=E_K(\mathtt 0 ^n \Vert IV) \oplus (\mathtt 0 ^{2n-3} \Vert \mathtt 101 )\), where \(\Vert \) denotes concatenation, and \(R_0=U_0\).

Processing of the Associated Data. The padded associated data is divided into n-bit blocks, and then processed block by block as described in Fig. 1. Note that a single padded block \(\mathtt 1 ||\mathtt 0 ^{n-1}\) will be processed in the case of an empty associated data string. We omit the details of this phase since it is irrelevant to our attack. Moreover, in the rest of the article we will only use empty AD strings, so we get \(S_1=(U_{1},V_{1})=E_K(S_0) \oplus (\mathtt 1 || \mathtt 0 ^{2n-2} || \mathtt 1 )\) and \(R_1=R_{0} \oplus U_1\).

Fig. 1.
figure 1

Initialization and processing of the associated data

Processing of the Plaintext. We denote by p the number of plaintext blocks after padding and \(P=(P_{1},P_{2}, \ldots ,P_{p})\). The plaintext is processed block by block as depicted in Fig. 2. At round i, the internal state is updated with the plaintext block \(P_i\) by \(S_{i+1}=(U_{i+1},V_{i+1}) = E_K(S_i) \oplus (P_i || R_i)\) and \(R_{i+1} = R_{i} \oplus U_{i+1}\). The ciphertext block \(C_i\) is then computed with \(C_i = P_i \oplus V_{i+1}\).

Fig. 2.
figure 2

Processing of the plaintext

Finalization and Tag Generation. When all the plaintext blocks are processed, the final state is \((S_{p+1},\,R_{p+1})\). The authentication tag T is generated with two internal block cipher calls, as depicted in Fig. 3.

Fig. 3.
figure 3

Finalization and tag generation

2.2 Security Claims

The security claims of JAMBU are given in the CAESAR competition submission document [14]. When the nonce is not reused, JAMBU is claimed to provide 2n-bit security for confidentiality and n-bit security for authentication. We note that the type of confidentiality security (i.e. IND-CPA, IND-CCA1 or IND-CCA2) is not mentioned by the designers. When the nonce is misused (i.e. several encryptions can be performed with the same nonce), JAMBU is claimed to remain reasonably strong. Namely, in that scenario, the confidentiality of JAMBU is supposed to be only partially compromised as the authors claim that it only leaks the information of the first block or the common prefix of the message. Regarding authentication in the nonce-misuse scenario, the authors remain vague, only mentioning that “the integrity of JAMBU will be less secure but not completely compromised”. We summarize in Table 1 the security claims of the CAESAR competition candidate AES-JAMBU where \(n=64\). We remark that as with many authenticated encryption schemes, if verification fails during decryption the new tag and the decrypted plaintext should not be given as output. Moreover it is also important to note that the total amount of message material (plaintext and associated data) that can be protected by a single key is limited to \(2^{64}\) bits for AES-JAMBU.

Table 1. Security claims for AES-JAMBU.

3 Attack on JAMBU in Nonce-Misuse Scenario

In this section, we analyze JAMBU in the nonce-misuse attack model, where a nonce can be used to encrypt multiple plaintexts. In such a model, JAMBU is an online authenticated encryption scheme, namely the i-th ciphertext block is produced before the \(i+1\)-th plaintext block is read. An inherent property of online authenticated encryption is that common prefix plaintext blocks always produce the same corresponding ciphertext blocks. According to the security claims of JAMBU  [14], the only compromised confidentiality security from the nonce-respecting model to the nonce-misuse model is this additional inherent property as becoming an online authenticated encryption in the latter model.

However, we present here a practical attack to distinguish JAMBU from a random online authentication encryption, which invalidates the designers’ confidentiality security claims of JAMBU in the nonce-misuse model.

3.1 Confidentiality of Online Authenticated Encryption

For an online encryption scheme \((\mathcal {E}_K, \mathcal {D}_K)\) with a key space \(\mathcal {K}\), its confidentiality security is usually defined via upper bounding the advantage of all chosen-plaintext distinguishers.Footnote 1 We give a brief description as follows, and refer interested readers to [1, 7] for the full formal definitions. Let \(\mathcal {OAE}\) denote the set of all online authenticated encryption algorithms that have the same block and tag size with \((\mathcal {E}_K, \mathcal {D}_K)\). Let \((\mathtt{OEnc}, \mathtt{ODec}) \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathcal {OAE} \) denote an algorithm randomly selected from \(\mathcal {OAE} \). Let \(\mathbb {D} \) be a distinguisher that interacts with \(\mathcal {E}_K\) or \(\mathtt{Enc}\), and outputs one bit. Its advantage is defined as:

$$ \mathbf {Adv}_{\mathcal {E}}^{\mathrm {cpa}}(\mathbb {D}) := \Pr \left[ K \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathcal {K}, \mathbb {D} ^{\mathcal {E}_K} \Rightarrow 1 \right] - \Pr \left[ (\mathtt{OEnc}, \mathtt{ODec}) \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathcal {OAE}, \mathbb {D} ^{\mathtt{OEnc}} \Rightarrow 1 \right] . $$

Then we define \(\mathbf {Adv}_{\mathcal {E}}^{\mathrm {cpa}}(t, q, \sigma , \ell ) := \max _{\mathbb {D}} \mathbf {Adv}_{\mathcal {E}}^{\mathrm {cpa}}(\mathbb {D})\), where the maximum takes over all distinguishers that run in time t and make q queries, each of length at most \(\ell \) blocks and of total length at most \(\sigma \) blocks.

3.2 Attack Overview

Our attack is based on an observation that we explain below. JAMBU maintains a 3n-bit internal state, but uses only one invocation to a 2n-bit block cipher \(E_K\) to update it per plaintext block. Thus, there are always n state bits per round which are not updated through the strong primitive (i.e. the underlying block cipher). More precisely, every round \(S_i= (U_i, V_i)\) is input to the block cipher: \((X_{i}, Y_{i})=E_K(S_i)\). On the other hand, \(R_i\) is linearly injected into the updated state as \(V_{i+1}= Y_i \oplus R_i\). Furthermore, if a pair of plaintexts satisfying \(\varDelta S_i = 0\) is found, then the state differences in two consecutive rounds are linearly related, i.e., \(\varDelta V_{i+2} = \varDelta R_{i}\), which will be exploited by our cryptanalysis.

Overall, our attack can be divided into three parts. First the attacker will try to build a special difference structure in the internal state by querying the encryption of a fixed messageFootnote 2 with several different nonces. Then, using this special differential structure, he will try to recover the values of these internal differences and at the same time force a zero-difference on the input of one of the internal cipher calls. Finally, based on this differential structure that is now fully known and controlled, he will be able to distinguish \(\mathtt{JAMBU} \) from a random online authenticated encryption, and further forge some ciphertext blocks for a message that has never been queried before.

3.3 First Step

For the first step, the attacker picks a random n-bit message block \(P_1\), and asks for the encryption of this message for \(2^{n/2}\) distinct nonce values. Since the corresponding ciphertext blocks are also n-bit long, the attacker will have a good chance to observe a collision on the block \(C_1\). We denote IV and \(IV'\) the two nonces leading to that collision. One can easily see from Fig. 4 that since no difference is inserted in the block \(P_1\), a collision on \(C_1\) necessarily means that we have a collision on the difference value of the upper branch and lower branch of the internal state (i.e. the difference values in \(R_1\) and in \(Y_1\) are equal). We denote that difference by \(\varDelta _R\), and we denote the random difference in \(X_1\) by \(\varDelta _S\). We remark that for this first attack step, we do not need to reuse any nonce value.

Fig. 4.
figure 4

The first step of the attack.

3.4 Second Step

In the second step, the goal will be to deduce the value of \(\varDelta _S\) and \(\varDelta _R\) which remain unknown at this moment. In order to achieve this, the attacker will now try to insert a difference in \(P_1\) in a hope that it will be equal to \(\varDelta _S\). If his choice is right, one can see from Fig. 5 that he will cancel the difference in \(U_2\) and that the difference appearing on the next ciphertext block \(C_2\) (for a plaintext block \(P_2\) without difference) will necessarily be \(\varDelta _R\). A key observation is that since no difference will be present any more on the input of the incoming block cipher call, the difference on \(C_2\) will remain \(\varDelta _R\) whatever the choice on the value of \(P_1\). To summarize, if the attacker adds the difference \(\varDelta _S\) in \(P_1\), then the difference in \(C_2\) will remain the same (i.e. \(\varDelta _R\)) whatever the value of \(P_1\) is. This behavior is what the attacker will use to detect when he makes the right choice for the difference insertion in \(P_1\).

Fig. 5.
figure 5

The second step of the attack.

The detailed procedure to find \(\varDelta _S\) is as follows. Firstly, the attacker constructs two tables as depicted in Fig. 6, each having \(2^{n/2}\) three-tuples of one-block plaintexts, such that all pairs created by taking one element from each of these two tables will correspond to all the \(2^{n}\) possible differences on a n-bit value. More precisely, let \(\langle i \rangle \) denote the integer i in a n / 2-bit binary representationFootnote 3. One table \(\mathcal {T}_1\) is \(\{ \, ( \, \langle 0 \rangle \Vert \langle i \rangle ,\) \(\langle 1 \rangle \Vert \langle i \rangle ,\) \(\langle 2 \rangle \Vert \langle i \rangle \, ) \, \}\), where i ranges over all n / 2-bit values.Footnote 4 We denote by \(( \, \langle 0 \rangle \Vert \langle i \rangle ,\) \(\langle 1 \rangle \Vert \langle i \rangle ,\) \(\langle 2 \rangle \Vert \langle i \rangle \, )\) the i-th element of \(\mathcal {T}_1\). The other table \(\mathcal {T}_2\) is \(\{\, ( \, \langle j \rangle \Vert \langle 0 \rangle \), \(\langle 1 \oplus j \rangle \Vert \langle 0 \rangle \), \(\langle 2 \oplus j \rangle \Vert \langle 0 \rangle \,) \, \}\), where j ranges over all n / 2-bit values. Similarly we denote the j-th element of \(\mathcal {T}_2\) by \(( \, \langle j \rangle \Vert \langle 0 \rangle \), \(\langle 1 \oplus j \rangle \Vert \langle 0 \rangle \), \(\langle 2 \oplus j \rangle \Vert \langle 0 \rangle \, )\). The pairwise differences between \(\mathcal {T}_1\) and \(\mathcal {T}_2\) are \(\{ \, ( \, \langle 0 \rangle \Vert \langle i \rangle \,) \oplus (\, \langle j \rangle \Vert \langle 0 \rangle \,) = \langle j \rangle \Vert \langle i \rangle \, \}\), where i and j independently range over all n / 2-bit values. Thus, one can see that it covers all the possible differences of one-block n-bit plaintext. In particular, although each element is a 3-tuple of plaintexts and hence each pair consist of three n-bit differences by XORing the corresponding plaintexts, these differences are all equal, i.e., \(( \, \langle 0 \rangle \Vert \langle i \rangle \, ) \oplus (\, \langle j \rangle \Vert \langle 0 \rangle \,) = ( \, \langle 1 \rangle \Vert \langle i \rangle \, ) \oplus (\, \langle 1 \oplus j \rangle \Vert \langle 0 \rangle \,)= ( \, \langle 2 \rangle \Vert \langle i \rangle \, ) \oplus (\, \langle 2 \oplus j \rangle \Vert \langle 0 \rangle \,). \)

Fig. 6.
figure 6

The tables \(\mathcal {T}_1\) and \(\mathcal {T}_2\). An example of element pair for difference \(\langle j \rangle \Vert \langle i \rangle \).

Secondly, the attacker selects a random one-block plaintext \(P_2\). For each element \(( \, \langle 0 \rangle \Vert \langle i \rangle ,\) \(\langle 1 \rangle \Vert \langle i \rangle ,\) \(\langle 2 \rangle \Vert \langle i \rangle \,)\) in table \(\mathcal {T}_1\), he uses separately the three plaintext block values as the first block \(P_1\), concatenates them with \(P_2\) as the second block, and makes three encryption queries with the nonce IV to receive the three corresponding ciphertexts. Then, the attacker computes the pairwise differences on the second block of these ciphertexts. In details, let \(C[ \langle 0 \rangle \Vert \langle i \rangle ]_2\), \(C[ \langle 1 \rangle \Vert \langle i \rangle ]_2\) and \(C[ \langle 2 \rangle \Vert \langle i \rangle ]_2\) denote the second ciphertext blocks corresponding to \(\langle 0 \rangle \Vert \langle i \rangle \Vert P_2\), \(\langle 1 \rangle \Vert \langle i \rangle \Vert P_2\) and \(\langle 2 \rangle \Vert \langle i \rangle \Vert P_2\) respectively. The attacker computes the following two n-bit differences and stores them.

$$\begin{aligned} \varDelta C[\langle i \rangle ]_{1} = C[ \langle 1 \rangle \Vert \langle i \rangle ]_2 \oplus C[ \langle 0 \rangle \Vert \langle i \rangle ]_2,&\,\,\,\,\, \varDelta C[\langle i \rangle ]_{2} = C[ \langle 2 \rangle \Vert \langle i \rangle ]_2 \oplus C[ \langle 0 \rangle \Vert \langle i \rangle ]_2. \end{aligned}$$

Similarly, for each element of the second table \(\mathcal {T}_2\), the attacker makes encryption queries with the above \(P_2\) as the second block and \(IV'\) as the nonce to receive the ciphertexts, and then computes the pairwise differences of the second ciphertext blocks, denoted as (\(\varDelta C'[\langle i \rangle ]_{1}\), \(\varDelta C'[\langle i \rangle ]_{2}\)). Then he matches the differences to previously stored \(\{\, (\varDelta C[\langle i \rangle ]_{1}\), \(\varDelta C[\langle i \rangle ]_{2})\, \}\). Once a matched pair is found, the attacker computes \(\varDelta _R\) and \(\varDelta _S\) from the corresponding plaintexts and ciphertexts as follows

$$\begin{aligned} \varDelta _R = C[ \langle 0 \rangle \Vert \langle i \rangle ]_2 \oplus C'[ \langle j \rangle \Vert \langle 0 \rangle ]_2,&\,\,\,\,\, \varDelta _S = (\, \langle 0 \rangle \Vert \langle i \rangle \,) \oplus ( \, \langle j \rangle \Vert \langle 0 \rangle \,) = \langle j \rangle \Vert \langle i \rangle . \end{aligned}$$

If the attacker does not find a match after running all elements in \(\mathcal {T}_2\), he outputs 0.

Now we evaluate the success probability of this step if the attacker interacts with \(\mathtt{JAMBU} \). For a pair \((\langle 0 \rangle \Vert \langle i \rangle ) \Vert P_2\) with nonce IV and \((\langle j \rangle \Vert \langle 0 \rangle ) \Vert P_2\) with nonce \(IV'\), if \(\varDelta _S = \langle j \rangle \Vert \langle i \rangle \), we have that \(C[ \langle 0 \rangle \Vert \langle i \rangle ]_2 \oplus C'[ \langle j \rangle \Vert \langle 0 \rangle ]_2 =\varDelta _R\) as explained in Sect. 3.2. Similarly, we have that \(C[ \langle 1 \rangle \Vert \langle i \rangle ]_2 \oplus C'[ \langle 1 \oplus j \rangle \Vert \langle 0 \rangle ]_2 =\varDelta _R\) and \(C[ \langle 2 \rangle \Vert \langle i \rangle ]_2 \oplus C'[ \langle 2 \oplus j \rangle \Vert \langle 0 \rangle ]_2 =\varDelta _R\). Then, we further deduce that

With an identical reasoning, we deduce that \(\varDelta C[\langle i \rangle ]_{2} = \varDelta C'[\langle j \rangle ]_{2}\). On the other hand, if \(\varDelta _S \ne \langle j \rangle \Vert \langle i \rangle \), the pair of the i-th element from \(\mathcal {T}_1\) and the j-th element from \(\mathcal {T}_2\) will have to satisfy the two n-bit equality conditions randomly, which will happen with probability \(2^{-2n}\). Since there are in total \(2^{n}\) such pairs, the probability of faulty positive pairs is negligible. Hence, the attacker gets the correct values of \(\varDelta _S\) and \(\varDelta _R\) with a probability very close to 1.

3.5 Third Step

Finally, in the third and last step, the attacker will choose a random one-block value \(P_1\) such that \(P_1\) and \(P_1 \oplus \varDelta _S\) have never been queried before as first plaintext block (he can simply keep track of the previously queried \(P_1\) values). Then, he will pick a random value for the second plaintext block \(P_2\) and ask the encryption of the message \((P_1 || P_2)\) with the nonce IV. He receives ciphertext blocks \(C_1\) and \(C_2\) from the encryption oracle. Then the attacker asks the encryption of another message \((P_1 \oplus \varDelta _S \Vert P_2)\) with the nonce \(IV'\), and receives ciphertext blocks \(C'_1\) and \(C'_2\). Then he computes \(C_2 \oplus C'_2\), and compares it to \(\varDelta _R\). If \(C_2 \oplus C'_2 = \varDelta _R\) holds, the attacker outputs 1. Otherwise, the attacker outputs 0.

One can easily evaluate the advantage of the attacker. For JAMBU, he will output 1 with a probability equal to 1. On the other hand, for a random authenticated encryption, he outputs 1 with a probability of \(2^{-n}\). Therefore, the advantage of the attacker is almost 1.

3.6 Attack and Complexity Summary

To summarize, our attack requires in total about \(O(2^{n/2})\) encryption queries and computations, and can be divided into three parts:

  • first step (\(2^{n/2}\) encryption queries and computations): the attacker picks a plaintext block \(P_1\) and queries encryption of this block for \(2^{n/2}\) distinct nonces. He keeps the nonce pair \((IV,IV')\) that leads to a collision on the ciphertext block \(C_1\).

  • second step (\(O(2^{n/2})\) encryption queries and computations): the attacker picks a random second plaintext block \(P_2\) and a random n / 2-bit value I and queries the encryption of the \(2^{n/2}\) plaintext blocks \(P_1=(\mathtt 0 ^{n/2} \Vert I )\) concatenated with \(P_2\) with nonce IV and the encryption of the \(2^{n/2}\) plaintext blocks \(P_1=(I \Vert \mathtt 0 ^{n/2})\) concatenated with \(P_2\) with nonce \(IV'\). He repeats the process with a few other constant values instead of \(\mathtt 0 ^{n/2}\) in order to improve the filtering, and he eventually deduces the value of \(\varDelta _S\) by checking which difference applied in \(P_1\) leads to the same difference in \(C_2\) whatever is the choice of I. He directly deduces that this difference on \(C_2\) is actually \(\varDelta _R\).

  • third step (2 encryption queries and computations): the attacker picks a random value \(P_1\) such that \(P_1\) and \(P_1 \oplus \varDelta _S\) have never been queried before, and asks the encryption oracle for the ciphertext corresponding to the message \((P_1 || P_2)\) with nonce IV. He receives \((C_1 || C_2)\). Then he queries the encryption of \((P_1 \oplus \varDelta _S \Vert P_2)\) with nonce \(IV'\) and receive \((C'_1 \Vert C'_2)\). Finally he checks if \(C'_2 \oplus C_2 = \varDelta _R\) holds.

We remark that for JAMBU-AES  [14], we have \(n=64\) and thus the confidentiality security is only around 32 bits in the nonce-misuse attack model. Thus, our cryptanalysis invalidates the confidentiality claims of the JAMBU designers.

3.7 Extension to a Plaintext-Recovery Attack

Our distinguishing attack can be extended to a more powerful plaintext-recovery attack in a straightforward way. The setting is as follows. Note that our attack is in the chosen-plaintext model, and hence the attacker requires only the encryption algorithm of JAMBU. In other words he is given access to an encryption oracle of JAMBU instantiated with a randomly selected key that is secret to the attacker. He is allowed to query any plaintext of his own choice and gets the corresponding ciphertext. In the end, the attacker is required to choose a new (nonce, ciphertext) pairFootnote 5 and to produce a corresponding plaintext for it. If the plaintext is indeed valid and if the prefix to its last block has never been queried before, then the plaintext-recovery attack is said to succeed (the reason of these restrictions is detailed in the discussion on trivial attacks in Sect. 3.8).

The procedure is as follows and it also has three steps. The first two steps are exactly the same as the first two steps of the distinguishing attack detailed in Sects. 3.3 and 3.4, and we adopt the same notations. In the third and last step, the attacker will choose a random value \(P_1\) such that \(P_1\) and \(P_1 \oplus \varDelta _S\) have never been queried before as first plaintext block under the nonce IV and \(IV'\). Then, he will pick a random value for the second plaintext block \(P_2\) and ask the encryption of the message \((P_1 || P_2)\) with the nonce IV. He receives ciphertext blocks \(C_1\) and \(C_2\) from the encryption oracle. Since he knows the value of \(\varDelta _R\) and \(\varDelta _S\), he will be sure that if he applies the difference \(\varDelta _S\) on \(P_1\) with nonce \(IV'\), he will get difference \(\varDelta _S\) on \(C_1\) and difference \(\varDelta _R\) on \(C_2\). Therefore, he can predict the plaintext \((P_1 \oplus \varDelta _S, P_2 \oplus \varDelta _R)\) corresponding to ciphertext \((C_1 \oplus \varDelta _S || C_2)\) with nonce \(IV'\). Moreover, it is easy to see that \((C_1 \oplus \varDelta _S || C_2)\) is not a prefix of any of previous returned ciphertext of the encryption of JAMBU, since the first ciphertext block is a permutation of the first plaintext block under the same nonce, and since \(P_1 \oplus \varDelta _S\) has not been queried before as the first plaintext block under \(IV'\) to the encryption oracle. One might argue that \(P_1\) is the first plaintext block and this is included in the security exclusions in the JAMBU security claims. However, we have used \(P_1\) for simplicity of description, but the attack remains the same with any amount of random message blocks prepended to \(P_1\).

The complexity of the above plaintext-recovery attacks is also \(O(2^{n/2})\) encryption queries and computations. The success probability is almost 1 (we omit the detailed evaluation since it is similar to the distinguishing attack).

3.8 Discussion on Trivial Attacks

Recently, Rogaway claimed a generic plaintext-recovery attack on online authenticated encryption in the nonce-misuse setting [10]. His attack adopts divide-and-conquer strategy and recovers the plaintext block by block. In details, the attacker uses the recovered first \(i-1\) plaintext blocks as prefix, guesses the i-th plaintext block, and verifies the correctness by sending it to encryption oracle and comparing the received i-th ciphertext block with the i-th target ciphertext block. However, obviously this attack essentially just reveals again the inherent weakness of online authenticated encryption that has been known before and has been also explicitly pointed out by the designer of JAMBU: common prefix plaintext blocks produces the same corresponding ciphertext blocks. In particular, the attacker has to query a plaintext to the encryption oracle, then receive a ciphertext that is exactly the same as the target ciphertext, and then output this plaintext as the correct plaintext. As a comparison, in our plaintext recovery setting, we explicitly exclude such rather trivial attacks by restricting that the last block of the target ciphertext (or plaintext) must not share its prefix with any previously returned ciphertext from the encryption oracle.

One can also think of the following trivial distinguishing attack on JAMBU and several other CAESAR candidates. For an ideal online authenticated encryption as defined in [1, 7], the i-th plaintext block should be input to a random permutation to produce the i-th ciphertext block, where the index of the random permutation is determined by the nonce, the associated data and the first \(i-1\) plaintext blocks. On the other hand, for JAMBU the i-th plaintext block is simply XORed to an internal state: \(C_i = P_i \oplus V_{i+1}\), where the value of \(V_{i+1}\) is determined by the nonce, the associated data and the first \(i-1\) plaintext blocks. Hence, \(\varDelta C_i = \varDelta P_i\) always holds under the same nonce, the same associated data and the same first \(i-1\) plaintext blocks. In details, an attacker queries a nonce IV and a one-block plaintext \(P_1\) to the encryption oracle, and receives a ciphertext \(C_1\). He then queries the same nonce IV and another one-block plaintext \(P'_1\) to the encryption, and receives a ciphertext \(C'_1\). If \(C_1 \oplus C'_1 = P_1 \oplus P'_1\) holds, the attacker outputs 1. Otherwise, he outputs 0. This distinguishing attack can trivially be extended to a plaintext-recovery attack on single-block ciphertexts.

As a comparison, our attacks reveal a specific weakness of JAMBU: when processing plaintext blocks, it uses only one invocation to a small block cipher (2n bits) to update a larger state (3n bits). Such a design choice obviously favours efficiency, but our attacks imply that there is a greater security compromise to pay than originally expected by the JAMBU designers.

4 Attack on JAMBU in Nonce-Respecting Scenario

In this section, we analyse the confidentiality security of JAMBU in the nonce-respecting scenario. JAMBU claims a 2n-bit confidentiality security (or 128-bit security for AES-JAMBU) in this setting. However, the claim statement does not contain any specification on the attack model considered (IND-CPA, IND-CCA1 or IND-CCA2). Hence, one may wonder if JAMBU can achieve such a confidentiality security level under all (previously known) attack modelsFootnote 6. We note that the adaptive chosen-ciphertext security (IND-CCA2) of JAMBU can be trivially broken with \(2^{n}\) queries by reusing messages with common prefixes (see Sect. 4.4). However, our distinguishing attack works with prefixes not previously queried. Furthermore, our method can be extended to a more powerful plaintext-recovery attack.

4.1 Confidentiality Under an Adaptive Chosen-Ciphertext Attack

For an authenticated encryption scheme \((\mathcal {E}_K, \mathcal {D}_K)\) with a key space \(\mathcal {K}\), its confidentiality security under adaptive chosen-ciphertext attacks has been defined in [2], usually referred to as IND-CCA2. Here we provide a brief description, and refer interested readers to [2] for the full formal definition. Let \(\mathcal {RO}\) denote a random oracle that has the same output bit length as \(\mathcal {E}_K\) on every input plaintext. Let \(\mathbb {D} \) be a distinguisher that interacts with \((\mathcal {E}_K, \mathcal {D}_K)\) or \((\mathcal {RO}, \mathcal {D}_K)\), and outputs one bit. Its advantage is defined as:

$$ \mathbf {Adv}_{\mathcal {E}}^{\mathrm {cca2}}(\mathbb {D}) := \Pr \left[ K \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathcal {K}, \mathbb {D} ^{\mathcal {E}_K, \mathcal {D}_K} \Rightarrow 1 \right] - \Pr \left[ K \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathcal {K}, \mathbb {D} ^{\mathcal {RO}, \mathcal {D}_K} \Rightarrow 1 \right] . $$

Then we define \(\mathbf {Adv}_{\mathcal {E}}^{\mathrm {cca2}}(t, q, \sigma , \ell ) := \max _{\mathbb {D}} \mathbf {Adv}_{\mathcal {E}}^{\mathrm {cca}}(\mathbb {D})\), where the maximum is taken over all distinguishers that run in time t and makes q queries, each of length at most \(\ell \) blocks and of total length at most \(\sigma \) blocks. The distinguisher must not make two queries with the same nonce to the encryption oracle that is \(\mathcal {E}_K\) or \(\mathcal {RO}\). Moreover, we assume the distinguisher does not query the outputs from one oracle to the other oracle. Namely, he does not query the received ciphertext from \(\mathcal {E}_K\) or \(\mathcal {RO}\) to \(\mathcal {D}_K\), and does not query the received plaintext from \(\mathcal {D}_K\) to \(\mathcal {E}_K\) or \(\mathcal {RO}\). These assumptions aim at preventing trivial distinguishing attacks.

4.2 Distinguishing Attack

We notice that JAMBU uses an n-bit tag. Therefore, one can always obtain the corresponding plaintext for a ciphertext of his own choice from the decryption oracle by making at most \(2^{n}\) queries, i.e., by exhaustively guessing the tag value. Based on this observation, we can transform the distinguishing attack in the nonce-misuse setting detailed in Sect. 3 to a distinguishing attack in nonce-respecting setting, with a complexity increase by a factor \(2^{n}\) and hence with a total complexity of \(2^{3n/2}\), which is lower than the 2n-bit security one might expect.

In details, the attack in the nonce-misuse setting consists of three steps, and the repeating nonces requirement happens in steps 2 and 3. Thus, we will mainly modify these two steps. We adopt the same notation as Sect. 3.

First Step. The procedure is exactly the same as before. For the plaintext \(P_1\), its ciphertext is denoted as \(C_1\) under the nonce IV and as \(C'_1\) under the nonce \(IV'\). Then we denote \(V[IV]_{2} = P_1 \oplus C_1\) and \(V[IV']_{2} = P_1 \oplus C'_1\).

Second Step. Firstly, the attacker constructs tables \(\mathcal {T}_1\) and \(\mathcal {T}_2\) as before. Secondly, he selects a random one-block ciphertext block \(C_2\). For each element \(( \, \langle 0 \rangle \Vert \langle i \rangle ,\) \(\langle 1 \rangle \Vert \langle i \rangle ,\) \(\langle 2 \rangle \Vert \langle i \rangle \, )\) in table \(\mathcal {T}_1\), he executes a similar procedure to interact with the decryption oracle for each of \(\langle 0 \rangle \Vert \langle i \rangle \), \(\langle 1 \rangle \Vert \langle i \rangle \) and \(\langle 2 \rangle \Vert \langle i \rangle \). Here we use \(\langle 0 \rangle \Vert \langle i \rangle \) as an example to describe this procedure. The attacker computes \(V[IV]_{2} \oplus (\, \langle 0 \rangle \Vert \langle i \rangle \,)\) as the first ciphertext block, concatenates it with \(C_2\) as the second block, and queries the constructed two-block ciphertext to the decryption oracle with the nonce IV and with a random selected tag value. If the decryption oracle returns a failure symbol \(\bot \), the attacker changes the tag to a new value, and makes a decryption query with the same nonce and the same ciphertext. He will repeat such decryption queries by exhaustively trying new tag values until the decryption oracle returns a plaintext instead of \(\bot \). In the returned plaintext, it is easy to get that the first block is \(\langle 0 \rangle \Vert \langle i \rangle \), and we denote its second block as \(P[ \langle 0 \rangle \Vert \langle i \rangle ]_{2}\). Similarly, we define notations \(P[ \langle 1 \rangle \Vert \langle i \rangle ]_{2}\) and \(P[ \langle 2 \rangle \Vert \langle i \rangle ]_{2}\) for the second plaintext block corresponding to \(\langle 1 \rangle \Vert \langle i \rangle \) and \(\langle 2 \rangle \Vert \langle i \rangle \) respectively. Once a plaintext obtained, the attacker computes the pairwise differences of the second plaintext blocks as follows:

$$\begin{aligned} \varDelta P[\langle i \rangle ]_{1} = P[ \langle 1 \rangle \Vert \langle i \rangle ]_{2} \oplus P[ \langle 0 \rangle \Vert \langle i \rangle ]_{2},&\,\,\,\,\, \varDelta P[\langle i \rangle ]_{2} = P[ \langle 2 \rangle \Vert \langle i \rangle ]_{2} \oplus P[ \langle 0 \rangle \Vert \langle i \rangle ]_{2}. \end{aligned}$$

For each element of the other table \(\mathcal {T}_2\), the attacker makes similar decryption queries, but using \(IV'\) as nonce and \(V[IV']_2\) to compute the first ciphertext blocks. We denote the computed pairwise differences of the second plaintext blocks as (\(\varDelta P'[\langle j \rangle ]_{1}\), \(\varDelta P'[\langle j \rangle ]_{2}\)). The attacker matches the differences to previously stored \(\{ \, (\varDelta P[\langle i \rangle ]_{1}\), \(\varDelta P[\langle i \rangle ]_{2}) \, \}\). Once a matched pair is found, the attacker computes \(\varDelta _R\) and \(\varDelta _S\) from the corresponding plaintexts and ciphertexts as follows:

$$\begin{aligned} \varDelta _R = P[ \langle 0 \rangle \Vert \langle i \rangle ]_{2} \oplus P'[ \langle j \rangle \Vert \langle 0 \rangle ]_{2},&\,\,\,\,\, \varDelta _S = (\, \langle 0 \rangle \Vert \langle i \rangle \, ) \oplus (\, \langle j \rangle \Vert \langle 0 \rangle \,) = \langle j \rangle \Vert \langle i \rangle . \end{aligned}$$

If no match is found after trying all elements in \(\mathcal {T}_2\), the attacker outputs 0.

Third Step. The attacker selects a random one block \(C_1\) such that \(C_1\) and \(C_1 \oplus \varDelta _S\) have not been queried before as a first block of ciphertext under the nonces IV and \(IV'\). Then, he selects another random block \(C_2\). Firstly, the attacker makes queries \(C_1\Vert C_2\) to the decryption oracle with the nonce IV by exhaustively guessing the tag until he receives the plaintext, where the second plaintext block is denoted as \(P_2\). Secondly, the attacker makes queries \(C_1 \oplus \varDelta _S \Vert C_2\) to the decryption oracle with the nonce \(IV'\) by exhaustively guessing the tag until he receives the plaintext, where the second plaintext block is denoted as \(P'_2\). Finally, he computes \(\varDelta P_2 = P_2 \oplus P'_2\), and compares it to \(\varDelta _R\). If \(\varDelta P_2 = \varDelta _R\), the attacker outputs 1. Otherwise, he outputs 0.

The overall complexity is dominated by step 2, which is upper bounded by \(O(2^{3n/2})\) (or \(2^{96}\) for AES-JAMBU). The advantage of the distinguisher is almost 1 (we omit the detailed evaluation since it is similar with that of the attacks in previous sections).

4.3 Extension to a Plaintext-Recovery Attack

The plaintext-recovery attack setting is as follows. The attacker is given access to both encryption and decryption oracles of JAMBU instantiated with a randomly selected key that is secret to the attacker. He is allowed to make encryption and decryption queries of his own choice. Note that he must not make two encryption queries with the same nonce. In the end, the attacker is required to choose a nonce and a ciphertext (where the last block of the ciphertext must not have the same prefix than the last blocks of any previously outputted or queried ciphertext under the same nonce) and to produce a corresponding plaintext for it. If the plaintext is indeed valid, the plaintext-recovery attack is said to succeed.

The attack procedure is similar with that of distinguishing attacks from Sect. 4.2. The first two steps are exactly the same, and we adopt the same notations. In the third and last step, the attacker will choose a random one-block value \(C_1\) such that \(C_1\) and \(C_1 \oplus \varDelta _S\) have never been outputted as the first ciphertext block from the encryption oracle and have never been queried to the decryption oracle as first ciphertext block under the nonce IV and \(IV'\). Then, he will pick a random value for the second plaintext block \(C_2\) and interact with the decryption oracle to receive the plaintext \(P_1\Vert P_2\) of the ciphertext \((C_1 || C_2)\) under the nonce IV. Since he knows the value of \(\varDelta _R\) and \(\varDelta _S\), he will be sure that if he applies the difference \(\varDelta _S\) on \(P_1\) with nonce \(IV'\), he will get difference \(\varDelta _S\) on \(C_1\) and difference \(\varDelta _R\) on \(C_2\). Therefore, he can predict the plaintext \((P_1 \oplus \varDelta _S, P_2 \oplus \varDelta _R)\) corresponding to ciphertext \((C_1 \oplus \varDelta _S || C_2)\) with nonce \(IV'\).

The complexity of the above plaintext-recovery attacks is \(O(2^{3n/2})\) encryption queries and computations (or \(2^{96}\) for AES-JAMBU), and its success probability is almost 1 (we omit the detailed evaluation, since it is similar to the distinguishing attack).

4.4 Discussion on Trivial Attacks

In the nonce-respecting scenario, although the attacker cannot make two encryption queries with the same nonce, he is allowed to repeat nonces during the interaction with the decryption oracle. Hence, if he makes more than \(2^n\) decryption queries, he will obtain more than one pair of plaintext and ciphertext under the same nonce. As a result, this leads to several trivial attacks (similar to the trivial attacks on JAMBU in the adaptive chosen-ciphertext attack model described in Sect. 3.8). For example, the attacker can interact with the decryption oracle to receive a plaintext \(P_1\) for nonce IV and a one-block ciphertext \(C_1\), and then interact with the encryption oracle to receive a ciphertext \(C'_1\) for a random one-block plaintext \(P'_1\) with the same nonce IV. Finally he checks if \(P_1 \oplus C_1 = P'_1 \oplus C'_1\) holds. We refer to Sect. 3.8 for more discussions on trivial attacks on JAMBU.

5 Implementation of the Attack

We have implemented the attack on AES-JAMBU for the nonce-misuse scenario as described in Sect. 3 and we have verified the special differential structure from Fig. 5. For simplicity, the associated data was set to be empty, and the 128-bit key was set to 0x100f0e0d0c0b0a090807060504030201.

5.1 Results of the Attack

In the first step of the attack, we chose a random 64-bit plaintext \(P_1\) and asked for encryption under different nonce values. With \(2^{32}\) encryption queries, we found a collision on a pair of ciphertexts \(C_1, C'_1\) with a pair of nonce values \(IV, IV'\) (see Table 2).

Table 2. First step of the attack

With this pair of nonce values, we proceeded to the second step of the attack, \(P_2\) being set to zero for simplicity. We constructed the tables \(\mathcal {T}_1\) and \(\mathcal {T}_2\) and by matching the differences in the second block of ciphertexts, we obtained the values of \(\varDelta _S\) and \(\varDelta _R\). Table 3 shows the first tuple of the pair of plaintexts and ciphertexts tables with the matching difference.

Table 3. Second step of the attack

In the third step, we chose a random 128-bit plaintext \((P_1 \Vert P_2)\) and asked for its encryption with nonce IV. Upon receiving the ciphertext \((C_1 \Vert C_2)\), we deduced the ciphertext \((C^D_1 \Vert C^D_2)=(C_1 \oplus \varDelta _S \Vert C_2 \oplus \varDelta _R)\) for the plaintext \((P_1 \oplus \varDelta _S \Vert P_2)\) with nonce \(IV'\) without querying it to the encryption oracle. Finally, we checked that by asking for the encryption of the plaintext \((P_1 \oplus \varDelta _S \Vert P_2)\) with nonce \(IV'\), the ciphertext \((C'_1 \Vert C'_2)\) obtained is indeed what we had deduced (as can be seen from Table 4).

Table 4. Third step of the attack

The codes for the attack on AES-JAMBU are included in the supporting document, they are separated in two main codes - Step 1 and Step 2 of the attack, AES-NI is used for running AES-JAMBU.

5.2 Running Time of the Attack

For the first step of the attack, it took about 3.7 h and 36 GB of memory to find a collision. While for the second step of the attack, it took about 8.8 h and 320 GB to find \(\varDelta _S\) and \(\varDelta _R\).

For the second step of the attack, one can do a trade-off between the computation time and memory requirement. For instance, instead of constructing tables of \(2^{32}\) elements, one can construct tables of \(2^{30}\) (or \(2^{28}\) respectively) elements and the computation time takes about 2.2 h (or 0.5 h respectively) and 80 GB (or 20 GB respectively) of memory. However, in this case, one would have to guess the 2 (or 4 respectively) most significant bits of the difference values i and j. Hence, by repeating the attack procedure 16 times (or 256 times respectively), the value of \(\varDelta _S\) and \(\varDelta _R\) can be recovered by enumerating all the possible most significant bits values.

Conclusion

In this article, we have proposed a cryptanalysis of the confidentiality of JAMBU in both the nonce-misuse and nonce-respecting models. Namely, we have shown that one can break confidentiality in the nonce-misuse scenario with \(2^{32}\) computations and queries, while having access to only the encryption oracle. For the nonce-respecting, we show that our attack can be extended to break confidentiality security of JAMBU with \(2^{96}\) computations and queries in the adaptive chosen-ciphertext attack model, with message prefixes not previously queried.

It would be an interesting future work to study how JAMBU could be patched to resist these attacks. We believe that one simple possibility would be to output \(P_{i-1}\) instead of \(P_{i}\) during round i (while keeping the insertion of \(P_i\) in the internal state). This would probably prevent our attack since the last block of the distinguishing plaintext/ciphertext pair would have the exact same prefix than the last block of previously queried pairs.