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 nonce-based, 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.

The preliminary version was presented at Dagstuhl Seminar 14021 in 2014.

1 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 nonce-respect/nonce-repeat 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 side-channel 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 incremental-MACs (instantiated with randomized ECB and the XOR scheme in [7]) to achieve a provable security with respect to unforgeability. One of the proposed schemes, RPC-mode, provides insert and delete functionalities. As a side-effect, 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. byte-wise incremental encryption [4, 5] and incremental MAC with SHA-3 [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 nonce-repeating 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 nonce-repeating model. The COPA mode [2, 3] is parallelizable and nonce-misuse 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 nonce-based 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, non-incremental ones. In particular, for nonce-based schemes [34], one needs to carefully consider the problem of security under “nonce repetition.” Moreover, in nonce-based 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 Enc-then-MAC 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 Enc-then-MAC 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 Enc-then-MAC composition and “verify-then-decrypt” functionality [1]. This reduces the number of masks and the cost of an XOR operation per block.

Fig. 1.

Bad example: layered PMAC.

Fig. 2.

Good example: OCB3 $+$ PMAC.

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 n-bit 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 PMAC-like 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 nonce-based 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.

Nonce-Based. We follow the well-established nonce-based 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 nonce-based framework. We formalize the security notions under such circumstances.

No Randomization or Expansion. Since we follow the nonce-based framework, we do not allow $\varPi$ to be randomized. In general randomization would require the use of pseudo-random 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 nonce-based 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 nonce-based symmetric-key encryption and demand that ${\varvec{A}}$ should be nonce-respecting 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 nonce-respecting 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 nonce-respecting.

We do similarly for the incremental setting. Specifically, we consider random oracles having the same interfaces with the six incremental operations. In the ideal world adversary has access to this random oracle, which we write&=($,$,$,$,$,$) where each oracle is an independent random oracle having the corresponding interface. We define

where the probabilities are taken over the choice of key K and randomness used in the oracles and in the adversary ${\varvec{A}}$. This convention of probability definition apply to the rest of the paper. Here we demand that ${\varvec{A}}$ be nonce-respecting. Without loss of generality we also assume that ${\varvec{A}}$ never makes incremental queries that lead to a trivial win. These are incremental queries which ${\varvec{A}}$ can check the consistency conditions of the incremental oracles in the real world.

Authenticity. In the conventional AEAD the authenticity was defined in terms of unforgeability under chosen-message 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 non-trivial query (N, A, C, T) to its decryption oracle where the oracle would return something other than the reject symbol $\bot$.

This notion of authenticity is extended to our incremental setting in a straightforward way. We simply give ${\varvec{A}}$ additional access to the incremental oracles $\varDelta$ and consider a forgery event. That is, we define

$$ {\text {Adv}}^\mathrm {auth}_{\varPi ,\varDelta }({\varvec{A}}):=\Pr \bigl [{\varvec{A}}^{\mathcal {E}_K,\mathcal {D}_K,\varDelta }\text { forges}\bigr ], $$

where by “forges” we mean the event that $\mathcal {D}_K$ would return something other than $\bot$. We assume that ${\varvec{A}}$ is nonce-respecting and does not make a trivial-win query to its decryption oracle $\mathcal {D}_K$.

4 Design Requirements

Parallelizability. An obvious requirement to be incremental is the parallelizability for encryption, decryption and tag generation. Ideally, those computations should be block-wise, 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 up-to-prefix 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 nonce-repeating 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 check-sum of M as OCB is unsuitable for incremental AEAD.

No Tag Truncation. Truncating a state to generate tag is incompatible with incremental operations. Let us explain an example of incremental operation for PMAC, which computes a tag T for a message $M=M_1\Vert M_2\Vert \cdots \Vert M_n$ as follows.

$$\begin{aligned} \varSigma&\leftarrow 0,&\varSigma&\leftarrow \varSigma \oplus E_{K}(M_i \oplus L_i) {\text { for }} i=1,\ldots ,n-1,&T&\leftarrow E_{K}(\varSigma \oplus M_n \oplus L^{\prime }), \end{aligned}$$

where $L_i$ and $L^{\prime }$ are the masks. With the tag truncation, $\hat{T} \leftarrow trunc(T)$ is output as a tag, where trunc truncates the input value to the tag size. To incrementally update tag, the user first needs to recover $\varSigma$ by inverting the last block cipher call. If the tag truncation is applied, T cannot be recovered from $\hat{T}$ (no clue for the user to guess the discarded bits of T).

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).

No Ciphertext Translation. Another unsuitable example is the ciphertext translation proposed by [32] as a generic way to incorporate A in nonce-based AE schemes. It processes A by a universal hash function $f^A$, say $\text {OCB3}^{A}$, and generates the tag by XORing $f^A(A)$ and a part of C. Intuitively C is a random string as long as the nonce is respected, and it takes a role of hiding $f^A(A)$. It is also possible to generate the tag as $f^A(A) \oplus f^C(C)$ with a deterministic MAC $f^C$, say PMAC. Using a deterministic MAC for $f^C$ is crucial because incremental AEAD reuses the same nonce. Here the combination of universal hash $f^A$ and deterministic MAC $f^C$ spoils incremental AEAD. The construction with $\text {OCB3}^{A}$ for A and PMAC for $f^{C}$ is given in Fig. 3. In order to incrementally update C, the last block-cipher call in PMAC needs to be inverted. Without the knowledge of $\text {OCB3}^{A}(A)$, the user cannot recover the block-cipher’s output. Note that the same applies when $f^A$ is PMAC and $f^C$ is $\text {OCB3}^{A}$ (then A cannot be updated incrementally).

Fig. 3.

Ciphertext translation assuming $f^A$ is $\text {OCB3}^{A}$ and $f^C$ is PMAC.

Parallel Mask Generation. The mask for each block needs to be generated in parallel. Using serial pseudo-random 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 block-wise 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 nonce-repeating 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 stream-cipher, which breaks parallelizability.

• GCM [28] adopts the CTR mode. The reproduction of the same keystream in the nonce-repeating 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 {CBC-MAC}(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 layered-PMAC, i.e. $\mathrm {PMAC} ( \ \mathrm {PMAC(A)}\Vert C \ )$. The layered PMAC spoils incremental AEAD. The block-cipher is built with the double-block-length permutation with the Even-Mansour 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 nonce-repeating model.

• OTR [29] which is also used in Prøst-OTR [25] is similar to OCB except that encryption and decryption are processed in every 2 blocks with 2-round 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_{2i-1}$ are encrypted as

  $$\begin{aligned} C_{2i-1}&= E_K(2^{i-1}L \oplus M_{2i-1}) \oplus M_{2i}, \\ C_{2i}&= E_K(2^{i-1}L \oplus \delta \oplus C_{2i-1}) \oplus M_{2i-1}, \end{aligned}$$

  where L and $\delta$ are mask values. Then, incrementally updating $M_{2i}$ only simply affects to $C_{2i-1}$, which does not provide the ideal confidentiality.

• 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 nonce-repetition. 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 block-cipher (TBC) based design. The computation structure basically follows the one in OCB in a TBC level. Similarly to OCB, the integrity in the nonce-repeating model is the main drawback.

• YAES [14] processes A with a PMAC-like structure. The encryption is similar to the CTR mode. The PMAC-like structure is again used by taking intermediate value of each block as input. Finally, the results of two PMAC-like 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

In general, there are three approaches to construct authenticated encryptions: Enc-then-MAC (EtM), Enc-and-MAC, (E&M), and MAC-then-Enc (MtE). Here, we compare the cost of incremental operations with those three approaches.

Fig. 4.

Incremental encryption.

Fig. 5.

Incremental decryption. MtE is omitted.

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 5-tuple 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.

Several conditions are required to achieve incrementality. First, we suppose that the conversion from M to C (or C to M in decryption) is processed in block-wise, i.e. 1 block change in M only requires 1-block computation to obtain new $C^{\prime }$. For integrity, we need to avoid simple forgery attack in the nonce-repeating model. Let X be C in EtM and X be M in E&M. We assume that each block in A and X is processed by some computation, and moreover the sum of their computations is processed again. Namely, for a given $(A_1\Vert A_2\Vert \cdots \Vert A_n,X_1\Vert X_2\Vert \cdots \Vert X_l)$, T is computed as follows.

$$\begin{aligned} \varSigma \leftarrow 0,&\varSigma \leftarrow \varSigma \oplus \bigoplus _{i=1}^n F_K^i(A_i),&\varSigma \leftarrow \varSigma \oplus \bigoplus _{j=1}^l G_K^j(X_j),&T \leftarrow H_K(\varSigma ), \end{aligned}$$

(1)

where $F_K^i$ and $G_K^j$ are block-wise key-dependent computations and $H_K$ is an invertible key-dependent computation.

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.

• 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 1-block 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 s-block 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 2s-block computations. In Step 3, both approaches require between 2s- and s-block computations depending on how many blocks of A and M are modified. In 4, both approaches require 1-block 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 2s-block computations while E&M requires only s-block 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 Enc-then-MAC. 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” (IND-CPA) algorithm for the encryption part in EtM composition [9], whereas in E&M one needs relatively stronger encryption algorithm such as IND-CCA. In particular, for block-wise 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 i-th 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 2-bit representation of integer j. Here $E_K$ is the underlying n-bit block cipher with a secret key K and $N\in \{0,1\}^{n-2}$ is a nonce. The choice of Gray code rather than doubling comes from the fact that we need to compute i-th 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.

Now the new mode of operation iterates an n-bit block cipher $E_K$ and is based on XE construction given by Rogaway [33]. Its pseudo-code is given in Figs. 6 and 7. The encryption algorithm is also illustrated in Fig. 8.

Fig. 6.

Pseudo-code of the new mode of operation, the ordinary AEAD part.

Fig. 7.

Pseudo-code of the new mode of operation, the incremental operations.

Fig. 8.

An illustration of the encryption algorithm of the new mode of operation

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

Let $(\varPi ,\varDelta )$ be the incremental AEAD scheme specified above, with the underlying block cipher calls $E(\cdot \oplus \xi )$ replaced with independent random functions $\varphi _{\xi }$, where $\xi \in \{\gamma _i,\varDelta _i,\delta _i,\delta '\}$. Then for any adversary ${\varvec{A}}$ which makes at most q queries, we have

$$ {\text {Adv}}^\mathrm {priv}_{(\varPi ,\varDelta )}({\varvec{A}})\le \frac{q^2}{2^{n+1}}. $$

Proof

Since ${\varvec{A}}$ is assumed to be nonce-respecting and not making a trivial-win 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 tag-generation 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 i-th query for the first time; i.e. the event $\mathsf {bad}$ has not occurred for the queries $j=1,2,\ldots ,i-1$ 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 i-th query. Observe that by construction of the scheme, the computation of $\varSigma$ or $\varSigma ^*$ at the i-th query always involves an invocation of a random function $\varphi _\cdot$; therefore, we must have $\Pr \bigl [\mathsf {bad}_i\bigr ]\le (i-1)/2^n$. Hence the overall probability can be bounded as $\Pr \bigl [\mathsf {bad}\bigr ]\le \sum _i^q(i-1)/2^n\le q^2/2^{n+1}$.   $\square$

Authenticity. We next prove authenticity. We prove the following theorem.

Theorem 2

Let $(\varPi ,\varDelta )$ be the incremental AEAD scheme specified above, with the underlying block cipher calls $E(\cdot \oplus \xi )$ replaced with independent random functions $\varphi _{\xi }$, where $\beta \in \{\gamma _i,\varDelta _i,\delta _i,\delta '\}$. Then for any adversary ${\varvec{A}}$ which makes at most q queries to its encryption oracle and incremental oracles and at most $q'$ queries to its decryption oracle, the length of associated data being at most $\ell _\mathrm {A}$ blocks and the length of a message being at most $\ell _\mathrm {M}$ blocks, we have

$$ {\text {Adv}}^\mathrm {auth}_{(\varPi ,\varDelta )}({\varvec{A}})\le \frac{q^2}{2^{n+1}}+\frac{q'(\ell _\mathrm {A}\ell _\mathrm {M}q+3)}{2^n}. $$

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 tag-generation 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$.

Hence the overall probability becomes

$$ \Pr \bigl [\mathsf {forge}'\bigm |\lnot \mathsf {bad}\bigr ]\le \frac{1}{2^n}+\frac{1}{2^n}+\frac{1}{2^n}+\frac{\ell _\mathrm {A}\ell _\mathrm {M}q}{2^n}=\frac{\ell _\mathrm {A}\ell _\mathrm {M}q+3}{2^n}. $$

   $\square$

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 non-incremental AEAD scheme that requires only 1 block-cipher 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 non-incremental is better.

• In many AEAD schemes especially for 1-pass 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.

A Summary of Existing Schemes

Table 1 lists the unsuitable factors for incremental AEAD adopted in each design. Each column represents “block-wise encryption,” “block-wise decryption,” “integrity for nonce repeat,” “PRP for nonce repeat,” “tag-truncation free,” “ciphertext translation free,” “layered PMAC for processing A,” and “parallel generation of mask (or counter),” respectively. “$\checkmark$” represents that the scheme is suitable for incremental AEAD while “$-$” represents that the scheme is unsuitable.

Table 1. Survey of CAESAR candidates and GCM for incremental AEAD.

Parallelizability is a crucial requirement for incrementality. Without having parallelizability, the scheme cannot be incremental. However for other requirements, the scheme can be incremental with paying additional cost or with additional restrictions in applications even if they are not satisfied. If the incremental update is applied prior to the release of the encryption/decryption result to a public domain, security issues in the nonce-repeating model do not arise. Besides, security issues can be solved by combining other cryptographic techniques as long as they can be processed in block-wise. The problems with tag truncation, ciphertext translation and layered PMAC can be practically addressed by safely storing the internal state value, which is of a relatively small cost, e.g. only with additional one block information Also, the serial mask generation can also be avoided if masks are precomputed and stored offline.