Is AEZ v4.1 Suﬃciently Resilient Against Key-Recovery Attacks?

. AEZ is a parallelizable, AES-based authenticated encryption algorithm that is well suited for software implementations on processors equipped with the AES-NI instruction set. It aims at oﬀering exceptionally strong security properties such as nonce and decryption-misuse resistance and optimal security given the selected ciphertext expansion. AEZ was submitted to the authenticated ciphers competition CAESAR and was selected in 2015 for the second round of the competition. In this paper, we analyse the resilience of the latest algorithm version, AEZ v4.1 (October 2015), against key-recovery attacks. While AEZ modiﬁcations introduced in 2015 were partly motivated by thwarting a key-recovery attack of birthday complexity against AEZ v3 published at Asiacrypt 2015 by Fuhr, Leurent and Suder, we show that AEZ v4.1 remains vulnerable to a key-recovery attack of similar complexity and security impact. Our attack leverages the use, in AEZ, of an underlying tweakable block cipher based on a 4-round version of AES. Although the presented key-recovery attack does not violate the security claims of AEZ since the designers made no claim for beyond-birthday security, it can be interpreted as an indication that AEZ does not fully meet the objective of being an extremely conservative and misuse-resilient algorithm.


Introduction
Authenticated Encryption (AE) algorithms aim at providing encryption and message authentication in a combined way.The purpose of the ongoing international competition CAESAR, that was launched in 2014, is to select a portfolio of AE algorithms that offer better security guarantees and/or improved performances as compared with existing AE standards such as AES-GCM [1].AEZ [2,3] is an AES-based AE scheme designed by Hoang, Krovetz, and Rogaway.It is a high-profile CAESAR candidate and was selected in July 2015 for the second round of the competition.The AEZ construction can be viewed as a mode of operation of an underlying block cipher -more precisely of a mixture of AES versions with 4 and 10 rounds denoted AES4 and AES10.AEZ uses secret offsets and round keys derived from the authenticated encryption key K. AEZ is parallelizable and particularly well suited for software implementations on processors equiped with the AES-NI instruction set.On such environments, its computational cost is lower than the one of AES-GCM and close to the one of OCB [4].AEZ aims at providing an unusually strong nonce and decryption misuse resistance and more generally best achievable security given the selected amount of plaintext expansion.These security properties are captured by the notion of robust authenticated encryption (RAE), a demanding security notion, not attainable by online AE schemes, i.e.AE schemes allowing a single-pass blockwise plaintext encryption with constant memory [5].The RAE security notion and the security arguments underlying the AEZ construction were detailed in the Eurocrypt 2015 paper [2].
In this paper, we analyze the resilience of the latest algorithm version, AEZ v4.1 (October 2015) [3], against key-recovery attacks.We show that the AEZ modifications introduced in 2015, that were partly motivated by thwarting a key derivation attack with birthday complexity against AEZ v3 published at Asiacrypt 2015 by Fuhr, Leurent and Suder [6], do not prevent the existence of key derivation attacks of birthday complexity against AEZ v4.1.In both cases, the attack rests on the fact that AEZ was designed as to be potentially usable either without nonce 1 or with a repeating nonce values without other security impact than the detectability of repeated (associated data, message) pairs.Unlike the attack of [6], our most efficient key derivation attack relies on the use of AES4 in AEZ.It can therefore not be transposed to the more conservative but less efficient scaled up version of AEZ where only AES10 is used instead of a mixture of AES10 and AES4.
Neither the AEZ v3 attack of [6] nor our attack on AEZ v4.1 violates the security claims of AEZ since the designers made no claim for beyond-birthday security.It should also be noted that if one takes into account the limitation of the amount of data processed under the same key to 2 48 bytes required by the designers, their success probability becomes relatively low.
We nevertheless believe that the vulnerability of AEZ4.1 to a key derivation attack of birthday complexity2 represents an undesirable property, particularly for an algorithm that otherwise aims at satisfying a very strong notions of security and at being exceptionally resilient in various misuse situations.Indeed, even though the existence of distinguishers of birthday complexity against modes of operation of block ciphers is not so unusual, the existence of full key derivation attacks of birthday complexity is far less frequent and raises in the case of AEZ v4.1 the following resilience questions (exactly the same as those raised by the attack of [6] in the case of AEZ v3).First, our attack allows to recover the whole key material with a much higher success probability than the one that would result from generic attacks for typical key sizes, e.g.128, 256, or 384 bits even if the below-birthday data limitation of 2 48 bytes imposed by the designers is respected.Second, this probability can become arbitrarily close to 1 in the algorithm misuse case where the data limitation of 2 48 bytes cannot be enforced and "birthday" amounts of data can be processed.
Our results are summarized in Table 1.Our most efficient attack essentially consists of two phases.In a first phase, 128 bits of key material used for pre-whitening the inputs to some AES4 and AES10 computations are derived, using a birthday attack.We show that the universal hashing part of the AEZ computations, on which the attack of [6] concentrated, can still be targeted by some birthday attacks.However the key material information this provides is less suited for continuing the attack than a 128-bit sub-key that can be derived by targeting instead the encipherment part of the AEZ computations.This sub-key determines the pre-whitening of some AES4 computations also involved the encipherment procedure.In a second phase of the attack, we encrypt particular plaintext structures and detect plaintext pairs leading to a special differential behaviour in the last three rounds of these AES4 computations.This allows to recover the remaining of the key material.The paper is organized as follows.Section 2 outlines the parts of the AEZ v4.1 specifications that are useful for our attack and the main differences between AEZ v4.1 and AEZ v3.Section 3 first describes partial attacks of birthday complexity allowing to recover a 128-bit piece of the key material (Section 3.1).The combination of these partial attacks can be viewed as a suboptimal key derivation attack of birthday time and data complexity.Then we detail our most efficient attack on AEZ v4.1 (Section 3.2), that exploits the use of AES4 in AEZ.The attack of Section 3.2 has the property (not shared by the combined attack of Section 3.1) that its success probability remains abnormally high if the amount of data processed under the same key is limited to the below-birthday threshold of 2 48 bytes.

Description of AEZ
The following input and output arguments are used in AEZ: -a plaintext P of plen bits; -a key K of arbitrary length klen bits.The default value of klen is 384 bits and klen values of at least 128 bits are recommended; -a nonce N of length nlen bits.The use of nonce values of length at most 128 bits is recommended and nlen = 0 is allowed, as well as the use of several nonce lengths for authenticated encryptions under the same key; -a string-valued or more generally vector-valued associated data A = (A 1 , • • • , A m ) of m strings, of total length alen bits.A string-valued associated data can be viewed as a vector with m = 1 components; -a ciphertext C of clen bits.
Although their lengths are defined in bits, all these arguments are required to consist of an integer number of bytes.
AEZ is also parametrized by the authenticator byte length Abytes of default value 16.The corresponding number of bits τ = 8 × Abytes represents the plaintext expansion clen − plen and also the number of zero bits that shall be appended to the plaintext P before encipherment if P is not the empty string.The augmented plaintext (P || 0 τ ) is denoted by P in the sequel and the binary representation of τ as a 128-bit word is denoted by [τ ] 128 .
The AEZ authenticated encryption process can be viewed as follows.First a vectorvalued tweak T = ([τ ] 128 , N, A 1 , • • • , A m ), that encodes the triplet (τ, N, A) is derived.Then, depending on the the plaintext length plen, different encipherment functions are applied: The way the tweak argument T is processed in all these functions consists of deriving an associated universal hash value ∆ = AEZ-hash(K, T ) of length 128 bits and then using ∆ as an offset in some parts of the encipherment computations.
Since we do not use AEZ-tiny in our attack, we only describe AEZ-prf and AEZ-core.

Tweaked Instances of AES4 and AES10 Used in AEZ
AEZ uses AES-based tweakable block ciphers [7] (TBC) using the XE and XEX constructions.Three sub-keys I, J, and L, of length 128 bits each, are used in these TBC, which are derived from the key K in a way that depends of the key length klen : -if klen = 384, then I || J || L = K; -if klen = 384, then I || J || L = BLAKE2b(K), using an instance of the cryptographic hash function BLAKE2b [8] that produces 384-bit hash values.
Given two input tweaks i, j, the TBC E i,j K is defined as follows: where δ i = 2 i−3 and δ j = 8 (j−1)/8 + (j − 1) mod 8.In the former table, AES4 (resp.AES10) are AES variants that consist of 4 (resp.10) full AES rounds parametrized by 5 (resp.11) independent sub-keys.Thus, if we denote the composition of SubBytes, ShiftRows, and MixColumns by aesr we get ), AES10 can be defined in the same way.

AEZ-hash universal hashing
To describe AEZ-hash(K, T ), we assume that the tweak T = (τ, N, A 1 , . . ., A m ), where (A 1 , . . ., A m ) is a m-component vector.This allows to cover both the cases of string-and vector-valued associated data.Let us rewrite T as T = (T 1 , . . ., T t ), where t = m + 2. For each m i -block component T i = B i,1 . . .B i,mi of T , whose last block B i,mi can be complete or incomplete, a partial hash value ∆ i is computed as follows:

PRF Function
AEZ-prf is designed with the purpose to provide a PRF of settable output length τ , that can be viewed as an encipherment of the empty plaintext.The output of AEZ-prf is the τ -bit string given by with ∆ = AEZ-hash(K, T ).

AEZ Core
AEZ-core is the encipherment function used to process augmented plaintexts of at least 256 bits.It takes as input the key K, the tweak vector T and the augmented plaintext P .The vector T is first preprocessed by computing the universal hash value: ∆ = AEZ-hash(K, T ), which will be used as an offset value at some subsequent steps of the encipherment computation.
Then, the augmented plaintext is split as follows into (in)complete 128-bit blocks: where |P * | = |P * | = 128 except for at least one of the values P u and P v , that satisfy In detail, to split P one needs to 1. Take the 256 last bits of P to form P x P y .This is always possible since |P | ≥ 256; 2. For every remaining pair of entire blocks if any form P i P i (starting from the beginning of P ); 3. Letting r = plen + τ mod 256, if r = 0, the remaining bits form -P u if r < 128, -P u P v with an empty block P v if r = 128 The ciphertext blocks are then computed as shown on Figure 1, up to the fact that in the first case (r < 128), the v-column is omitted and the paddings and compressions represented by trapezoids on the v-column are moved to the u-column.
For a more detailed description of AEZ-core and more generally on AEZ v4.1, we refer to the AEZ v4.1 specification [3].

Tweaks from AEZ v3
In a nutshell, the main differences between AEZ v3 and AEZ v4.1 are the following: -the procedure for deriving the subkeys I, J, and L from the key K was entirely modified.The AEZ v3 derivation procedure, that did not involve the BLAKE2b hash function, had indeed the undesirable property that for key lengths such as |K|=128 bits, the knowledge of one of the subkeys implied the knowledge of the key K.Moreover, while a key length of at least 128 bits is recommended in both AEZ v3 and AEZ v4.1, a default key length of 384 bits was introduced in AEZ v4.1; -the tweakable block ciphers involved in the AEZ-hash universal hashing use the XEX construction in AEZ v4.1, whereas they were using the XE construction in AEZ v3.Moreover the offset values used in the definition of the various tweakable block ciphers E i,j K used in AEZ were modified.
One of the motivations for these changes was to thwart the birthday attack on AEZ v3 introduced by Fuhr, Leurent, and Suder in 2015 [6].This attack indeed recovered one of the subkeys (namely J) by leveraging its use in the pre-whitening keys of the XE construction of the AEZ-hash computation underlying the AEZ-prf function.It then took advantage from the undesirable property of the AEZ v3 subkey derivation procedure mentioned above to recover the key K.
While the attack described by Fuhr et al. does not work anymore on AEZ v4.1, we will see in Section 3.1 that the use of the XEX construction in AEZ-hash does not prevent birthday attacks, and Section 3.2 will show that the knowledge of I can be leveraged for recovering the other subkeys J and L.

Attacks on AEZ
In this section, we describe two key derivation attacks: -First, a combination of three independent birthday attacks allowing to retrieve one of the sub-keys I, J, and L each.One limitation of this combined attack comes from the fact that the amount of data that can be processed under one single key is limited to 2 48 bytes, below the 2 64 blocks birthday bound.Its success probability, equal to the product of the success probabilities of the underlying birthday attacks, becomes in the case of a 128-bit key lower than the one of a generic attack.
-Second, a more efficient attack that consists of two phases.In the first phase, of birthday complexity, one of the three former partial attacks is applied to retrieve the value of I.In the second phase, the knowledge of I is leveraged to mount a differential attack against some of the AES4 instances of the encipherment computations.For any reasonable key length, e.g. at least 128 bits, its success probability remains abnormally high (i.e. higher than the one of a generic attack) if the amount of data that can be processed under one single key is limited to 2 48 bytes.

Birthday Attacks
We describe in this subsection three partial attacks of birthday complexity each allowing to recover one of the three sub-keys.
All these partial attacks are based on the following informal observation.Let F and G denote two one-block to one-block functions parametrized by secret keys, δ 1 and δ 2 denote two secret one-block offset values and n denote the block length.Let us assume that an adversary is able to access H(x) = G(F (x ⊕ δ 1 ) ⊕ F (x ⊕ δ 2 )) for sufficiently many chosen block values x.Let us show that if a small multiple of 2 n 2 values of x are tried this allows (under mild conditions on F and G that we will not detail here) to determine the secret offset difference δ 1 ⊕ δ 2 with an overwhelming probability.Indeed, with overwhelming probability, there exists a pair (x, x ) such that x ⊕ x = δ 1 ⊕ δ 2 .It is easy to see that for such a pair, H(x) = H(x ) since the single difference between the computations of H(x) and H(x ) is that the entries of the first and second invocations of F are swapped.Conversely, if H(x) = H(x ), x ⊕ x provides a candidate value for x ⊕ x = δ 1 ⊕ δ 2 that is easy to test using a few extra H computations.
Note that all attacks presented below can be conducted under the assumption of a fixed nonce length, i.e. nlen = 128.We emphasize that the attacks can be transposed, with slight adjustements, to a situation where the nonce is omitted (i.e.nlen = 0).4

Collisions in AEZ-hash
Detecting suitable collisions in the AEZ-hash function allows to recover the two sub-keys J and L by birthday attacks.While AEZ-hash is an internal procedure whose ouput is not directly available to the adversary, such collisions on AEZ-hash can nevertheless be detected by collisions they induce in some AEZ-prf output blocks. 5Let ∆ be the output of AEZ-hash under an unknown key and a chosen entry where we assume that |A| = 128.For simplicity, we also assume τ = 128 bits, but the attack also applies to others value of τ .
Following the description of AEZ-hash, we get: . By replacing E i,j K (X) by its expression we obtain: If we restrict ourselves to (A, N ) pairs of blocks such that A = N , the former expression becomes With this expression, we are able to create a collision on hash values ∆ associated to (N, N ) pairs and this can be used to retrieve the difference L between the first and second offset values applied to N .Indeed, if N = N ⊕ L, let us denote by ∆ the associated hash value.We have: Hence, when N = N ⊕ L, we have ∆ = ∆ .Note that this can be viewed as a direct consequence from the former observation.Indeed, in the former expressions of ∆, N is added with the offsets δ 1 = 2L ⊕ 8J and δ 2 = 3L ⊕ 8J, of difference L, before being input to the function F = AES4 K .

Recovering the Sub-key L
The former remark allows to build the following birthday attack: 1. Collect H(N ) = AEZ-prf(K, T, τ ) with T = (τ, N, N ) for 2 64 values of N , 2. If a collision occurs, this implies H(N ) = H(N ) since AEZ-prf is just an overencryption of the AEZ-hash output and therefore L is likely to be equal to N ⊕ N .
For this attack we need about 2 64.2 pairs (N, A = N ) of input blocks to succeed with a probability of about 0.5.If the amount of input data is restricted to the limit of 2 44 blocks imposed by the designers, the success probability drops to 2 −43 .

Recovering the Sub-key J
The previous method can be used to retrieve J in a nonce-misuse scenario where a fixed nonce value N is repeated (which should result in no security degradation if the other AEZ input data are not repeated since an optimal nonce-misuse resistance is claimed).Indeed one can remark that using the previous notation except letting where N is a fixed nonce value of length 128 bits, A is a variable one-block string, and the default value of 128 bits is assumed for τ .Using the description of AEZ-hash one can write which implies ∆ = ∆ .One can then build the following attack to recover J.

If a collision happens, this implies H(A ) = H(A)
and therefore J is likely to be equal to A ⊕ A .
To reach 2 64.2 queries and a probability of success of about 0.5 we need to run the algorithm with 2 65.8 blocks of data.If the amount of input data is restricted to 2 44 blocks, the recovery of J succeeds with probability 2 −44.2 .

Collision in AEZ-core
The last sub-key that remains unknown is I.We show how to recover it using a birthday attack within the AEZ-core function.
Let us consider 6-block augmented plaintexts: where B denotes a one-block string and τ = 128 bits.In this partial attack, we assume that a fixed nonce value N and no associated data are used.Note that plaintext messages of length only five blocks are being used since the last block 0 τ corresponds to the ciphertext expansion.
Next, we denote by X the intermediate value associated with the two first pairs of blocks, that is used as an offset in the P x , P y part.We remind that X = X 1 ⊕ • • • ⊕ X m in general.In our case, we have X = X 1 ⊕ X 2 which, once developed, becomes We can rewrite this expression as and notice that if B = B ⊕ I then X = X .This leads to a similar attack to the one on J and L. Indeed one can remark that collisions on the value of X induce collisions in the value of C y since the single difference affecting the (P x , P y ) part of the computation is the introduction of distinct values Y and Y , that only affect the value of C x , not the value of C y .
In summary, we search for collisions on the value of C y to detect collisions on X (as shown in Figure 2).
The following steps describe the attack exploiting the preceding remark.
1. Collect C y,B from the encipherments AEZ-core(K, T, P ) associated to 2 64 values of B.
2. If a collision occurs, i.e.C y,B = C y,B , then I is likely to be equal to B ⊕ B and this is easy to test using another value of B.
We need to encrypt 2 66.3 blocks of data to expect a collision with probability 0.5.If the amount of input data is restricted to 2 44 blocks, the recovery of I succeeds with probability 2 −45.6 .

Summary of Birthday Attacks
We have presented three partial attacks, each allowing to recover one of the three sub-keys I, J, and L. The following table summarizes the data complexity required by each attack for a success probability of 0.5 and their success probabilities if the amount of input data is limited to 2 44 blocks.The time complexity of these attacks is equal to the time complexity for a single query multiplied by the query complexity.
Difference propagation in the birthday attack to retrieve I.
The former partial attacks can be combined to recover the three sub-keys.However, when restricted to the encryption of 2 44 blocks, this combined attack succeeds, in the case of a 128-bit key, with a lower probability than a classical brute-force attack. 6Chosen plaintexts 7 In this row, the data and query complexities were derived as the sum of the data (resp.query) complexities for recovering I, J, and L with a probability of 0.5 1/3 in three birthday attacks, as to ensure that the success probability is 0.5 for the combined attack.

AES4 Cryptanalysis
We previously described partial attacks allowing to recover one of the three sub-keys used in AEZ and a resulting combined attack.We now describe an attack which, assuming the sub-key I has been retrieved using the last partial attack presented before, allows to efficiently recover the two others sub-keys J and L.
As in the partial attack allowing to recover I, we assume that τ = 128 and we use a fixed nonce value N and no associated data in all considered encryptions.

Conducting Idea
Mounting a differential attack that targets the first AES4 encryption of the P u part of the AEZ-core function allows to leverage the knowledge of I to recover J and L. Since I is known, this eventually boils down to attacking only three AES rounds instead of four.Although the differential cryptanalysis of 3-round AES is simple and well studied, the context of the attack for AEZ is more constrained and requires dedicated analysis.We therefore describe in some detail how to take these constraints into account. Let , where P u denotes a 128-bit block.Since (plen + τ ) mod 256 = 128, an empty block P v is introduced in the computation of X, that we denote by R = E 0,5 K (1 || 0 127 ).The resulting offset value X is: The detailed computation of X is summarized in Figure 3.
To obtain information on J and L, one can search pairs of P u values whose differential behaviour in the three last rounds of the AES4 computation follows a 4-1-4 differential characteristic.In other words, at the input to the second, third, and fourth rounds, we want the associated state values to only differ on 4 bytes, resp. 1 and 4 bytes, as shown in Figure 4.  We are using the numbering convention of Figure 5 for the AES state bytes.Let us denote by ∆(x 1 , . . ., x l ) the vector space of difference values equal to zero everywhere outside from the byte positions x 1 , . . ., x l .The expected differential behaviour at rounds 2, 3, and 4 is the following.Let (S 0 , S 0 ) denote a pair of chosen second round input values before the addition of J, of difference S 0 ⊕ S 0 ∈ ∆(0, 5, 10, 15)) and δ x denote a difference value from MC(∆(0, 7, 10, 13)).(S 0 , S 0 ) can be derived from the chosen pair of P u values (P u = aesr −1 (S 0 ) ⊕ 4I, P u = aesr −1 (S 0 )) ⊕ 4I) and one can test whether the differential behaviour of this pair is the desired one and the resulting AES4 output difference is equal to δ x .Indeed, let (P x , P x ) be a pair of P x blocks of difference P x ⊕ P x = δ x and P y = 0, and let (C v , C x , C y ) = AEZ-core(K, T, (P u , P x , P y )) (C v , C x , C y ) = AEZ-core(K, T, (P u , P x , P y )).
Then we get C y = C y since the differences on the X offset values and on the P x values cancel out.In Figure 6, the difference propagation is represented by the red pattern.Note that C y = C y happens with a negligible probability of about 2 −128 if the tested condition is not met.We now show that the use of appropriate structures of (P u , P x ) values -obtained as the cartesian product of smaller structures of P u and P x values -allows to efficiently get C y = C y collision.

Structure of P u values
We want to test at least one pair (S 0 , S 0 ) of difference value S 0 ⊕ S 0 ∈ ∆(0, 5, 10, 15) that leads after the second round to a difference value that belongs to the set ∆(0).A simple heuristic argument indicates that testing about 2 24 (S 0 , S 0 ) pairs should suffice for this to happen.Since picking S 0 and S 0 from a subset of S of ∆(0, 5, 10, 15) of size 2 m , m ≤ 16, allows to cover approximately 2 2m−1 such pairs, selecting a structure S of 2 12.5 such values can be expected to suffice to obtain a good pair with a sufficient probability.
The resulting structure of P u values that we use in the sequel is U = aesr −1 (S) ⊕ 4I.We expect at least one pair of U elements to have the expected differential behaviour.

Structures of P x and P x values
At the output of the AES4 function we want the difference to belong to the image of ∆(0, 7, 10, 13) by MixColumns.Since MixColumns is a linear operation, such a difference, denoted δ x , can be expressed as follows, δ x = δ x,(0,7) ⊕ δ x,(10,13) with δ x,(0,7) ∈ MC(∆(0, 7)) and δ x,(10,13) ∈ MC(∆(10, 13)).This decomposition, in combination with the previous structure, allows to reduce by a squared factor the sets of tested P x and P x values.This is explained in the next section.

How to Find a Good Pair
We can use cartesian products of the structures defined above to find a collision with an improved data complexity.
We call observation the block C y,Pu,Px resulting from the encryption of the plaintext P u || P x || 0 128 .With the previous notations, one can remark that if C y,Pu,Px = C y,P u ,P x then with overwhelming probability: By construction, P u and P u values are selected in such a way that the resulting round 2 input difference δ in = aesr(P u ⊕ 4I) ⊕ aesr(P u ⊕ 4I) belongs to ∆(0, 5, 10, 15), and P x and P x values were selected in such a way that their difference δ out = P x ⊕ P x can take any value from ∆(0, 7) ⊕ ∆(10, 13) = ∆(0, 7, 10, 13).
Therefore we can expect at least one equality C y,Pu,Px = C y,P u ,P x to happen and with overwhelming probability the underlying (P u , P u ) pair is a good pair of second round input difference δ in and fourth round output difference δ out .
On can also note that this method can be extended to the following differential patterns.

Sub-keys Recovery
Once a collision C y,Pu,Px = C y,P u ,P x occurs, we obtain a good pair (P u , P u ) with a known AES4 output difference δ out = P x ⊕ P x .This can be used to retrieve information on the sub-keys J and L.
method to the one used to find the right value of J, based on the former observation used for the birthday attack, can be used in order to find the right value of L.

Algorithm and Complexity to Recover J and L
In summary, the following algorithm allows to find the values of J and L assuming that I is known.
5. For each good pair, compute the about 275 candidate quartets of J bytes that are compatible with δ i in .
6. Test with AEZ-prf all the candidate values to find J.
7. For each good pair, compute the candidate quartets of L bytes that are compatible with the δ i out .
8. Test with AEZ-prf all the candidate values to find L.
-Step 3 : Finding a collision can be achieved with a time complexity of about 2 33.3 .This a computational cost, so the query complexity is not affected.
-Step 5 : With pre-computation of all solutions for SB(X ⊕ δ in ) = SB(X) ⊕ δ mid with any δ in , δ mid the candidates are easily computed with a time complexity of 2 24 .As for Step 3 this phase does not require additional queries.
-Step 7 : No more cost since the pre-computation used in Step 5 can be reused here.
The final cost to find J and L is given in Table 3 below.This part of the attack was successfully validated on the public implementation of AEZ v4.1.This allowed to confirm that J and L can be recovered once I has been recovered.

Results of Our Attack
As described our attack works in two phases : first, find the sub-keys I by a birthday attack, and then, recover the two other sub-keys J and L by attacking AES4.Since the number of queries needed in the attack is far greater than the offline time complexity, the latter is insignificant in comparison of other costs and so, not included in the complexity of our attack.The final cost of our attack, depending on whether the data limit of 2 48 bytes is respected or not, is given in the following

Conclusion
One of the purposes of the modifications between AEZ v3 and AEZ v4.1 was to fix an undesirable property allowing to recover the whole key from one of the sub-keys used in AEZ.Our paper shows that this property remains despite the changes.We show a key-recovery attack that allows to recover the three sub-keys from the knowledge of only one.
These modifications were also partly motivated by thwarting an attack of birthday complexity allowing to recover one of the subkeys.We described three birthday attacks on AEZ v 4.1 allowing to retrieve one of the three sub-keys.
Even though no claim for beyond birthday security has been made and our attack does not violate the security claims for AEZ, it raises some doubts regarding the resilience of AEZ against key-recovery attacks when the amount of processed data approaches the birthday bound.

A
Computation of the Average Number of Candidates for a Quartet of Bytes of Sub-key J If we let a, b represent two non-zero random one-byte differences, then the equation sbox(X ⊕ a) = sbox(X) ⊕ b may have 0, 2 or 4 solutions (sbox corresponds to the AES S-box).These number of solutions stand with their respective probabilities which are: #{X | sbox(X ⊕ a) = sbox(X) ⊕ b} =      0 with p 0 = 128 255 2 with p 2 = 126 255 4 with p 4 = 1 255 .