K ← K$ win← false Q← ∅ Finalize() return win Encrypt(H,M ) (C, T ) ← EK(H, M ) Q∪ {(H, C, T )} return (C, T ) Verify(H,C,T ) M ← DK(H, C, T ) if ((H, C, T ) /∈ Q) ∧ (M 6= ⊥) then win← true end if return M
as the success probability of winning a (cryptographic) game G. Each game consists
of three functions: An initialization function Initialize(), a finalization function Finalize(), and oracle functions. Any adversary A that is playing a game calls the Initialize() function first. In the following, A then makes some queries to the encrypt and decrypt oracles, and finally, A ends the game by invoking Finalize().
To A, every function of a game is a black box, i.e., it has no access to internal variables. An adversary wins the game if and only if Finalize() returns true. We denote Pr[AG⇒ 1] as the probability that the adversary wins the Game G.
An AE scheme Π = (K, E, D) protects the ciphertext integrity against an adversary A when it is not able to come up with a fresh authentic ciphertext tuple (H, C, T ), i.e., DK(H, C, T ) 6= ⊥, where (H, C, T ) is not the result of a previous query of A.
The INT-CTXT advantage based on the the Game GINT-CTXT (cf. Algorithm 2) is formally defined as follows:
Definition 4.3 (INT-CTXT Advantage). Let Π = (K, E, D) be an authenticated encryption scheme as introduced in Section 4.1, and let GINT-CTXT denote the game from Algorithm 2. Then, the INT-CTXT advantage of a nonce-respecting adversary A is defined as
AdvINT-CTXTΠ (A) = PrAGIN T −CT XT ⇒ 1,
and
AdvINT-CTXTΠ (q, ℓ, t) = max
A
AdvINT-CTXTΠ (A)
as the maximum advantage over all nonce-respecting INT-CTXT-adversaries that run in time at most t, ask a total maximum of q queries to the encryption and decryption oracles, and whose total query length is at most ℓ blocks.
4.3. Security Notions
Upper-Bounding the CCA3 Advantage. Bellare and Namprempre showed in [22] that an authenticated encryption scheme that is both IND-CPA- and INT-CTXT- secure, is also CCA3-secure. This notable observation is formalized as follows:
Theorem 4.4 (CCA3 Advantage [22]). Let Π = (K, E, D) be an authenticated encryption scheme as introduced in Section 4.1, and let A be a nonce-respecting CCA3Π adversary that runs in time t, and makes q queries with a total length of at
most ℓ blocks. Then, there exists an IND-CPAΠ-adversary Ap and an INT-CTXTΠ
adversary Ac such that
AdvCCA3Π (A) ≤ AdvIND-CPAΠ (Ap) + AdvINT-CTXTΠ (Ac),
where both Ap and Ac run in time O(t) and make at most q queries.
Proof Sketch. By applying the triangle inequality on Definition 4.1, we have AdvCCA3Π (A) = PrhK ← K : AEK(·,·),DK(·,·,·) ⇒ 1i− PrhA$(·,·),⊥(·,·,·)⇒ 1i ≤ PrhK ← K : AEK(·,·),DK(·,·,·) ⇒ 1i− PrhK ← K : AEK(·,·),⊥(·,·,·)⇒ 1i + PrhK ← K : AEK(·,·),⊥(·,·,·)⇒ 1i− PrhA$(·,·),⊥(·,·,·)⇒ 1i
For a key K ← K, we design two adversaries A$ p and Ac so that
PrhAEK(·,·),⊥(·,·,·) ⇒ 1i− PrhA$(·,·),⊥(·,·,·)⇒ 1i ≤ AdvIND-CPA
Π (Ap)
PrhAEK(·,·),DK(·,·,·)⇒ 1i− PrhAEK(·,·),⊥(·,·,·)⇒ 1i ≤ AdvINT-CTXT
Π (Ac).
Ap: Adversary Ap runs A and answers A’s queries to the function Encrypt and
Decrypt by using its own Encrypt oracle or returning ⊥, respectively. Ap outputs
whatever A outputs.
Ac: Adversary Ac runs A, and answers A’s queries to the function Encrypt by
using its own Encrypt oracle. It submits A’s queries to the Decrypt oracle to its own Verify oracle and, regardless of the response, returns ⊥. Note that the Verify oracle sets win to true if and only if a fresh Decrypt query of Ac is valid.
4.4. Game-Based Proofs
The majority of the upcoming proofs in this paper are based on common game-playing arguments. In this thesis, all games are written in a language similar to L that was introduced by Bellare and Rogaway in [28]. The basic concept of this proof technique is called game hopping. It is a formalized way to transform a cryptographic scheme into an ideal scheme, e.g., a random function by a series of minor modifications. We denote G0, . . . , Gn as a series of games, where G0 denotes the initial game and Gn
the final game. As usual, our adversary A has only black-box access to any Game Gi. Thus, the advantage of A to distinguish Game Gi from Game Gj is given by
AdvGj
Gi(A) =
PrAGi ⇒ 1− PrAGj ⇒ 1 .
Game-playing proofs become handy when it is hard to compute AdvGn
G0(A) in a
straightforward manner. The difference between subsequent games Gi and Gi+1 is,
by construction, easy to compute. Finally, from the common triangle inequality, we have AdvGi+2
Gi (A) ≤ Adv
Gi+1
Gi (A) + Adv
Gi+2
Gi+1(A), and thus,
AdvGn G0(A) ≤ n X i=1 AdvGi Gi−1(A).
5
Misusing Authenticated Encryption Schemes
You are never too old to set another goal or to dream a new dream.
C. S. Lewis
During the past decade, many AE schemes were proposed – usually with a formal proof of their respective CCA3 security. Up to now, CCA3 proofs used to rely on two common assumptions: (1) nonce-respecting adversaries, and (2) secure underlying primitives. While both aspects are well-understood in theory, they are hard to guar- antee in practice. Thus, security issues were overlooked or ignored in various cases and security applications were put at high risk. In this thesis we highlight two blind spots in the established security definitions: nonce misuse and decryption misuse.
5.1. Nonce Misuse
The standard requirement for encryption schemes – authenticated or not – is to prevent leakage of any information about the plaintext except for its length. A stateless deterministic authenticated encryption scheme cannot fulfill this security requirement since an adversary can easily detect, if a plaintext was encrypted multiple times or not. Thus, the user must provide a fresh additional auxiliary input (called nonce) for each encryption. We speak of a nonce misuse, if a nonce value is reused.
In theory, the concept of nonces is simple. In practice, it is challenging to ensure that nonces never repeat. Flawed implementations of nonces are ubiquitous [51, 122, 146, 214, 239], but, apart from implementation failures, cases exist where software
developers cannot always prevent nonce reuse. For example, a persistently stored counter that is increased and written back each time a new nonce is needed may be reset by a backup – usually after some previous data loss. Similarly, the internal and persistent state of an application may be duplicated when a virtual machine is cloned, etc.
Our analysis in Section 6.1 shows that almost all previously published OAE schemes cannot longer ensure the privacy, integrity, or both for encrypted messages when threatened by a nonce-ignoring adversary.
Ideally, an adversary that is given the encryption of two (equal-length) plaintexts M1 and M2cannot even decide if M1 = M2or not. When a nonce is used more than once, deciding if M1 = M2 becomes easy. Deterministic encryption schemes, such as SIV [209], ensure that they do not leak any other additional information about plaintexts, even when exposed to a nonce-reusing adversary. In the case of on-line encryption, where the i-th ciphertext block is independend of all message blocks Mj
with j > i, it is unavoidably to leak information beyond M1 = M2. The adversary
can compare any pair of ciphertexts for their Longest Common Prefix (LCP), and then derive the longest common prefix of their corresponding plaintexts. We propose to call an (on-line) AE scheme misuse resistant if the only information an adversary can obtain from ciphertexts are their lengths, and the LCP of its plaintexts. In the following we first formally define the length of the LCP.
Definition 5.1 (Length of the Longest Common Prefix (LLCP)). Let M, M′ ∈ ({0, 1}n)∗ denote two messages. Then, we define the length of the longest
common n-prefix of M and M′ as LLCPn(M, M′) = max i M1 = M1′, . . . , Mi = Mi′ . For a non-empty set Q of elements of ({0, 1}n)∗, we define
LLCPn(M, Q) = max
X∈Q{LLCPn(M, X)} .
On-line Permutation (OPerm). We aim for larger permutations that not only per- mute single blocks but can handle messages of multiple blocks. Such a permutation,
5.1. Nonce Misuse
Algorithm 3 Random On-Line Permutation Implemented via Lazy Sampling