A New Mode of Operation for Incremental Authenticated Encryption with Associated Data
Abstract
We propose a new mode of operation for authenticated encryption with associated data (AEAD) that achieves incrementality and competitive performance with many designs in CAESAR. The incrementality of a function \(F(\cdot )\) means the property that once F(x) is stored, the value \(F(x^{\prime })\) with a slightly modified input \(x^{\prime }\) can be updated from F(x) much faster than computing \(F(x^{\prime })\) from scratch. It turns out that the security of incremental AEAD needs to be treated carefully. Incremental operations leak more information than ordinary ones. Moreover, if the scheme is noncebased, nonce repetition must be taken into account. We discuss which structures are (un)suitable for incrementality. Parallelizability is a minimum requirement, but there are many other requirements, often subtle and complex, especially for combining associated data A with a message M. For example, using PMAC for both A and M would spoil incrementality. We go through 57 designs submitted to CAESAR and show that none of them meets all the requirements. It turns out that options are quite limited and the design of an incremental AEAD mode is almost uniquely determined. We propose a new construction providing incremental operations such as update, append and chop. Interestingly, our encryption part is composed of the XE construction instead of XEX, hence optimizing the efficiency.
Keywords
Incremental cryptography AEAD PMAC OCB CAESAR EncthenMAC XE1 Introduction
Recently, many AEAD schemes have been proposed especially for CAESAR [10], which determines a new portfolio of AEAD. AEAD schemes are evaluated in many criteria including the performance in various platforms, security of integrity/confidentiality in noncerespect/noncerepeat models, and additional features such as parallelizability, provable security, length optimality, efficient processing for repeated associated data, variable tag size, a small masking cost against sidechannel analysis, etc. Incrementality is one of such additional features.
Incremental cryptography was introduced by Bellare et al. [6]. Suppose that an input x was once processed by a function \(F(\cdot )\), and the output was stored. Then, a fraction of x is modified to \(x^{\prime }\). The incremental cryptography allows to quickly update F(x) to \(F(x^{\prime })\) in time proportional to the amount of modification made to x, which is faster than recomputing \(F(x^{\prime })\) from scratch.
Incremental cryptography in early days focused on hashing, signature, and MAC rather than encryption [6, 8]. A work in [7] initiated the discussion for incremental encryption/decryption. The security of incremental encryption schemes is always worse than the ordinary schemes. [7] introduced the security policy as hiding all the information other than the amount of difference for incremental operations. The proposed schemes provide most of practical operations i.e. update, delete, and insert. As a drawback, their scheme requires extra randomness and the randomness must be sent to a verifier, which causes a tag expansion. Moreover the construction needs to make the plaintext size at least twice of the original plaintext so that the modification history for all message blocks are recorded in the extended blocks.
More closely related work is the one by Buonanno et al. [15] about incremental AE (without AD). Buonanno et al. study a generic composition of probabilistic encryptions and incrementalMACs (instantiated with randomized ECB and the XOR scheme in [7]) to achieve a provable security with respect to unforgeability. One of the proposed schemes, RPCmode, provides insert and delete functionalities. As a sideeffect, the encryption cost becomes 4 times more than the ordinary scheme, which is unlikely to be accepted in the CAESAR competition.
There are a few more researches on incremental cryptography, e.g. bytewise incremental encryption [4, 5] and incremental MAC with SHA3 [18]. We omit their details in this paper.
Achieving the incrementality for both of the efficient encryption and MAC at the same time is not an easy task. Considering the basic requirements of the incrementality, the following two conditions are inevitable: (1) parallelizability for encryption and decryption and (2) the same nonce must be iterated multiple times, thus the scheme must provide some robustness against nonce repetition. The GCM mode [28] can meet the first condition. However, under the noncerepeating model, the key stream for all blocks are leaked, which does not meet the second condition. The OCB mode [35] can meet the both conditions for encryption/decryption. However, its authentication (tag generation) is the encryption of the message checksum, which can be broken easily under the noncerepeating model. The COPA mode [2, 3] is parallelizable and noncemisuse resistant. However, its onlineness, i.e. modifying 1 message block affects all the subsequent blocks, cannot allow the incremental operation.
Our Contributions. This paper investigates incremental AEAD. Our final goal is developing a new mode of operation for incremental AEAD, which is also secure and practically efficient; as efficient as CAESAR candidates. Therefore, we avoid the ciphertext expansion, tag expansion, and extra randomness. We make the scheme simple and minimize the cost of each operation. We begin with formalizing noncebased incremental AEAD. Then, we investigate various operations used in the CAESAR candidates with respect to (un)suitability for the incremental operation. Finally we propose a new mode of operation with security proof. Contributions of this paper are further detailed as follows.
 1.
Formalization. As pointed out by Bellare et al. [7], in principle it is inevitable that incremental operations, especially encrypting, should leak more information than ordinary, nonincremental ones. In particular, for noncebased schemes [34], one needs to carefully consider the problem of security under “nonce repetition.” Moreover, in noncebased AEAD [32], the combination of various components raises subtle and complex issues. In this work, a framework of incremental AEAD is formalized, rigorously defining the syntax of incremental operations, the model of adversaries, and the notion of security.
 2.
Design Requirements. The presence of associated data A causes potential problems, which need to be carefully addressed. For instance, consider EncthenMAC approach [9]. Suppose that A is processed by PMAC [13] and that its output and C are again processed by PMAC. We call this construction layered PMAC and illustrate it in Fig. 1. Here one would expect the parallelizability of PMAC to be useful for incremental operations. However, one would soon notice that incremental operations cannot be performed on A, since the two PMACs are “stacked.” This motivates us to slightly change the processing method for A from PMAC to the one used in OCB3 [26]. The resulting scheme is illustrated in Fig. 2. This scheme now allows incremental update of A. In this way we identify suitable and unsuitable constructions for designing an incremental AEAD mode of operation.
 3.
New Mode of Operation. It turns out that there are a number of requirements essential for a secure incremental AEAD mode of operation. Indeed, we perform a survey on the CAESAR candidates and confirm that none of them fulfills all the requirements. This motivates us to build a new mode that satisfies all these conditions. Interestingly, options are quite limited, and the overall structure of the mode is almost uniquely determined according to the design conditions. Fortunately there is one that satisfies all the conditions. This work presents one concrete, optimized example. The new AEAD mode achieves greater efficiency and enables incremental operations at a minimal cost. Unlike previous proposals [7], the new mode does not need ciphertext expansion, tag expansion, or additional randomness. The computational cost of incremental operations is only linear to the number of blocks to be updated. The new mode is capable of executing update, append and chop operations.
The overall design of the new AEAD mode is inspired by PMAC [13] which was already incremental to a certain degree. Specifically, we utilize XE construction [33] within EncthenMAC paradigm [9]. Unlike OCB [35], the XE construction, rather than XEX [33], turns out to be sufficient for realizing the encryption part, owing to the EncthenMAC composition and “verifythendecrypt” functionality [1]. This reduces the number of masks and the cost of an XOR operation per block.
2 Our Goals
We begin with stating properties that we want an incremental AEAD scheme to have. At the same time we mention properties that we do not—that is, the properties that ordinary AEAD schemes possess but seem “incompatible” with incrementality and inessential in the practical use.
Let \(\varPi \) be an AEAD scheme. Let N denote the nonce. Let \(A=A_1A_2\cdots A_a\) be associated data divided into nbit blocks \(A_i\). Let \(M=M_1M_2\cdots M_m\) be a message and \(C=C_1C_2\cdots C_m\) the ciphertext. Let T denote the tag. In the following we consider the case of incremental authenticated encryption; the case of verification and decryption can be treated in the same manner.
Types of Incremental Operations. We demand \(\varPi \) to be capable of update, append and chop operations on A and M, since these appear to be feasible by basing on a PMAClike internal structure. Here, the update operation either recomputes new \(T'\) given new \(A'_i\) and the original T and \(A_i\) or recomputes new \(T'\) and \(C'_i\) given the new \(M'_i\) and the original T, \(C_i\) and \(M_i\). The append operation either recomputes new \(T'\) given an additional data block \(A_{a+1}\) and the original T or recomputes new \(T'\) and \(C'_{m+1}\) given an additional message block \(M_{m+1}\) and the original T. The chop operation is similarly defined. It should be noted that in many of the existing noncebased AEAD schemes [32] the ciphertext C is not affected by A, which is a desirable property for incremental AEAD.
Efficiency. We demand the incremental operations to be efficient. Specifically, the computational cost should increase only linearly to the number of blocks to be modified.
NonceBased. We follow the wellestablished noncebased framework, which was formalized by Rogaway [34]. The crucial problem here is that incremental operations by definition imply the use of the same nonce value N multiple times, which contradicts the security notions of noncebased framework. We formalize the security notions under such circumstances.
No Randomization or Expansion. Since we follow the noncebased framework, we do not allow \(\varPi \) to be randomized. In general randomization would require the use of pseudorandom number generator, which is costly. Moreover, randomization would expand the output size of the encryption algorithm. We would like to keep the original size of the ciphertext and the tag of an ordinary noncebased AEAD scheme.
3 Formalization
In this section we formalize the framework of incremental AEAD by defining its algorithmic syntax, adversarial model, and security notions.
3.1 Syntax
An incremental AEAD scheme \((\varPi ,\varDelta )\) consists of an ordinary AEAD algorithms \(\varPi =(\mathcal {E}_K,\mathcal {D}_K)\) and the set of incremental operations \(\varDelta \) which consists of \((\mathbb {U}^\mathrm {A}_K,\mathbb {A}^\mathrm {A}_K,\mathbb {C}^\mathrm {A}_K)\) for associated data and \((\mathbb {U}^\mathrm {M}_K,\mathbb {A}^\mathrm {M}_K,\mathbb {C}^\mathrm {M}_K)\) for the message part. The syntax of these algorithms are as follows.

The encryption algorithm \(\mathcal {E}_K\) takes as input a nonce \(N\in \mathcal {N}\), associated data \(A\in \mathcal {A}\) and a message \(M\in \mathcal {M}\) and outputs a pair (C, T) of ciphertext \(C\in \mathcal {C}\) and tag \(T\in \{0,1\}^n\), so that we have \((C,T)\leftarrow \mathcal {E}_K(N,A,M)\). For simplicity we assume that the length of associated data A, of a message M, or of ciphertext C is always a multiple of n bits.

The decryption algorithm \(\mathcal {D}_K\) takes as input a nonce N, associated data A, a ciphertext C and a tag T and outputs either the reject symbol \(\bot \) or a message M, so that we have \(\bot \text { or }M\leftarrow \mathcal {D}_K(N,A,C,T)\).

We demand that \(\mathcal {E}_K\) and \(\mathcal {D}_K\) should be consistent; that is, whenever \((C,T)\leftarrow \mathcal {E}_K(N,A,M)\), we must have \(M=\mathcal {D}_K(N,A,C,T)\).

The update operation \(\mathbb {U}^\mathrm {A}_K\) takes as input a nonce N, the position i to be updated, the original \(A_i\), the new \(A'_i\) and the original T and outputs a new tag value \(T'\), so that \(T'\leftarrow \mathbb {U}^\mathrm {A}_K(N,i,A_i,A'_i,T)\). Similarly, the update function \(\mathbb {U}^\mathrm {M}_K\) takes as input a nonce N, the position i to be updated, the original \(C_i\), the new \(M'_i\) and the original T and outputs a new ciphertext block \(C'_i\) and a new tag value \(T'\), so that we have \((C'_i,T')\leftarrow \mathbb {U}^\mathrm {M}_K(N,i,C_i,M'_i,T)\).

The append operation \(\mathbb {A}^\mathrm {A}_K\) takes as input a nonce N, the current number of blocks a of A, a new block \(A_{a+1}\) to be appended, and the original T and outputs a new tag value \(T'\), as \(T'\leftarrow \mathbb {A}^\mathrm {A}_K(N,a,A_{a+1},T)\). Similarly, the append function \(\mathbb {A}^\mathrm {M}_K\) takes as input a nonce N, the current number m of ciphertext blocks, the new \(M_{m+1}\) and the original T and outputs a new ciphertext block \(C_{a+1}\) and a new tag value \(T'\), so that we have \((C_{m+1},T')\leftarrow \mathbb {A}^\mathrm {M}_K(N,m,M_{m+1},T)\).

The chop operation \(\mathbb {C}^\mathrm {A}_K\) takes as input a nonce N, the current number a of blocks in A, the original \(A_a\), and the original T and outputs a new tag value \(T'\), so we can write \(T'\leftarrow \mathbb {C}^\mathrm {A}_K(N,a,A_{a},T)\). Similarly, the chop function \(\mathbb {C}^\mathrm {M}_K\) takes as input a nonce N, the current number m of ciphertext blocks, the original \(C_m\), and the original T and outputs a new tag value \(T'\), and so we simply have \(T'\leftarrow \mathbb {C}^\mathrm {M}_K(N,m,C_m,T)\).

We demand that the incremental operations are consistent with each other; that is, if the same value of a block \(A_i\) or \(M_j\) is “restored” after performing a sequence of incremental operations, then we must have the same value for \(C_j\) and T.

We demand that the incremental operations are consistent with the encryption and decryption algorithms; that is, if \((N,A',C',T')\) is a result after performing incremental operations, we must have \(M'=\mathcal {D}_K(N,A',C',T')\).
3.2 Adversarial Model
An adversary is an oracle machine. In the conventional setting of AEAD, an adversary \({\varvec{A}}\) is given access to the encryption oracle \(\mathcal {E}_K(\cdot ,\cdot ,\cdot )\) and the decryption oracle \(\mathcal {D}_K(\cdot ,\cdot ,\cdot ,\cdot )\). We follow the framework of noncebased symmetrickey encryption and demand that \({\varvec{A}}\) should be noncerespecting to its encryption oracle. That is, adversary \({\varvec{A}}\) is not allowed to use the same value of N in making queries to its encryption oracle \(\mathcal {E}_K\).
Now in the current setting of incremental AEAD we give \({\varvec{A}}\) access also to the incremental oracles, \(\mathbb {U}^\mathrm {A}_K\), \(\mathbb {A}^\mathrm {A}_K\), \(\mathbb {C}^\mathrm {A}_K\), \(\mathbb {U}^\mathrm {M}_K\), \(\mathbb {A}^\mathrm {M}_K\) and \(\mathbb {C}^\mathrm {M}_K\). We forbid \({\varvec{A}}\) from making queries to these incremental oracles with an “unused” nonce N; that is, these values of N which have not been used in the encryption oracle \(\mathcal {E}_K\). We write \(\varDelta =(\mathbb {U}^\mathrm {A}_K,\mathbb {A}^\mathrm {A}_K,\ldots ,\mathbb {C}^\mathrm {M}_K)\) to gather the six oracles.
Since we assume that adversary \({\varvec{A}}\) is noncerespecting and does not make incremental queries with an unused nonce, from the value of N it should be clear which (A, C, T) is relevant when \({\varvec{A}}\) makes a query to one of its incremental oracles. We allow \({\varvec{A}}\) to interleave its queries to the encryption, decryption and incremental oracles. \({\varvec{A}}\) can make its queries to these oracles in any combination.
Suppose that \({\varvec{A}}\) has access to its oracles \(\mathcal {O}_1,\mathcal {O}_2,\ldots \). We write \({\varvec{A}}^{\mathcal {O}_1,\mathcal {O}_2,\ldots }\) to denote the value returned by \({\varvec{A}}\) after interacting with its oracles.
3.3 Security Notions
In the conventional AEAD, the key notions of security were privacy and authenticity. We follow these notions. We formalize the notions of security and authenticity when adversaries have additional access to the incremental oracles.
Privacy. In the conventional AEAD setting the notion of privacy was defined in terms of indistinguishability between the real encryption oracle \(\mathcal {E}_K\) and the ideal oracles \(\$\) where \(\$\) is an oracle having the same interface with \(\mathcal {E}_K\) but returns a random string of expected length upon a query (N, A, M). Here of course the adversary is assumed to be noncerespecting.
Authenticity. In the conventional AEAD the authenticity was defined in terms of unforgeability under chosenmessage attacks. Here adversary \({\varvec{A}}\) is given access to both the encryption oracle \(\mathcal {E}_K\) and the decryption oracle \(\mathcal {D}_K\). By a forgery we mean the event that \({\varvec{A}}\) makes a nontrivial query (N, A, C, T) to its decryption oracle where the oracle would return something other than the reject symbol \(\bot \).
4 Design Requirements
Parallelizability. An obvious requirement to be incremental is the parallelizability for encryption, decryption and tag generation. Ideally, those computations should be blockwise, but they can be processed with neighboring blocks as long as the scheme is parallelizable. This requirement excludes several design principles, e.g. online ciphers with uptoprefix privacy and offline ciphers. Serial designs, e.g. SpongeWrap [11], is also excluded.
Encryption for Combined Data. For the MAC generation, intermediate values computed in parallel must be combined efficiently. The combined data is sensitive, thus some secure finalization computation must be applied to the combined data so that adversaries cannot recover it from the tag. Moreover, when a part of blocks are modified for incremental operations, the combined data also needs to be updated. Ideally, the design allows to obtain the combined data without touching any unmodified blocks. The possible solution is recovering the combined data from the tag with the knowledge of the key. Those constraints lead to the usage of encryption for the combined data.
Security Against Nonce Reuse. During the incremental operations, unmodified blocks need to stay unchanged, which requires the reuse of the same nonce. Thus, the scheme must provide some robustness against noncerepeating adversaries. As a result, the schemes using keystream for encryption and decryption like GCM is not suitable. Indeed, trivial attacks can be mounted against GCM with incremental operation. The adversary first makes query of (N, A, M) to the encryption oracle and obtains the corresponding (N, A, C, T). Key stream can be recovered with \(M \oplus C\). Then, the adversary incrementally modifies a fraction of M to \(M^{\prime }\). The nonce N is repeated and the key stream never changes, which allows to predict corresponding \(C^{\prime } = M^{\prime } \oplus \mathtt{key stream}\). Similarly, integrity must be ensured against the nonce repetition to avoid trivial distinguishers. Encrypting the checksum of M as OCB is unsuitable for incremental AEAD.
No Layered PMAC. Associated data A needs to be incorporated carefully. An unsuitable choice is a layered PMAC in Minalpher [36], which computes a tag by \(\mathrm {PMAC}(\ \mathrm {PMAC}(A)\Vert C\ )\). Because \(\mathrm {PMAC}(A)\) cannot be recovered from T, the user cannot update A incrementally. A slightly modified procedure in OCB3 [26] can avoid this problem. Let \(\text {OCB3}^{A}\) be the function to process A in OCB3, which initializes \(\varSigma \) to 0 and updates it as \(\varSigma \leftarrow \varSigma \oplus E_{K}(A_i \oplus L_i)\) for \(i=1,2,\ldots ,n\). In short, the special treatment of the last block of PMAC is removed. The original motivation of replacing PMAC with \(\text {OCB3}^{A}\) was improving hardware implementation, but it also makes the scheme suitable for incremental AEAD. Namely, if the tag is computed as \(\mathrm {PMAC}(\ \text {OCB3}^{A}(A)\Vert C\ )\), both of A and C can be incrementally updated (see Figs. 1 and 2).
Parallel Mask Generation. The mask for each block needs to be generated in parallel. Using serial pseudorandom number generates for generating masks is unsuitable for incremental AEAD.
5 Survey of Existing Schemes
We investigate the modes of operation for 57 algorithms submitted to CAESAR with respect to the suitability for incremental AEAD. We list the algorithms providing blockwise encryption and discuss their suitability for incremental AEAD. GCM is also discussed for comparison.

CPFB [30] basically follows the CTR mode. In each block, the keystream is generated with XOR of the counter and the previous plaintext block. The serial structure of the decryption and the reproduction of the same keystream in the noncerepeating model make CPFB unsuitable for incremental AEAD. The tag generation is suitable for incremental AEAD. In short, it initializes \(\varSigma \leftarrow 0\) and generates a tag T for \(A_1,\ldots ,A_m\) and \(M_1,\ldots ,M_n\) as \(\varSigma \leftarrow \varSigma \oplus E_K(A_i\Vert i) \text{ for } i=1,\ldots ,m,\)\(\varSigma \leftarrow \varSigma \oplus E_{K_j}\bigl ( (M_j\Vert j)\oplus K \bigr ) \text{ for } j=1,\ldots ,n,\) and \(T \leftarrow E_{K^{\prime }}(\varSigma \oplus L)\), where \(K,K_j,K^{\prime }\), and L are key and mask values. Each block can be incrementally updated after \(D_{K^{\prime }}(T) \oplus L\) is computed.

Enchilada [20] processes M with the XEX construction and computes tag with \(\mathrm {GHASH}(A,C)\), which seems suitable for incremental AEAD. However the mask values for the XEX construction are generated by ChaCha streamcipher, which breaks parallelizability.

GCM [28] adopts the CTR mode. The reproduction of the same keystream in the noncerepeating model raises a security concern for incremental AEAD.

iFeed [37] processes A with PMAC and processes M with the inversion of the CBC mode. The tag is generated by \(\text {CBCMAC}(M) \oplus \mathrm {PMAC(A)}\) with the ciphertext translation. Decryption of iFeed is not parallelizable and the ciphertext translation spoils incremental operations.

Minalpher [36] processes M with the XEX construction and computes tag with layeredPMAC, i.e. \(\mathrm {PMAC} ( \ \mathrm {PMAC(A)}\Vert C \ )\). The layered PMAC spoils incremental AEAD. The blockcipher is built with the doubleblocklength permutation with the EvenMansour construction which causes the tag truncation at the end. The serial mask generation is also a drawback.

OCB [27] is also used in some other designs including CBA [21], Deoxys [22], Joltik [23], KIASU [24], and SCREAM [19]. The only but important concern for OCB is the integrity in the noncerepeating model.
 OTR [29] which is also used in PrøstOTR [25] is similar to OCB except that encryption and decryption are processed in every 2 blocks with 2round Feistel network. Interestingly, security of OTR is worse than OCB for incremental AEAD. In addition to the modified block position, it leaks how the 2 blocks are modified. Suppose that \(M_{2i}\) and \(M_{2i1}\) are encrypted aswhere L and \(\delta \) are mask values. Then, incrementally updating \(M_{2i}\) only simply affects to \(C_{2i1}\), which does not provide the ideal confidentiality.$$\begin{aligned} C_{2i1}&= E_K(2^{i1}L \oplus M_{2i1}) \oplus M_{2i}, \\ C_{2i}&= E_K(2^{i1}L \oplus \delta \oplus C_{2i1}) \oplus M_{2i1}, \end{aligned}$$

PAEQ [12] works like the CTR mode with a big permutation. In each block, a part of permutation output is used as keystream which raises the problem against noncerepetition. The overall structure for tag generation, which takes XOR of results of each message block and each associated data block then performs the permutation at the end, is suitable for incremental AEAD. However, the last permutation output is always truncated due to the big permutation size, which prevents incremental operations.

\(\pi \)Cipher [17] has the similar structure as PAEQ. Besides the security issue about the reproduction of keystream, the tag for A and M are lastly XORed for the ciphertext translation, which is unsuitable for incremental AEAD.

Silver [31] is a tweakable blockcipher (TBC) based design. The computation structure basically follows the one in OCB in a TBC level. Similarly to OCB, the integrity in the noncerepeating model is the main drawback.

YAES [14] processes A with a PMAClike structure. The encryption is similar to the CTR mode. The PMAClike structure is again used by taking intermediate value of each block as input. Finally, the results of two PMAClike computations are XORed for ciphertext translation. Reproduction of keystream and ciphertext translation are unsuitable for incremental AEAD.
Summary is available in Table 1 in Appendix. None of the existing schemes achieves incremental AEAD. In the next section, we will propose a new construction suitable for incremental AEAD.
6 A Concrete Example
6.1 Choice of Generic Constructions
Encryption Cost. Encryption with those approaches are illustrated in Fig. 4. For incremental AEAD, \((C,T) \leftarrow (K,N,A,M)\) is once computed and (K, N, A, C, T) is stored for decryption. An important remark is that M disappears in the 5tuple value passed to the decryption side. Then, for modified values \((A^{\prime },M^{\prime })\), new values \((C^{\prime }, T^{\prime })\) are updated from \((C,T,A^{\prime },M^{\prime })\).
As illustrated in Fig. 4, E&M and MtE are similar. With MtE, modifying 1 bit of A can affect to C, which is not desired for the incrementality. Hereafter, we exclude MtE from our choices and show the comparison between EtM and E&M.
The incremental update operation requires the following computations.
 1.
Recover the intermediate value \(\varSigma \) from T.
 2.
Compute the impact from old (A, X) to \(\varSigma \) for the modified blocks.
 3.
 (a)
If M is modified to \(M^{\prime }\), compute new \(C^{\prime }\) for the modified blocks. (skip if only A is modified)
 (b)
Compute the impact from new \((A^{\prime },M^{\prime })\) to \(\varSigma ^{\prime }\) for the modified blocks.
 (a)
 4.
Compute new \(T^{\prime }\) from \(\varSigma ^{\prime }\).
Let us consider the cost of the update operation in EtM and E&M when s blocks are modified. In Step 1, both approaches require 1block computation of \(H_K^{1}\). Step 2 yields a difference. In EtM, X is C which is stored in (K, N, A, C, T), thus it requires sblock computations. While in E&M, X is M however M is not stored. M needs to be recovered from C and then the impact from M to \(\varSigma \) is computed, which requires 2sblock computations. In Step 3, both approaches require between 2s and sblock computations depending on how many blocks of A and M are modified. In 4, both approaches require 1block computation. In the end, Step 2 yields a difference and it brings an advantage for EtM.
Regarding the append operation, Step 2 can be removed from the above procedure, because the append operations only adds the new impact to \(\varSigma \). Hence, the advantage of EtM disappears. Regarding the chop operation, Step 3 is removed from the above procedure, because nothing new is added to \(\varSigma \). Hence, EtM keeps the advantage over E&M. All in all, we conclude that EtM is better for incremental encryption.
Decryption Cost. Decryption with EtM and E&M are illustrated in Fig. 5. \((M,T) \leftarrow (K,N,A,C,T)\) is once computed and (K, N, A, M, T) is stored for incremental computations. C does not have to be stored. There are two ways to utilize incrementality of decryption. In the first way, the tag verification fails and later only a fraction of (A, C) is modified as correction. In the second way, after decrypting (K, N, A, C, T), it is expected to decrypt the similar tuples of \((A^{\prime }, C^{\prime })\). Actually, authentication of several messages in which only the header part is different was the original motivation of the incremental cryptography [6].
As it can be seen in Figs. 4 and 5, encryption of EtM and encryption of E&M have duality against decryption of E&M and decryption of EtM, respectively. The procedure of the incremental operations is basically the same as Step 1 to Step 4. When the impact to \(\varSigma \) from old C (for EtM) or old M (for E&M) is computed, EtM requires 2sblock computations while E&M requires only sblock computation. Thus, E&M has an advantage compared to EtM.
In summary, due to the duality, there is no choice with an overwhelming advantage. EtM and E&M should be chosen depending on which of encryption and decryption is the main target.
Favoring EncthenMAC. Given the above discussion, it seems reasonable to choose EtM for incremental encryption and E&M for incremental decryption. However, we argue that EtM can be also an attractive option for incremental decryption.
The reason is that one can use a “weak” (INDCPA) algorithm for the encryption part in EtM composition [9], whereas in E&M one needs relatively stronger encryption algorithm such as INDCCA. In particular, for blockwise encryption the XE construction, rather than XEX, is sufficient for building the encryption part if the scheme is based on the EtM composition. As a result, within the EtM paradigm one can construct a mode of operation that is efficient for both incremental encryption and decryption, as we shall show in the following section.
6.2 New Mode of Operation
In this section we present a new mode of operation for incremental AEAD. We first explain the method of mask generations. Consider the set \(\{0,1\}^n\) as the finite field of \(2^n\) elements with respect to some primitive polynomial f(x), so that the degree of f is n and the element x generates the whole multiplicative group. Let \(\varGamma _i\) denote the ith Gray code, for \(i\ge 1\). We define \(\gamma _i\leftarrow \varGamma _iL_0\), \(\varDelta _i\leftarrow \varGamma _iL_1\), \(\delta _i\leftarrow \varGamma _iL_2\) and \(\delta '\leftarrow L_3\) where \(L_j\leftarrow E_K\bigl (N\Vert (j)_2\bigr )\) for \(j=0,1,2,3\) with \((j)_2\) being a 2bit representation of integer j. Here \(E_K\) is the underlying nbit block cipher with a secret key K and \(N\in \{0,1\}^{n2}\) is a nonce. The choice of Gray code rather than doubling comes from the fact that we need to compute ith mask from scratch when one of the incremental operations is performed.
For simplicity we assume that \(T\in \{0,1\}^n\) and the lengths of A, M and C are always a multiple of n bits. In practice A and M might need to be padded, so that their lengths become a multiple of n bits. In principle this would not affect the feasibility of our construction, as in most of the cases the padding affect only the last block (as in the standard \(10^*\) padding), and the last block can be always handles by the update, append and chop operations.
6.3 Security of the New Mode
We prove the security of the incremental AEAD scheme specified above. We follow the adversarial model and the security notions defined in Sect. 3.
The first step is to replace the block cipher calls with the secret masks with independent random functions (not permutations). This is possible owing to the result of XE construction given by Rogaway. The result says that the block cipher calls can be considered as secure tweakable block ciphers, with tweak space (N, i). Moreover, the independence among the masks \(\gamma \), \(\varDelta \), \(\delta \) and \(\delta '\) are ensured. So now we replace these block cipher calls with independent random functions and prove the security of the mode under such assumptions.
Privacy. We start with privacy. We prove the following theorem.
Theorem 1
Proof
Since \({\varvec{A}}\) is assumed to be noncerespecting and not making a trivialwin query, all ciphertext blocks \(C_i\), whether output by the encryption oracle \(\mathcal {E}_K\) or output by the incremental operations, are truly random strings. So we only need to show that tag T should behave like a random string. There is an event that the value T is not an independent random string. Namely, whenever we have a collision of the input value \(\varSigma \) or \(\varSigma ^*\) to the taggeneration function \(\varphi _{\delta '}\), the output tag T does not become a freshly random string.
So let \(\mathsf {bad}\) be the event that the values \(\varSigma \) or \(\varSigma ^*\) collide. Since the scheme \((\varPi ,\varDelta )\) behaves like the ideal object as long as the event \(\mathsf {bad}\) does not occur, we have \({\text {Adv}}^\mathrm {priv}_{(\varPi ,\varDelta )}({\varvec{A}})\le \Pr \bigl [{\varvec{A}}\text { sets }\mathsf {bad}\bigr ]\).
For \(i=1,2,\ldots ,q\) let \(\mathsf {bad}_i\) denote the event that the event \(\mathsf {bad}\) occurs at the ith query for the first time; i.e. the event \(\mathsf {bad}\) has not occurred for the queries \(j=1,2,\ldots ,i1\) so far. Clearly \(\Pr \bigl [\mathsf {bad}\bigr ]\le \sum _{i=0}^q\Pr \bigl [\mathsf {bad}_i\bigr ]\).
We bound \(\Pr \bigl [\mathsf {bad}_i\bigr ]\). Suppose \(\mathsf {bad}\) has not occurred so far and now \({\varvec{A}}\) makes the ith query. Observe that by construction of the scheme, the computation of \(\varSigma \) or \(\varSigma ^*\) at the ith query always involves an invocation of a random function \(\varphi _\cdot \); therefore, we must have \(\Pr \bigl [\mathsf {bad}_i\bigr ]\le (i1)/2^n\). Hence the overall probability can be bounded as \(\Pr \bigl [\mathsf {bad}\bigr ]\le \sum _i^q(i1)/2^n\le q^2/2^{n+1}\). \(\square \)
Authenticity. We next prove authenticity. We prove the following theorem.
Theorem 2
Proof
Let \(\mathsf {bad}\) be the event as defined in the privacy proof, neglecting queries to the decryption oracle \(\mathcal {D}_K\). Namely, queries to the \(\mathcal {D}_K\) oracle has no effect on setting the event \(\mathsf {bad}\). Let \(\mathsf {forge}\) denote the event that \({\varvec{A}}\) forges. We have \({\text {Adv}}^\mathrm {auth}_{(\varPi ,\varDelta )}(A)=\Pr \bigl [\mathsf {forge}\bigr ]\le \Pr \bigl [\mathsf {forge}\bigm \lnot \mathsf {bad}\bigr ]+\bigl [\mathsf {bad}\bigr ]\). Similarly to the privacy proof, we can show that \(\Pr \bigl [\mathsf {bad}\bigr ]\le q^2/2^{n+1}\).
Now we bound \(\Pr \bigl [\mathsf {forge}\bigm \lnot \mathsf {bad}\bigr ]\). For this, we slightly change the game and consider a game where \({\varvec{A}}\) is allowed to make only a single query to its decryption oracle. Let \(\mathsf {forge}'\) be the event that \({\varvec{A}}\) forges in such a game. Then we have \(\Pr \bigl [\mathsf {forge}\bigm \lnot \mathsf {bad}\bigr ]\le q'\Pr \bigl [\mathsf {forge}'\bigm \lnot \mathsf {bad}\bigr ]\) where with abuse of notation each \(\mathsf {bad}\) denotes a bad event in the corresponding game.
So it remains to bound \(\Pr \bigl [\mathsf {forge}'\bigm \lnot \mathsf {bad}\bigr ]\). Let \((N^\circ ,A^\circ ,C^\circ ,T^\circ )\) denote the query to the decryption oracle.

Case\(N^\circ \)is new. In this case the computation of a tag from \((N^\circ ,A^\circ ,C^\circ )\) involves an invocation of a random function \(\varphi _\cdot \). Therefore, for any value \(T^\circ \), we must have \(\Pr \bigl [\mathsf {forge}'\bigm \lnot \mathsf {bad}\bigr ]\le 1/2^n\).

Case\(N^\circ \)is old but either\(A^\circ \)or\(C^\circ \)contains a new block relative to \(N^\circ \). Again, in this case the new block in \(A^\circ \) or \(C^\circ \) would cause an invocation of the random function \(\varphi \) to compute a tag value from \((N^\circ ,A^\circ ,C^\circ )\). Therefore, we have \(\Pr \bigl [\mathsf {forge}'\bigm \lnot \mathsf {bad}\bigr ]\le 1/2^n\).

Case\(N^\circ \)is old and all block of\(A^\circ \)and\(C^\circ \)are also old relative to\(N^\circ \). This is a tricky case. There is no new invocation of the functions \(\varphi \) when computing a tag value from \((N^\circ ,A^\circ ,C^\circ )\). Let \(\varSigma ^\circ \) denote the input value to the taggeneration function \(\varphi _\delta '\), computed from the triplet \((N^\circ ,A^\circ ,C^\circ )\). We emphasize that in computing \(\varSigma ^\circ \) there is no fresh invocation of random functions \(\varphi \). Let \(A^*\) and \(C^*\) denote the associated data and the ciphertext corresponding to the \(N^\circ \)query to the encryption oracle \(\mathcal {E}_K\). Since \(A^\circ \) and \(C^\circ \) must be chopped forms of \(A^*\) and \(C^*\), respectively, the number of possible values of \(\varSigma ^\circ \) are at most \(\ell _\mathrm {A}\cdot \ell _\mathrm {M}\).

Case\(\varSigma ^\circ \)is a new input to\(\varphi _\delta '\). We have \(\Pr \bigl [\mathsf {forge}'\bigm \lnot \mathsf {bad}\bigr ]\le 1/2^n\).

Case\(\varSigma ^\circ \)is an old input to\(\varphi _\delta '\) Since there are at most q possible values of \(\varSigma \) and \(\varSigma ^*\), under the event \(\lnot \mathsf {bad}\), the event \(\mathsf {forge}'\) implies the event that the value \(\varSigma ^\circ \) gets hit by one of these q values. Therefore, we must have \(\Pr \bigl [\mathsf {forge}'\bigm \lnot \mathsf {bad}\bigr ]\le \ell _\mathrm {A}\ell _\mathrm {M}q/2^n\).

7 Discussion
In this section, we would discuss several topics on incremental authenticated encryption with associated data.

Incremental AEAD loses its efficiency when the number of modified blocks is big. Suppose that there is a nonincremental AEAD scheme that requires only 1 blockcipher call per block (twice faster than our construction). When more than a half of the input blocks are modified, recalculating the result from scratch with such a fast nonincremental is better.

In many AEAD schemes especially for 1pass schemes, the ciphertext is computed block by block and sent to the receiver as soon as each block is computed. The receiver also starts to decrypt the received ciphertext block by block. To apply the incremental decryption, the ciphertext must be stored even after the decryption is finished. In practice, such a scenario will occur in storage encryption; storing the encrypted data is the main purpose.

Under the assumption that the computation results, (C, T) for encryption and M for decryption, are not disclosed, incrementality might be achieved with the AEAD schemes requiring a single use of nonce. Abed et al. [16] summarized the CAESAR candidates in this line.
Notes
Acknowledgments
We would like to thank anonymous reviewers and the attendees of Dagstuhl Seminar 14021 on Symmetric Cryptography in 2014 for their helpful comments. We are very grateful to Liting Zhang for pointing out an issue with the previous version of our scheme in the preproceedings and for suggesting a possible solution.
References
 1.Andreeva, E., Bogdanov, A., Luykx, A., Mennink, B., Mouha, N., Yasuda, K.: How to securely release unverified plaintext in authenticated encryption. IACR Cryptology ePrint Archive 144 (2014)Google Scholar
 2.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
 3.Andreeva, E., Bogdanov, A., Luykx, A., Mennink, B., Tischhauser, E., Yasuda, K.: AESCOPA v. 1. Submission to CAESAR (2014)Google Scholar
 4.Atighehchi, K.: Spaceefficient, bytewise incremental and perfectly private encryption schemes. Cryptology ePrint Archive, Report 2014/104 (2014). http://eprint.iacr.org/
 5.Atighehchi, K., Muntean, T.: Towards fully incremental cryptographic schemes. In: Chen, K., Xie, Q., Qiu, W., Li, N., Tzeng, W. (eds.) ASIA CCS 2013, pp. 505–510. ACM (2013)Google Scholar
 6.Bellare, M., Goldreich, O., Goldwasser, S.: Incremental cryptography: the case of hashing and signing. In: Desmedt, Y.G. (ed.) CRYPTO 1994. LNCS, vol. 839, pp. 216–233. Springer, Heidelberg (1994)Google Scholar
 7.Bellare, M., Goldreich, O., Goldwasser, S.: Incremental cryptography and application to virus protection. In: Leighton, F.T., Borodin, A. (eds.) STOC 1995, pp. 45–56. ACM (1995)Google Scholar
 8.Bellare, M., Micciancio, D.: A new paradigm for collisionfree hashing: incrementality at reduced cost. In: Fumy, W. (ed.) EUROCRYPT 1997. LNCS, vol. 1233, pp. 163–192. Springer, Heidelberg (1997)CrossRefGoogle Scholar
 9.Bellare, M., Namprempre, C.: Authenticated encryption: relations among notions and analysis of the generic composition paradigm. In: Okamoto, T. (ed.) ASIACRYPT 2000. LNCS, vol. 1976, pp. 531–545. Springer, Heidelberg (2000)CrossRefGoogle Scholar
 10.Bernstein, D.: CAESAR Competition (2013). http://competitions.cr.yp.to/caesar.html
 11.Bertoni, G., Daemen, J., Peeters, M., Van Assche, G.: Duplexing the sponge: singlepass authenticated encryption and other applications. In: Miri, A., Vaudenay, S. (eds.) SAC 2011. LNCS, vol. 7118, pp. 320–337. Springer, Heidelberg (2012)CrossRefGoogle Scholar
 12.Biryukov, A., Khovratovich, D.: PAEQ v1. Submission to CAESAR (2014)Google Scholar
 13.Black, J.A., Rogaway, P.: A blockcipher mode of operation for parallelizable message authentication. In: Knudsen, L.R. (ed.) EUROCRYPT 2002. LNCS, vol. 2332, pp. 384–397. Springer, Heidelberg (2002)CrossRefGoogle Scholar
 14.Bosselaers, A., Vercauteren, F.: YAES v1. Submission to CAESAR (2014)Google Scholar
 15.Buonanno, E., Katz, J., Yung, M.: Incremental unforgeable encryption. In: Matsui, M. (ed.) FSE 2001. LNCS, vol. 2355, p. 109. Springer, Heidelberg (2002)CrossRefGoogle Scholar
 16.Abed, F., Christian Forler, S.L.: General overview of the firstround CAESAR candidates for authenticated ecryption. Cryptology ePrint Archive, Report 2014/792 (2014)Google Scholar
 17.Gligoroski, D., Mihajloska, H., Samardjiska, S., Jacobsen, H., ElHadedy, M., Jensen, R.E.: \(\pi \)Cipher v1. Submission to CAESAR (2014)Google Scholar
 18.Gligoroski, D., Samardjiska, S.: iSHAKE: Incremental hashing with SHAKE128 and SHAKE256 for the zettabyte era. Presented at NIST SHA3 Workshop 2014 (2014). http://csrc.nist.gov/groups/ST/hash/sha3/Aug2014/
 19.Grosso, V., Leurent, G., Standaert, F.X., Varici, K., Durvaux, F., Gaspar, L., Kerckhof, S.: SCREAM & iSCREAM sidechannel resistant authenticated encryption with masking. Submission to CAESAR (2014)Google Scholar
 20.Harris, S.: The Enchilada authenticated ciphers, v1. Submission to CAESAR (2014)Google Scholar
 21.Hosseini, H., Khazaei, S.: CBA mode (v1). Submission to CAESAR (2014)Google Scholar
 22.Jean, J., Nikolić, I., Peyrin, T.: Deoxys v1. Submission to CAESAR (2014)Google Scholar
 23.Jean, J., Nikolić, I., Peyrin, T.: Joltik v1. Submission to CAESAR (2014)Google Scholar
 24.Jean, J., Nikolić, I., Peyrin, T.: KIASU v1. Submission to CAESAR (2014)Google Scholar
 25.Kavun, E.B., Lauridsen, M.M., Leander, G., Rechberger, C., Schwabe, P., Yalçın, T.: Prøst v1. Submission to CAESAR (2014)Google Scholar
 26.Krovetz, T., Rogaway, P.: The software performance of authenticatedencryption modes. In: Joux, A. (ed.) FSE 2011. LNCS, vol. 6733, pp. 306–327. Springer, Heidelberg (2011)CrossRefGoogle Scholar
 27.Krovetz, T., Rogaway, P.: OCB (v1). Submission to CAESAR (2014)Google Scholar
 28.McGrew, D.A., Viega, J.: The security and performance of the Galois/Counter Mode (GCM) of operation. In: Canteaut, A., Viswanathan, K. (eds.) INDOCRYPT 2004. LNCS, vol. 3348, pp. 343–355. Springer, Heidelberg (2004)CrossRefGoogle Scholar
 29.Minematsu, K.: AESOTR v1. Submission to CAESAR (2014)Google Scholar
 30.Montes, M., Penazzi, D.: AESCPFB v1. Submission to CAESAR (2014)Google Scholar
 31.Penazzi, D., Montes, M.: Silver V. 1. Submission to CAESAR (2014)Google Scholar
 32.Rogaway, P.: Authenticatedencryption with associateddata. In: Atluri, V. (ed.) ACM CCS 2002, pp. 98–107. ACM (2002)Google Scholar
 33.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
 34.Rogaway, P.: Noncebased symmetric encryption. In: Roy, B., Meier, W. (eds.) FSE 2004. LNCS, vol. 3017, pp. 348–359. Springer, Heidelberg (2004)CrossRefGoogle Scholar
 35.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.) ACM CCS 2001, pp. 196–205. ACM (2001)Google Scholar
 36.Sasaki, Y., Todo, Y., Aoki, K., Naito, Y., Sugawara, T., Murakami, Y., Matsui, M., Hirose, S.: Minalpher v1. Submission to CAESAR (2014)Google Scholar
 37.Zhang, L., Wu, W., Sui, H., Wang, P.: iFeed[aes] v1. Submission to CAESAR (2014)Google Scholar