A fundamental flaw in the ++AE authenticated encryption mode

1 Introduction

The ++AE proposal [8] was submitted to the Competition for Authenticated Encryption: Security, Applicability, and Robustness (CAESAR) [2] in 2014. This block cipher mode of operation is intended to provide authenticated encryption with associated data (AEAD). An Authenticated Encryption (AE) scheme is a symmetric-key encryption scheme that provides both data confidentiality and integrity assurance for messages [1]. In Authenticated Encryption with Associated Data (AEAD), some portions of the message (the associated data) do not require confidentiality but still require integrity assurance.

The ++AE cipher design is similar to AE schemes previously proposed by Recacha: IOBC [6] and IOC [7]. All of these designs use a block cipher in Electronic CodeBook (ECB) mode with cross block chaining and a detectable redundancy paradigm for the integrity check, rather than computing a message authentication code (MAC). An integrity check vector (ICV) that is known to both sender and receiver is appended to the plaintext message before encryption and encrypted along with the other plaintext. When the ciphertext is decrypted and the plaintext is recovered, the decryption of the final block is compared to the known ICV to check for possible alterations in the message during transmission. The method used for determining the value of the integrity check vector (ICV) in ++AE is different to that used for IOBC and IOC, although the verification process follows the same concept. If changes to the ciphertext occur, the block chaining mechanism is intended to propagate these errors during decryption so that the recovered ICV is different to the original ICV value, thus revealing the integrity breach.

The block chaining mechanisms used in IOBC and IOC have previously been shown to be flawed. Mitchell presented a known plaintext forgery attack on IOBC in [5] with complexity of 2b/3, where b is the underlying cipher block length. Bottinelli, Reyhanitabar and Vaudenay [3] presented a chosen plaintext forgery attack on IOC with a success rate of 1-3×2-b. The ++AE proposal uses a different block chaining mechanism, which involves repeated use of two types of addition: bitwise XOR and integer addition modulo the block size.

Previously, we identified a weakness in the integrity assurance mechanism of the ++AE mode [4]. We identified certain groups of four consecutive plaintext blocks that cause the internal values of the block cross chaining mechanism to repeat. We demonstrated the exploitation of that weakness in chosen plaintext forgery attacks that were guaranteed to pass the ++AE integrity test regardless of the encryption key, the block cipher used and the block length.

This article reveals a far more serious weakness in the integrity assurance mechanism of ++AE. This flaw is more severe than [4] because it applies to any plaintext message. We show that the integrity mechanism in ++AE does not verify the most significant bit of any plaintext block. Flipping the most significant bit in any plaintext block has no effect on the encryption of subsequent plaintext blocks. Consequently, no error propagates and the final MDC value is not affected.

This article is arranged as follows: Section 2 defines the notation used and briefly describes the ++AE scheme. Section 3 provides the mathematical proofs relating to the basic operations of ++AE. In Section 3 we prove a fundamental flaw in ++AE: that the most significant bit of each plaintext block does not affect the encryption of the integrity check vector. The last section draws a conclusion.

2 Description of ++AE

This section describes the ++AE block cipher mode of operation, based on Recacha’s two submissions [8] to the CAESAR competition: v1.0 in March 2014 and the revised version v1.1 in April 2014. The encryption and decryption procedures for ++AE are identical in both versions, and our analysis applies to both.

2.2 ++AE specification

Suppose that P=(P1,P2,…,PN) is an N-block plaintext message to be ++AE encrypted, using the symmetric key K and the public value S previously shared between sender and receiver. Note that S should be different for each message. To begin, two secret b-bit values, denoted IVa and IVb, are computed as follows:

IVa=eK⁢(S),IVb=eK⁢(IVa).

Integrity is assured by appending an integrity check vector ICV to the end of the plaintext message. The value of ICV is computed as follows:

ICV=(IVa⊕S)+(IVb⊕(N+M)).

The encrypted ICV block is referred to as a Modification Detection Code (MDC). ++AE uses pairs of internal chaining vectors, Qi and Ii. Changes in the ciphertext should propagate through the chaining vectors to the last block during decryption, resulting in an incorrect decryption of MDC to ICV. Only messages with the expected ICV are accepted as authentic. The ++AE encryption and decryption operations are described in Table 1 and illustrated in Figure 1.

Table 1

++AE encryption and decryption algorithms.

Algorithm 1: ++AE encryption	Algorithm 2: ++AE decryption
𝐄𝐧𝐜𝐫𝐲𝐩𝐭K⁢(S,P)	𝐃𝐞𝐜𝐫𝐲𝐩𝐭K(S,C∥MDC)
01. Q0←IVa	01. Q0←IVa
02. I0←IVb	02. I0←IVb
03. fori←1toNdo	03. fori←1toNdo
04.  Ii←Pi⊕Qi-1	04.  Xi←dK⁢(Ci)
05.  Qi←Ii+Ii-1+Qi-1	05.  Qi←Xi⊕Ii-1
06.  Xi←Qi⊕Ii-1	06.  Ii←Qi-(Ii-1+Qi-1)
07.  Ci←eK⁢(Xi)	07.  Pi←Ii⊕Qi-1
08. end for	08. end for
09. QN+1←(ICV⊕QN)+IN+QN	09. QN+1←dK⁢(MDC)⊕IN
10. MDC←eK⁢(QN+1⊕IN)	10. IN+1←QN+1-IN-QN
11. returnC∥MDC	11. ICV′←IN+1⊕QN
	12. ifICV′=ICVthen
	13.  returnP={P1,…,PN}
	14. else
	15.  return INVALID
	16. end if

Figure 1

++AE encryption and decryption operations.

3 Fundamental flaw in ++AE

This section explains how the chaining mechanism in ++AE results in a fundamental flaw in the integrity assurance mechanism. We provide the mathematical foundations before explaining the flaw.

From Theorem 3.2, complementing the most significant bit of a plaintext block Pj will complement the most significant bit of the internal values Ij, Qj and Xj. From Theorem 3.3, if the values for Ij and/or Qj are complemented, the encryption of the subsequent plaintext Pj+1 is not affected. Theorems 3.2 and 3.3 show that the MDC is unaffected by any change in the most significant bit of any plaintext block, except for the last block (PN+1=ICV). Consequently, the decryption of this MDC will give the correct ICV for the altered message. In other words, the integrity mechanism in ++AE does not verify the most significant bit of any plaintext block.

The purpose of the integrity assurance mechanism is to detect alterations to the received data either due to accidental or intentional modification. However, the integrity assurance mechanism in ++AE does not detect alterations to the most significant bit in any plaintext block. This is a fundamental flaw. This weakness allows a malicious sender or receiver to dispute the content of a validly sent message by claiming that the message is different in the most significant bit of any subset of the message blocks.

Based on this flaw, a straightforward chosen plaintext forgery attack would also be possible, except that the ++AE specification requires a different public value S to be used for each message encrypted. If nonce-reuse is possible, then plaintext forgeries are easily constructed.

4 Conclusion

In this article, we analysed the security of the ++AE authenticated encryption mode against forgery attacks and revealed a serious flaw in the integrity mechanism of ++AE: it does not verify the most significant bit of any plaintext block except the last block (PN+1=ICV). This is a fundamental flaw in the authentication mechanism, which could be maliciously exploited by either sender or receiver. Flaws in ++AE have been previously reported [4], but this is far more serious.

Note that this flaw is based on the properties of the cross chaining structure used in ++AE. It applies regardless of the choice of the underlying block cipher and independently of the chosen key or the message. This mode should not be considered suitable for authenticated encryption.