How to Securely Release Unverified Plaintext in Authenticated Encryption

Abstract

Abstract. Scenarios in which authenticated encryption schemes output decrypted plaintext before successful verification raise many security issues. These situations are sometimes unavoidable in practice, such as when devices have insufficient memory to store an entire plaintext, or when a decrypted plaintext needs early processing due to real-time requirements. We introduce the first formalization of the releasing unverified plaintext (RUP) setting. To achieve privacy, we propose using plaintext awareness (PA) along with IND-CPA. An authenticated encryption scheme is PA if it has a plaintext extractor, which tries to fool adversaries by mimicking the decryption oracle without the secret key. Releasing unverified plaintext then becomes harmless as it is infeasible to distinguish the decryption oracle from the plaintext extractor. We introduce two notions of plaintext awareness in the symmetric-key setting, PA1 and PA2, and show that they expose a new layer of security between IND-CPA and IND-CCA. To achieve integrity of ciphertexts, INT-CTXT in the RUP setting is required, which we refer to as INT-RUP. These new security notions are used to make a classification of symmetric-key schemes in the RUP setting. Furthermore, we re-analyze existing authenticated encryption schemes, and provide solutions to fix insecure schemes.

Authenticated Encryption in the Face of Protocol and Side Channel Leakage

“…We model this by explicitly defining security relative to a class of leakage functions (as is common for instance in the contexts for related-key or key-dependent message attacks). By appropriately setting the class of leakage functions, we show that our notion generalises previous strengthened AE security notions, including SAE, RUP and distinguishable decryption errors [2,4,13], and previous leakage notions, including the simulatable leakage, auxiliary input and probing models [17,26,56].…”

“…We establish that schemes susceptible to release of unverified plaintext are unsuitable even for much more modest types of leakage and we confirm modern folklore that this affects all schemes that are roughly of the type Encrypt-and-MAC or MAC-then-Encrypt (cf. [2]). Conversely, we show that Encrypt-then-MAC style schemes are secure against a large class of leakage functions, where we express this class in terms of the leakage classes against which the underlying primitives are secure.…”

“…Prior to the competition, Boldyreva et al [13] had investigated how to model a scheme from which decryption failures are not identical, such as under a timing attack. Andreeva et al [2] (RUP) considered the release of unverified plaintexts, where the decryption oracle releases candidate plaintexts even if they fail verification. The robust authenticated encryption notion of Hoang et al [25] also implies security against the leakage of these candidate plaintexts, among other goals.…”

“…The adversary A may make queries to these oracles, and eventually outputs a bit. Instead of writing the games in code, we adopt shorthand notation [2] so that the distinguishing advantage of A between two collections of n oracles (O 1 , . .…”

“…We are particularly interested in subtle authenticated encryption [4] which augments the authenticated encryption security game with an implementation-dependent leakage oracle that provides an adversary deterministic decryption leakage on invalid ciphertexts only. Subtle authenticated encryption encompasses earlier notions such as multiple decryption errors [13] and the release of unverified plaintexts [2]; it can be regarded as protocol leakage.…”