Collision Attacks Against CAESAR Candidates
Abstract
In this paper we study authenticated encryption algorithms inspired by the OCB mode (Offset Codebook). These algorithms use secret offsets (masks derived from a whitening key) to turn a block cipher into a tweakable block cipher, following the XE or XEX construction.
OCB has a security proof up to \(2^{n/2}\) queries, and a matching forgery attack was described by Ferguson, where the main step of the attack recovers the whitening key. In this work we study recent authenticated encryption algorithms inspired by OCB, such as Marble, AEZ, and COPA. While Ferguson’s attack is not applicable to those algorithms, we show that it is still possible to recover the secret mask with birthday complexity. Recovering the secret mask easily leads to a forgery attack, but it also leads to more devastating attacks, with a keyrecovery attack against Marble and AEZ v2 and v3 with birthday complexity.
For Marble, this clearly violates the security claims of full nbit security. For AEZ, this matches the security proof, but we believe it is nonetheless a quite undesirable property that collision attacks allow to recover the master key, and more robust designs would be desirable.
Our attack against AEZ is generic and independent of the internal permutation (in particular, it still works with the full AES), but the keyrecovery is specific to the key derivation used in AEZ v2 and v3. Against Marble, the forgery attack is generic, but the keyrecovery exploits the structure of the E permutation (4 AES rounds). In particular, we introduce a novel cryptanalytic method to attack 3 AES rounds followed by 3 inverse AES rounds, which can be of independent interest.
Keywords
CAESAR competition Authenticated encryption Cryptanalysis Marble AEZ PMAC Forgery Keyrecovery1 Introduction
The purpose of an Authenticated Encryption scheme is to provide both privacy and integrity with a single cryptographic algorithm. In 2014, the CAESAR competition was launched with the goal to identify good Authenticated Encryption schemes as better alternatives to current options such as AESGCM [14]. 57 candidates have been submitted to the CAESAR competition, and they must now be analyzed carefully.
In this paper, we provide a security analysis of the AESbased candidates Marble [5] and AEZ v3 [7]. Both designs are inspired by OCB [16], designed in 2001 by Rogaway, Bellare, Black, and Krovetz. They are built as modes of operation of a block cipher^{1}, using secret offsets at the input and/or output of the block cipher calls.
Marble. Marble [5] is a CAESAR candidate by Jian Guo inspired by COPA [1]. COPA was designed in 2013, and combines OCB’s offsets with an internal dependency chain in order to achieve some security in the case of nonce repetition. Marble uses two internal chains in order to prevent birthday attacks on the internal chain, and uses reducedround AES as building blocks. Marble claims security against noncerepetition, and against release of unverified plaintexts, but cannot hide common prefixes in case of nonce reuse (Marble is online). As opposed to most CAESAR candidates, Marble claims full 128bit security (beyond the birthday bound). The structure of Marble can be seen in Fig. 2.
Results presented so far on Marble include a ciphertext distinguisher with complexity \(2^{64}\), similar to the distinguisher against the counter mode [17].
AEZ. AEZ is a CAESAR candidate designed by Hoang, Krovetz, and Rogaway. The authors define the security notion of Robust AE, which is the optimal security achievable when nonces are repeated, and unverified plaintexts are released. AEZ is claimed to achieve this security notion. In this paper, we focus on the current version of AEZ, AEZ v3, as proposed on the cryptocompetition mailing list, and presented at DIAC [7]. AEZ v3 has also been accepted at Eurocrypt 2015, and presented as one of the honorable mentions for the best papers award [8]. Our result can also be applied to AEZ v2, but not to AEZ v1, because of a different key expansion.
As far as we are aware, no cryptanalysis of AEZ as been published so far.
Our Results. In this paper, we describe generic collision attacks against Marble and AEZ, allowing to recover the whitening key with about \(2^{n/2}\) chosen message queries. When the whitening key is known the security offered by Marble and AEZ crumbles and we show a forgery attack using a single extra encryption query. Moreover, we extend this result to keyrecovery attacks using properties of the internal permutations and/or the key scheduling.
Our results are summarized in Tables 1 and 2. The data complexity is listed in number of message blocks (16 bytes). We now detail our results on each AuthenticatedEncryption with AssociatedData (AEAD) scheme.
Marble. Our attack against Marble uses queries with repeated nonces, which should be secure according to the security claims of Marble. Since Marble claims security beyond the birthday bound (allowing up to \(2^n\) block of data), the forgery attack using collisions clearly violates the security claims. In addition, we show that if unverified plaintexts are released, i.e. if we can obtain plaintexts from ciphertexts without a valid tag, then we can further recover the master key K. For this attack, we build special queries so that only 3 forward AES rounds and 3 backwards AES rounds are active, and we develop a novel method to attack such a reduced cipher with only known plaintext/ciphertexts. Our attack can be build upon two different distinguishers. the first one is based on the detection of collision events, and the second one on a statistical property. In both cases, our attack requires about \(2^{33}\) queries and its time complexity is \(2^{64}\); we believe this result is also of independent interest.
Following the disclosure of this attack, Guo proposed a minor modification of the specifications of Marble as version 1.2 [6]. However, our attack is still applicable to the modified version, as shown independently by ourselves and Lu [13]. Guo later decided to withdraw Marble from the CAESAR competition.
AEZ. Our analysis of AEZ v3 focuses on the processing of Associated Data. In particular, if AEZ is used with an empty message and no nonce, it turns into a variant of PMAC, and the security notion of Robust AE becomes the usual MAC security notion. We show how to recover the whitening key of this variant of PMAC with a collision attack (a collision attack is also possible against the standard PMAC, e.g. following [11]). More importantly, the key derivation of PMAC allows to recover the master key K from the whitening key.
This attack does not violate the security proof, but matches the security bound. However, collision attacks usually have a more limited impact (e.g. only affecting authenticity), and it seems quite unfortunate that a collision attack leads to a keyrecovery. This property should probably be avoided when possible^{2}.
Our results against Marble.
Attack (Sec. claim)  Data  Time 

Recover L  \(2^{65} \times 2\) CP  \(2^{64}\) 
Forgery (\(2^{128}\))  \(2^{65} \times 2\) CP  \(2^{64}\) 
Keyrecovery (\(2^{128}\)):  
Collisionbased\(^a\)  \(2^{65} \times 2\) CP + \(2^{32.6} \times 130\) CC  \(2^{64}\) 
Collisionbased  \(2^{65} \times 2\) CP + \(2^{33} \times 130\) CC  \(2^{64}\) 
Our results against AEZ.
Attack  Data\(^a\)  Time  Success probability 

Keyrecovery  \(2^{66.6}\)  1  1 
Keyrecovery  \(2^{44}\)  1  \(2^{45.2}\) 
Outline of the Paper. Since our collision attack on AEZ is much simpler than the attack against Marble, we first explain it in Sect. 2. Then we give a short description of the Marble authenticated encryption algorithm in Sect. 3. In Sect. 4, we show how to recover the whitening key L and describe our forgery attack. Finally, we demonstrate in Sect. 5 how to recover the encryption key K from decryptionmisuse queries.
2 Collision Attack Against AEZ
We first explain the collision attack on AEZ and the resulting keyrecovering attack.
2.1 Short Description of AEZ
For simplicity, we consider AEZ used with only associated data, without any nonce or message (the attack can easily be applied with a fixed nonce and message if required). In this case, AEZ turns into a variant of PMAC, and the security claim becomes the usual MAC security definition. A particularity of AEZ is that it allows a vectorvalued input, i.e. it can authenticate a sequence of strings rather than a single string.

The key derivation algorithm generates keys \(k_0, k_1\) and whitening keys J, L
 Full data blocks \(A_i^j\) of the jth string (indexed from 1) are processed as:$$\begin{aligned} X_i^j&= E_{k_0}\left( A_i^j \oplus (i \,\,{\text {mod}}\,\, 8) \cdot J \oplus 2^{\left\lfloor {(i1)/8}\right\rfloor } \cdot L \oplus 8j \cdot J\right) \end{aligned}$$
 If the last block is partial, it is enciphered as:$$\begin{aligned} X_i^j&= E_{k_0}(A_i^j \oplus 8j \cdot J) \end{aligned}$$

The first block to be processed is the ciphertext extension \(\tau \) (corresponding to the tag length). It is \(\tau =128\) by default.

The tag is computed as \(E_{k_1}(\bigoplus _{i,j} X_i^j)\)
2.2 Collision Attack on AEZ

\(\mathcal {A} = \{A_{x} ~~ x \in \{0 \ldots 2^{64}1\}\}\), with \(A_x = \left( \tau ; C; (C \parallel [x] \parallel \mathtt {0}^{64})\right) \)

\(\mathcal {B} = \{B_{y} ~~ y \in \{0 \ldots 2^{64}1\}\}\), with \(B_y = \left( \tau ; (C \parallel \mathtt {0}^{64} \parallel [y]); C \right) \)
Key Recovery. Surprisingly, the key derivation of AEZ allows to recover the master key K from the whitening key J. More precisely, if the master key K is of length 128 bits or smaller, J is an encryption of K under a known constant C: \(J = \text {AES4}_C(K)\). This can easily be inverted: \(K = \text {AES4}_C^{1}(J)\). We note that this is not the case in PMAC, where the whitening key is an encryption of 0 under the secret key K: \(L = \text {AES}_K(0)\).
This attack matches the security proof of AEZ and does not violate the security claims. However, a complete break of AEZ after the birthday bound is not expected: most schemes with birthdaybound security are more resilient and collision attacks don’t allow keyrecovery.
It should be mentioned that the Eurocrypt version of AEZ does not explicitly specify a key derivation algorithm, and leaves it as an open problem:
“The key \(K \in \) Byte \(^{*}\) is mapped to three 16byte subkeys (I, J, L) using the keyderivation function (KDF) named Extract that is called at line 401. The definition of Extract is omitted from the figures and regarded as orthogonal to the rest of AEZ. See the AEZ spec for the current Extract\(:\) Byte \(^{*} \rightarrow \) Byte \(^{48}\). In our view, it is an unresolved matter what the security properties (and even what signature) of a good KDF should be. Work has gone off in very different directions, and the area is currently the subject of a Password Hashing Competition (PHC) running concurrently with CAESAR.”
Clearly, the key derivation of the AEZ v3 specification does not have the security properties of a good KDF.
Data Limit. The AEZ specification requires users to change the key after encrypting \(2^{48}\) bytes, i.e. \(2^{44}\) blocks. This prevents the attack as described above. However, we can perform the attack with smaller sets \(\mathcal {A}\) and \(\mathcal {B}\) of size \(2^{41.4}\), with a success probability of \(2^{45.2}\). This is still much more efficient than generic attacks: with a time complexity of \(2^{44}\), a bruteforce key search only succeeds with a probability of \(2^{84}\).
3 Description of Marble
Marble is an authenticated encryption algorithm designed by Guo [5] with keylength and taglength of both 128 bits. A plaintext and its associated data are divided into blocks of 128 bits and are then proceeded consecutively. Its internal permutation is based on a modified version of the AES block cipher. Unlike other authenticated encryption algorithms, Marble does not require a nonce.
Marble has very strong security claims: it claims to offer full 128bit security, i.e. an attack should take time \(T = 2^{128}\) even after large amount of data have been encrypted with the same key (up to \(D = 2^{128}\)). This is in contrast to many CAESAR candidates and classical modes of operations for block ciphers (e.g. GCM), which only offer a birthday level of security, i.e. the ciphers are secure as long as \(T \cdot D < 2^{128}\).
In addition, Marble does not use nonces, and the security claim even holds if unverified plaintexts are released, i.e. the adversary can request the decryption of a ciphertext C without knowing a valid tag corresponding to C (decryptionmisuse oracle). A few other CAESAR candidate allow the release of unverified plaintext (AEZ, POET, APE, Minalpher), but they only claim birthday security.
An overview of Marble is depicted in Fig. 2. The Marble mode of operation makes use of two 128bit chaining variables \(s_1\) and \(s_2\), initialized with constants \(const_1\) and \(const_2\). The associated data and the plaintext are padded independently, so both resulting fields A and P can be divided into 128 bit blocks. We do not describe the padding function here, as it does not affect our attacks. We will denote a message to encrypt by \((AD \parallel M)\), where AD is a vector containing \(l_A\) 128bit blocks of associated data and M is a vector containing \(l_M\) 128bit blocks of plaintexts.
In the case of Marble, each one of the three permutations \(E_1\), \(E_2\) and \(E_3\), is composed with 4 fullround of AES (i.e. SubByte, ShiftRow, MixColumn and AddRoundKey). One can notice that no key addition is performed at the beginning of those permutations. 12 subkeys are therefore required. A 128bit master key K is derived into 11 subkeys using the AES128 keyschedule algorithm. The master key itself is used as the 12th subkey. For more information about the AES block cipher, we refer to [2].
 1.
Addition (i.e. xor) of the prewhitening key;
 2.
Application of the internal primitive;
 3.
For plaintext blocks, application of the post whitening key, which results in ciphertext blocks.
4 A Universal Forgery Attack on Marble
4.1 Recover the Mask L
The main idea of the attack is to build a pair of message \(M \ne M'\) so that the inputs to the \(E_1\) functions are the same for both messages. This is possible if M and \(M'\) have the same total length, but the associated data and message parts have different lengths. When the inputs to \(E_1\) collide, all the intermediate computations collide, and we can detect this event on the resulting ciphertexts. Please note that as different multiples of L are used for postwhitening, this operation is more tricky than detecting a collision on ciphertexts. In the following we use 2 blocks of AD and 1 block of message for M, but 1 block of AD and 2 blocks of message for \(M'\).

\(M_{\alpha }=(AD[1],AD[2] \parallel M[1])=(A,8\alpha \parallel 6 \alpha )\);

\(M'_{\beta }=(AD[1] \parallel M'[1],M'[2])=(A \parallel 8\beta ,6\beta )\).
4.2 An Attack Against Marble 1.2
After the first release of our attack, Guo made a minor modification to the specification of Marble [6]. Namely, the input mask for the last block of associated data is changed from \(2^{i1}3^2L\) to \(2^{i1}3^3L\). Our attacks can be adapted as follows.

\(M_{\alpha }=(AD[1],AD[2] \parallel M[1])=(10\alpha , 28\alpha \parallel 6 \alpha )\);

\(M'_{\beta }=(AD[1] \parallel M'[1],M'[2])=(10\beta \parallel 28\beta ,6\beta )\).
4.3 Computing Forgeries on Marble Without Whitening Keys
5 KeyRecovery Attack
We now show how to recover the master key once the mask L has been determined. In order to simplify the description of the attack, we now focus on the maskless variant of Marble; however the full attack can easily be adapted to the full version of Marble with a known mask.
The main idea is to collect pairs of messages with a fixed difference in some internal state variables. This will allow us to attack a reduced cipher composed by 4 AES rounds followed by 4 inverse AES rounds rather than a 12round AES (see details below). Moreover, we apply this strategy to \(E_1\) rather that to \(E_3\) because the whitening key of \(E_1\) is directly derived from L. Since L is known, the first AES round of \(E_1\) is keyindependent. Therefore we can peel it off, and attack only 3 forward rounds and 3 inverse rounds. However, this requires us to use decryption queries, but we can’t forge valid tags for an arbitrary ciphertext yet, so we use a decryptionmisuse oracle.
5.1 Gathering Pairs
In addition, we can peel off the outer rounds since there is no whitening key in \(E_1\).
5.2 Extracting the Key
The first step of our attack is to guess a diagonal of the first round key, which allows to compute a column after the first round and before the last round. Next we focus on the middle rounds. The middle rounds have only one MixColumn operation, and one InverseMixColumn without byte shuffling in between. Therefore it can be seen as four parallel 32bit functions, acting on each diagonal (similar to the SuperSBox technique [4]). Note that if the key guess is wrong, the resulting function can not be decomposed into 4 parallel functions. For each function, 1 input byte and 1 output byte are known. We describe below two different distinguishers for the middle rounds, that lead to key recovery attack with similar complexities. The first one is based on a rare event that can easily be detected, the second one relies on the detection of a statistical bias in the generic case.
Collisionbased Distinguisher. For our first distinguisher, we focus on the constant \(\delta _S\). We only know that \(\delta _S\) is nonzero on the full state. Considering that it is distributed uniformly on nonzero constants, it cancels one of the diagonals^{3} with probability \((2^{96}1)/(2^{128}1) \approx 2^{32}\). Then, an average of \(2^{30}\) different choices of AD are necessary to reach a value of \(\delta _S\) that cancels on one of the diagonals. Let us consider that it occurs on the first diagonal (w.l.o.g.), which contains bytes 0, 7, 10, 13. Then, the value of these bytes collide before and after the AddDeltaS operation. Then, the values of the first column of the block (bytes 0, 1, 2, 3) are not affected by the middle rounds. If we continue the decryption process towards both ends of the modified version of the AES, the collision passes through the InverseMixColumn operation. After undoing the ShiftRow, SubByte and textsfAddKey operation, we notice that the values of bytes 0, 5, 10, 15 are equal at the beginning and at the end of the middle part of the cipher.
For each choice of AD, we then generate 3 (plaintextciphertext) pairs \((\widetilde{P}_x,\widetilde{P}'_x)\) for 3 values of x. Then, we proceed as follows.
In each of the \(2^{30}\) sets, we guess separately the 32 bits on each of the 4 antidiagonals^{4} of the first round key. This enables to compute one full column of the state before and after the middle rounds, for each value of x. For each byte \(b_i\) in this column, we store a list \(L_i\) of the key values such that the input byte and the output byte of the middle rounds are equal for each x.
Then we consider the first diagonal before and after the middle rounds. It contains bytes 0, 5, 10 and 15 of the block. Remember that the diagonals contain the inputs and outputs of 4 independent functions \(F_i\). From the 4 lists of partial keys \(L_j,j=0,5,10,15\), we can build all the keys such that the input of \(F_i\) collides with the output for each value of x. Using the known plaintexts and ciphertexts for the full cipher, we can try all these keys as candidates. Then, we repeat the whole process with the other three diagonals.
We now explain why this attack works.
Filtering Keys. Following the analysis above, the right key can be decomposed into 4 partial keys covering each diagonal of the block. If \(\delta _S\) cancels on one of the columns, then the partial values of the right key will appear on the four corresponding lists \(L_i\), and the full key will be among the combination of elements of the four lists. Therefore, the right key will be detected by our algorithm.
False Positives. For each wrong partial 32bit key, it is stored in the corresponding list \(L_j\) if the input and output of \(F_i\) collide on byte j, for each of the 3 values of x. This occurs with probability \(2^{24}\), if we consider the input and output byte computed for \(F_i\) as independent. Therefore, we have on average one false positive of each of the 4 diagonals of the key. Considering that the number of false positives are independent for each diagonal of the key, there are on average \((2^8)^4 = 2^{32}\) keys to try, for each of the 4 diagonals and each of the \(2^{30}\) sets of values. The expected number of key candidates is marginally increased to \((2^8+1)^4\approx 2^{32}\) when the difference \(\delta _S\) cancels on the diagonal, as each set of partial keys at least contains the right key.
\(\delta _S\ne 0\) on column i. As above, each wrong key guess is stored with probability \(2^{24}\), which leads to \((2^8)^4\) false positives on average, that are discarded by exhaustive search.
Summary of the Attack. We focus on the key recovery attack on the maskless version of Marble. In the decryptionmisuse setting, it requires the decryption of \(6\times 2^{30}\) ciphertexts composed of 130 blocks of plaintext and 1 block of associated data, which correspond to \(2^{30}\) sets of 3 pairs. To build the lists of partial keys, one has to perform \(6\times 1/4\) of an AES round for each partial key guess, leading to a total of \(3\times 2^{31}\) AES rounds, for each set and each diagonal. The average complexity of this step for the full attack is then \(3\times 2^{63}\) AES rounds. The most timeconsuming part of the attack is the exhaustive search among the remaining candidates, which requires \(2^{64}\) AES encryptions on average (\(2^{32}\) per column and per set).
Linear Cryptanalysis. The method described in Sect. 5.1 leads to the knowledge of plaintextciphertext pairs for a cipher that consists of 3 AES rounds, a key addition and 3 inverse AES rounds. The adversary therefore targets a cipher with a reduced number of rounds, in a known plaintext setting. Using linear cryptanalysis therefore seems a natural idea. As shown above, one can guess 4 key bytes, which leads to the knowledge of 4 input and 4 output bytes of the inner 4 rounds of this cipher.
In [9], Keliher and Sui demonstrate that the maximum expected linear probability over 2 AES rounds is about \(LP \approx 1.638\times 2^{28}\). In our case, we can concatenate a linear trail with its inverse. When averaging over the possible values of the key and of the intermediate difference \(\delta _S\), the maximum expected probability for a 4round characteristic would be about \(LP^2 \approx 1.342\times 2^{55}\). This number also gives an estimation of the amount of data required for the attack to work. Even by taking into account the possible bias due to the linear hull effect, the complexity of the linear attack is expected to be far higher than the one suggested by the experiments below.
A refinement of the linear attack consists in noticing that between the two middle rounds, each byte of the block is affected only by a key byte and a byte of \(\delta _S\), but not by other bytes of the block. Therefore, the two middle Sbox layers could be expressed as one layer of 8bit keydependent Sboxes, leading to trails with 6 active Sboxes instead of 10. Nevertheless, the best linear trail would then depend on the unknown value of \(\delta _S\), which would make it hard to exploit. Instead, we use the following statistical distinguisher.
Statistical Distinguisher. Intuitively, if we have many partial input/output pairs, we should detect some correlation between the inputs and output. Indeed, when the key guess is wrong, the function composing the distinguisher behaves as a 128bit permutation instead of the parallel application of four 32bit functions. Hence, the input and output bytes are less correlated. We focus on a property that does not require to know in advance which values are correlated, and works for any function based on (four 32bit) parallel permutations.
In order to analyze this algorithm, we model the counters using random variables \(C_{\alpha ,\beta }\), and the sample variance as \(S^2\) for a wrong key guess, and \(S^2_{*}\) for the right key. Our goal is to show that when D is large enough, we have \(\Pr [S^2 > S^2_{*}]\) negligible, i.e. the correct key is ranked first.
Wrong key Guess. We know that starting from \(\alpha \), if we revert the initial round with the wrong key, then compute three rounds forward with the correct keys, add \(\delta _S\), compute three round backwards with the correct keys, and finally one round forward with the wrong key, we reach a state with \(\beta \). Therefore, \(\alpha \) and \(\beta \) are partial inputs/outputs of a 128bit permutation.
If we model this function by a random 128bit permutation, the number of data matching a pair \((\alpha ,\beta )\), in images and preimages of this 128bit function, follows an hypergeometric distribution. Indeed, for each input which first byte has value \(\alpha \), the output is drawn uniformly without replacement among all the possible outputs of the function. The success is determined by whether the first byte of the output equals \(\beta \). The number of draws is \(2^{120}\), and there are \(2^{120}\) success cases among \(2^{128}\) possible values.
For the right key, we don’t have an analytic expression of the distribution of the sample variance, but we can perform experiments. Our experiments show that with very high probability \(S^2_{*} >2^{16}+2^{12}\), as seen in Fig. 8. Of our \(2^{16}\) experiments, the minimum value of \(s^2_{*}\) was \(102795 \approx 2^{16}+2^{15}\). Using \(D = 2^{32}\), we have a large margin and we expect the attack to work with significantly less data, but recovering L will be the bottleneck of the attack.
6 Conclusion
Our results show that collision attacks can have a strong impact on the security of authenticated encryption schemes. It seems that extracting the whitening key using collisions is possible in many OCBbased designs, and this can sometimes be extended into a full keyrecovery attack.
On AEZ, we show how to recover the whitening key, and we point out that the key derivation of AEZ v2 and v3 has the unfortunate property that the master key can easily be recovered from the whitening key. This allows a complete break after the birthday bound. Even with a limit on the amount of data processed with a single key, this still gives an attack with a higher success probability than generic attacks. While this does not violate the security proof of AEZ, we believe it would be better to avoid this property.
Our results on Marble show that it does not provide the security features claimed by the author, i.e. beyond birthday bound security and decryptionmisuse resistance. We note that Marble still offers a stronger security than many CAESAR candidates and classical modes of operations when using nonces (or unique AD). Once usage requirements are relaxed, our results also show that the security of Marble is similar to the security of other misuse resistant CAESAR candidates (e.g. APE128, POET, AEZ, Minalpher) but it collapses badly after the birthday bound under a decryptionmisuse setting, even leading to a full key recovery.
It seems that adding one extra operation on the state between the processing of the associated data and of the message would avoid our attacks, but a thorough analysis would be necessary to ensure that the resulting construction is secure. As our attack heavily relies on the fact that \(S_1\) and \(S_2\) keep the same values on two different plaintexts, one could xor a constant block (for example, 16 bytes encoding the byte positions in the block, \((0,1,\ldots ,15)\)) on \(S_1\) and \(S_2\) after processing the associated data.
In addition, our keyrecovery attack of Marble suggests that 4 AES rounds in the E functions are insufficient if the adversary can find a shortcut to target two E functions instead of three. In particular, this suggest that a deeper investigation of the security of AEZ with a modified key schedule would be interesting.
Up to our knowledge, the statistical distinguisher presented to recover the encryption key of a reducedround AES, has never been used before. Although it permits to attack few rounds, it seems that it is more efficient than a classical linear attack. We believe that it is sufficient enough for this kind of distinguisher to benefit from further research.
Footnotes
 1.
For efficiency reasons, Marble and AEZ actually use 4rounds of AES rather than a full block cipher.
 2.
In AEZ v4, for the second round of the competition, the designers took into account our result and modified the key derivation in order to prevent this property.
 3.
defined as the images of columns by the ShiftRow operation.
 4.
defined as the preimages of columns by the ShiftRow operation.
References
 1.Andreeva, E., Bogdanov, A., Luykx, A., Mennink, B., Tischhauser, E., Yasuda, K.: Parallelizable and authenticated online ciphers. In: Sako, K., Sarkar, P. (eds.) ASIACRYPT 2013, Part I. LNCS, vol. 8269, pp. 424–443. Springer, Heidelberg (2013) CrossRefGoogle Scholar
 2.Daemen, J., Rijmen, V.: The Design of Rijndael: AES  The Advanced Encryption Standard. Information Security and Cryptography, Springer (2002)Google Scholar
 3.Ferguson, N.: Collision attacks on OCB. Comments to NIST (2002). http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/General_Comments/papers/Ferguson.pdf
 4.Gilbert, H., Peyrin, T.: SuperSbox cryptanalysis: improved attacks for AESlike permutations. In: Hong, S., Iwata, T. (eds.) FSE 2010. LNCS, vol. 6147, pp. 365–383. Springer, Heidelberg (2010) CrossRefGoogle Scholar
 5.Guo, J.: Marble Specification Version 1.0. Submission to the CAESAR competition, March 2014Google Scholar
 6.Guo, J.: Marble Specification version 1.2 (January 2015), posted on the cryptocompetition mailing listGoogle Scholar
 7.Hoang, V.T., Krovetz, T., Rogaway, P.: AEZ v3: AuthenticatedEncryption by Enciphering. In: DIAC 2014: Directions in Authenticated Ciphers, Santa Barbara, August 2014Google Scholar
 8.Hoang, V.T., Krovetz, T., Rogaway, P.: Robust authenticatedencryption AEZ and the problem that it solves. In: Oswald, E., Fischlin, M. (eds.) EUROCRYPT 2015. LNCS, vol. 9056, pp. 15–44. Springer, Heidelberg (2015) Google Scholar
 9.Keliher, L., Sui, J.: Exact maximum expected differential and linear probability for tworound advanced encryption standard. IET Inf. Secur. 1(2), 53–57 (2007)CrossRefGoogle Scholar
 10.Knight, K.: Mathematical Statistics. Chapman & Hall, New York (1999) CrossRefGoogle Scholar
 11.Lee, C.H., Kim, J.S., Sung, J., Hong, S.H., Lee, S.J.: Forgery and key recovery attacks on PMAC and mitchell’s TMAC variant. In: Batten, L.M., SafaviNaini, R. (eds.) ACISP 2006. LNCS, vol. 4058, pp. 421–431. Springer, Heidelberg (2006) CrossRefGoogle Scholar
 12.Liskov, M., Rivest, R.L., Wagner, D.: Tweakable block ciphers. J. Cryptology 24(3), 588–613 (2011)zbMATHMathSciNetCrossRefGoogle Scholar
 13.Lu, J.: On the Security of the COPA and Marble Authenticated Encryption Algorithms against (Almost) Universal Forgery Attack, February 2015Google Scholar
 14.NIST: Advanced Encryption Standard (AES) (November 2001), federal Information Processing Standards Publication FIPS 197Google Scholar
 15.Rogaway, P.: Efficient instantiations of tweakable blockciphers and refinements to modes OCB and PMAC. In: Lee, P.J. (ed.) ASIACRYPT 2004. LNCS, vol. 3329, pp. 16–31. Springer, Heidelberg (2004) CrossRefGoogle Scholar
 16.Rogaway, P., Bellare, M., Black, J., Krovetz, T.: OCB: a blockcipher mode of operation for efficient authenticated encryption. In: Reiter, M.K., Samarati, P. (eds.) CCS 2001, Proceedings of the 8th ACM Conference on Computer and Communications Security, Philadelphia, Pennsylvania, USA, November 6–8, 2001. pp. 196–205. ACM (2001)Google Scholar
 17.Sasaki, Y.: Universal Forgery on POET and Ciphertext Distinguisher on POET and Marble (July 2014), posted on the cryptocompetition mailing listGoogle Scholar