Fully Deniable Interactive Encryption: Ran Canetti Sunoo Park Oxana Poburinnaya July 25, 2020

Fully Deniable Interactive Encryption
Ran Canetti∗ Sunoo Park† Oxana Poburinnaya‡
July 25, 2020
Abstract
Deniable encryption (Canetti et al., Crypto 1996) enhances secret communication over public channels,
providing the additional guarantee that the secrecy of communication is protected even if the parties are
later coerced (or willingly bribed) to expose their entire internal states: plaintexts, keys and randomness.
To date, constructions of deniable encryption — and more generally, interactive deniable communication
— only address restricted cases where only one party is compromised (Sahai and Waters, STOC 2014).
The main question — whether deniable communication is at all possible if both parties are coerced at
once — has remained open.
We resolve this question in the affirmative, presenting a communication protocol that is fully deniable
under coercion of both parties. Our scheme has three rounds, assumes subexponentially secure indistin-
guishability obfuscation and one-way functions, and uses a short global reference string that is generated
once at system set-up and suffices for an unbounded number of encryptions and decryptions.
Of independent interest, we introduce a new notion called off-the-record deniability, which protects
parties even when their claimed internal states are inconsistent (a case not covered by prior definitions).
Our scheme satisfies both standard deniability and off-the-record deniability.
∗
Boston University and Tel Aviv University. Email: canetti@bu.edu
†
MIT and Harvard. Email: sunoo@csail.mit.edu
‡
Boston University. Email: oxanapob@bu.edu
1
Contents
1 Introduction 1
1.1 Our Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Fully Deniable Interactive Encryption: Definition in a Nutshell . . . . . . . . . . . . . . . . 3
1.3 A Very Brief Overview of the Construction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Directions for Future Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Variants of Deniable Encryption and Other Related Concepts . . . . . . . . . . . . . . . . . 8
1.6 Prior Work on Deniable Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7 Organization, and How to Read This Paper . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Towards the Scheme: Technical Overview 11

2.1 A First Attempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Levels, Comparison-Based Decryption, and the Final Scheme . . . . . . . . . . . . . . . . . 16
2.3 Outline of security proof in oracle-access model. . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Changes to the construction due to iO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Defining Bideniable and Off-the-Record Deniable Encryption 22

3.1 Deniability in the CRS Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Deniability in The Oracle Access Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Deniable Encryption in Oracle-Access model 26

4.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Proof of correctness and security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5 Preliminaries: IO, DIO, and ACE 42

5.1 Indistinguishability Obfuscation for Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Equivalence of iO and diO for programs differing on one point . . . . . . . . . . . . . . . . 42
5.3 Puncturable Pseudorandom Functions and their variants . . . . . . . . . . . . . . . . . . . . 49
5.4 Asymmetrically constrained encryption (ACE) and its relaxed variant . . . . . . . . . . . . 50
6 Construction of interactive deniable encryption 54

6.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2 Building blocks and main theorem stating security . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.1 Level system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.2 Primitives required for the main construction, and their parameters . . . . . . . . . . 59
6.2.3 Main theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.3 Proof overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7 Level System 67
7.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.2 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.3 Overview of the proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.4 List of hybrids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.4.1 Proof of lemma 2 (Switching from `∗0 to `∗1 ). . . . . . . . . . . . . . . . . . . . . . . 80
7.4.2 Proof of lemma 3 (Changing the upper bound from T + 1 to T ). . . . . . . . . . . . 102
7.4.3 Proof of lemma 4 (Restoring behavior of Transform). . . . . . . . . . . . . . . . . . 119
2
7.5 Security reductions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
7.5.1 Reductions in the proof of lemma 2 (Switching from `∗0 to `∗1 ) . . . . . . . . . . . . 164
7.5.2 Reductions in the proof of lemma 3 (Changing the upper bound from T + 1 to T ) . . 167
7.5.3 Reductions in the proof of lemma 4 (Restoring behavior of Transform) . . . . . . . 169
8 Proof of bideniability of our encryption protocol 177

8.1 List of hybrids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
8.1.1 Proof of lemma 54 (Indistinguishability of explanation of the sender) . . . . . . . . 177
8.1.2 Proof of lemma 55 (Indistinguishability of explanation of the receiver) . . . . . . . . 181
8.1.3 Proof of lemma 56 (Semantic security) . . . . . . . . . . . . . . . . . . . . . . . . 193
8.1.4 Proof of lemma 57 (Indistinguishability of levels) . . . . . . . . . . . . . . . . . . . 205
8.2 Detailed proof of security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
8.2.1 Reductions in the proof of lemma 54 (Indistinguishability of explanation of the sender)221
8.2.2 Reductions in the proof of lemma 55 (Indistinguishability of explanation of the receiver)225
8.2.3 Reductions in the proof of lemma 56 (Semantic Security) . . . . . . . . . . . . . . . 234
8.2.4 Reductions in the proof of lemma 57 (Indistinguishability of Levels) . . . . . . . . . 240
9 Proof of off-the-record deniability of our encryption protocol 247
A On Flexible Deniability: Discussion 259
B On removing layers of obfuscation 261
C Construction of relaxed ACE 262
D Encrypting longer plaintexts 269
3
1 Introduction
The ability to communicate secret information without having any prior shared secrets is a central pillar of
modern cryptography [DH76, RSA78, GM84]. However, standard definitions and existing algorithms for
secure communication only guarantee security if the parties’ local randomness remains hidden. If the parties’
secret keys or randomness are exposed, say as a result of coercion or bribery, secrecy is no longer guaranteed.
Moreover, the transcript in common encryption and key exchange schemes often “commits” the sender to the
plaintext, in that each transcript is consistent with only one plaintext and randomness.
To address this issue, Canetti, Dwork, Naor and Ostrovsky [CDNO96] introduced the notion of deniable
encryption, which provides a mechanism for preserving the secrecy of communicated plaintexts even in
the face of post-communication coercion or bribery.1 Specifically, deniable encryption (or, more generally,
deniable interactive communication) introduces additional algorithms, called faking algorithms, that are not
present in standard secure communication definitions. The faking algorithms allow the communicating parties
to present fake internal states (including keys and randomness) that make any communication transcript
appear consistent with any plaintext of the parties’ choice. Concretely, an adversary should not be able to tell
whether the sender and the receiver gave it the true keys, randomness, and plaintext, or fake ones.
When the communicating parties have a secret key that was shared ahead of time, deniable encryption can
be simple. The classic one-time-pad scheme is perfectly deniable: having sent c = k ⊕ m, the parties can
claim that they sent any plaintext m0 by claiming that k 0 = c ⊕ m0 is their true key. However, shared-key
deniable schemes fail to address the crucial question of how to deniably agree on a shared key in the first
place. Indeed, existing key exchange protocols are “committing” in a way that precludes deniability. For
instance, in Diffie-Hellman key exchange, there exists only one key consistent with any given transcript, so
it is impossible to equivocate a one-time pad key generated using Diffie-Hellman key exchange. Thus, the
core question here is how to deniably transmit a value (or equivalently, to establish a shared key) without any
pre-shared secrets.
This setting turns out to be much more challenging. Even the restricted case where only the sender is coerced
(or bribed) was fully resolved only much later, assuming indistinguishability obfuscation, in the breakthrough
work of Sahai and Waters [SW14].2 The case where only the receiver is coerced or bribed follows from
the sender-only case via a general transformation, at the cost of an additional message [CDNO96]; hence,
the [SW14] scheme implies a 3-round receiver-deniable protocol. This transformation can also be extended
to handle the case where the adversary may coerce either party, but only one of the two. Furthermore, as
demonstrated by Bendlin, Nielsen, Nordholt, and Orlandi [BNNO11], any receiver-deniable encryption
protocol must take at least three rounds of communication.
Constructing bideniable encryption protocols, namely encryption protocols that guarantee deniability in
the unrestricted case where both the sender and the receiver can be simultaneously coerced or bribed, has
remained open:
Do there exist bideniable encryption protocols, with any number of rounds?
Bideniability is a significantly stronger property than any of the restricted variants above, where the adversary
1
While our results address both bribery and coercion, bribery might be the better setting to keep in mind. Indeed, protecting
against bribery is more challenging in that the parties are incentivized to disclose all internal state, including all random choices.
2
Prior to [SW14], we only had the partial solution of [CDNO96], where the adversary’s distinguishing advantage decreases linearly
with ciphertext size; in particular, to get indistinguishability with negligibly small advantage, one has to send superpolynomially long
ciphertexts.
1
only learns the internal state of either the sender or the receiver.3 Indeed, when both parties are coerced, the
adversary obtains a complete transcript of an execution, including all the random choices, inputs and outputs
of both parties. This means that the adversary can now fully run this execution, step by step, and compare it
against the recorded communication. Even so, as long as the sender and receiver follow the protocol during
the actual exchange of messages, bideniability guarantees that any (real or fake) internal state provided by the
parties looks just as plausible as any other (real or fake) one.
Off-the-record deniability. When the attacker bribes or coerces both parties, a new concern emerges: what
happens if the plaintext claimed by the sender is different from that claimed by the receiver? This could arise
in various scenarios: the parties might simply not have the chance to coordinate a story in advance (e.g.,
if they are separated and interrogated); or the parties might be incentivized to tell different stories (e.g., to
protect themselves or those close to them); or the parties might find themselves incentivized to “defect” on
each other as in a prisoner’s dilemma. Still, standard bideniability (as defined by [CDNO96]) provides no
guarantees for these cases.
1.1 Our Contributions

Our first contribution is defining a security guarantee, called off-the-record deniability, that holds even
in the above setting, where the coerced (or bribed) parties’ responses are inconsistent with each other.4
Off-the-record deniability achieves protection akin to an ideal, physically protected communication channel
where the communication leaves no trace behind. That is, off-the-record deniability guarantees that the
communication transcript does not help the attacker to determine which of the two parties is telling the truth,
if any. This holds even if the parties deviate from the protocol — as long as the deviation happens after the
actual protocol execution completes. In other words, off-the-record deniability guarantees protection for each
party independently of the other party’s actions. This contrasts with standard bideniability where, for the
security guarantee to hold, both parties must lie, and their claims must be consistent.
Our second and main contribution is the first encryption protocol that is both bideniable and off-the-record
deniable. We call such protocols fully deniable. A fully deniable protocol provides protection akin to an ideal
channel, in that after message transmission, each party can claim that the message was any value whatsoever
(say, from a pre-specified domain) and the attacker has no way to tell which party, if any, is telling the truth.
We stress that, prior to this work, even the existence of bideniable encryption (without the additional
off-the-record property) was an open question.
Theorem 1. Assuming subexponentially secure indistinguishability obfuscation and subexponentially secure

one-way functions, there exists a 3-message interactive bit encryption scheme that is fully deniable (i.e., both
bideniable and off-the-record-deniable) in the common reference string model. In addition, the receiver’s
deniability is public (i.e., the true random coins of the receiver are not required to compute fake randomness
of the receiver).
Our common reference string (CRS) consists of six obfuscated programs: three for the sender (programs P1
and P3 for generating the first and third messages, respectively, and the sender faking program SFake) and
three for the receiver (programs P2 for generating the second message, the decryption program Dec, and the
3
We note that a related but different concept, multi-distributional bideniability, has previously been considered in a setting where
both parties are attacked [OPW11]; see Appendix A.
4
The off-the-record messaging protocol [BGB04] is a messaging protocol that shares our motivation of enabling encrypted
communications as close as possible to an ideal private channel, but is otherwise unrelated to our off-the-record deniability notion.
2
Type of deniability Secure against adversaries that may...
I. Sender-deniable coerce S but not R
II. Receiver-deniable coerce R but not S
III. Sender-or-receiver deniable coerce either S or R but not both
IV. Bideniable coerce both S and R, who claim the same plaintext
V. Off-the-record deniable coerce both S and R, who claim two different plaintexts
Table 1: Taxonomy of deniable encryption. In each case, the adversary sees a communication transcript
between sender S and receiver R. “Coercion” means the adversary may demand from a party an explanation
(internal state) consistent with a plaintext m of the adversary’s choice. Note: I∧II⇔III and IV∨V⇒I∧II∧III.
receiver faking program RFake). The scheme instructs the parties to run the obfuscated programs on their
relevant inputs and uniformly chosen random inputs.
Designing the scheme requires addressing two main classes of challenges. First, the operation of the six
programs should follow a certain “internal logic” — which ends up being necessary even in an idealized
model where parties only have oracle access to the encryption scheme programs. We make this logic explicit
by constructing and proving security of a fully deniable encryption scheme in this idealized model. While this
construction is not used directly in the full-fledged scheme, it highlights key design difficulties. Interestingly,
while many cryptographic primitives are trivial to construct in this idealized model, deniable encryption
is still highly non-trivial; indeed, our technical overview (section 2) is fully devoted to building deniable
encryption in the idealized model.
The next challenge lies in translating this idealized protocol to one that is provably secure when the programs
are (a) actual programs and (b) protected only by indistinguishability obfuscation (IO), not ideal obfuscation.
Here, we use the sophisticated tools developed in [KLW15, CHJV14, BPR15, BPW16] that were developed
for dealing with obfuscated programs that are designed to be repeatedly run on inputs that were generated
earlier by the program itself. Our situation is however significantly more complex: We have several programs
that are designed to take inputs from each other with a specific and context-dependent set of constraints. We
thus develop additional tools and abstractions that allow us to deal with this more complicated setting.
We now turn to discussing our definitions and constructions in more detail.
1.2 Fully Deniable Interactive Encryption: Definition in a Nutshell

Deniable interactive encryption is equipped with algorithms to generate protocol messages, to decrypt, and to
generate fake randomness. We present the definition for the three-message case, since our protocol has three
messages. A scheme consists of six programs P1, P2, P3, Dec, SFake, RFake as follows.
• Program P1, run by the sender, takes as input a message m and sender random string s, and outputs a
first message µ1 .
• Program P2, run by the receiver, takes as input a message µ1 and receiver random string r, and outputs
second message µ2 .
• Program P3, run by the sender, takes as input s, m, µ1 , µ2 and outputs a third message µ3 .
• Program Dec, run by the receiver, takes as input r, µ1 , µ2 , µ3 and outputs plaintext m̃.
• Program SFake takes as input the public transcript of the protocol (namely messages µ1 , µ2 , µ3 ), the
3
sender randomness s, the message m, a fake message m0 , and potentially some additional random input
ρS , and outputs a fake random string sm0 that is intended to explain the transcript as an encryption of
m0 .
• Program RFake takes as input the public transcript, the receiver randomness r, the message m, a fake
message m0 , and potentially some additional random input ρR , and outputs a fake random string rm0
that is intended to explain the transcript as decrypting to m0 .
We define correctness in the natural way: if the sender runs P1, P3 with plaintext m and uniformly chosen
s, and the receiver runs P2, Dec with uniformly chosen r, the receiver must decrypt m̃ = m except with
negligible probability.
Bideniability requires that no PPT adversary can distinguish the following two distributions: (1) a protocol
transcript for plaintext m0 , and both parties’ true random coins for that transcript; and (2) a protocol transcript
for plaintext m and fake random coins which make that transcript decrypt to m0 . That is,
(tr(s, r, m0 ), s, r) ≈c (tr(s, r, m), sm0 , rm0 ) , (1)
where s, r are uniformly random, tr(s, r, m) is the transcript from running the protocol to transmit m
with random inputs s for the sender and r for the receiver, sm0 = SFake(s, m, m0 , tr(s, r, m); ρS ), rm0 =
RFake(r, m, m0 , tr(s, r, m); ρR ), and ≈c denotes computational indistinguishability.
Off-the-record deniability requires that no PPT adversary can distinguish between the following three
cases:
• The sender tells the truth and the receiver lies. That is, the adversary sees a transcript for plaintext
m, the sender’s true random coins, and fake random coins from the receiver consistent with m0 .
• The sender lies and the receiver tells the truth. That is, the adversary sees a transcript for plaintext
m0 , fake random coins from the sender consistent with m, and the receiver’s true random coins.
• Both the sender and the receiver lie. That is, the adversary sees a transcript for plaintext m00 , fake
random coins from the sender consistent with m, and fake random coins from the receiver consistent
with m0 .
That is,
(tr(s, r, m), s, rm0 ) ≈c (tr(s, r, m0 ), sm , r) ≈c (tr(s, r, m00 ), sm , rm0 ) , (2)
where s, r, tr are defined as in (1), and sm , rm0 are fake coins produced by running faking algorithms on the
corresponding transcript.
Observe that bideniability implies that tr(s, r, m) ≈c tr(s, r, m0 ), so a bideniable scheme is also semantically
secure. Similarly, off-the-record deniable schemes are also semantically secure.
Full deniability. A scheme is fully deniable if it is both bideniable and off-the-record deniable. Full
deniability provides protection akin to an ideal secure channel in that the parties can freely claim any plaintext
was sent or received, and which guarantees protection even when parties’ claims do not match.
1.3 A Very Brief Overview of the Construction

Our starting point is an elegant technique from [SW14] that transforms any randomized algorithm A (with
domain X and range Y ) into a “deniable version” using IO. The technique creates two obfuscated programs
A0 and F , where: A0 is the “deniable version” of A; and F is a “faking algorithm” that, for any input
4
(x, y) ∈ X × Y , outputs randomness ρ such that A0 (x; ρ) = y. Using this technique, for any protocol, we can
equip parties with a way to “explain” any given protocol message sent: that is, to produce fake randomness
which makes that protocol message consistent with any plaintext of the parties’ choice.
Based on this, a first attempt at a bideniable scheme might be to apply the [SW14] technique to an arbitrary
public-key encryption scheme to create obfuscated programs for encryption, decryption, sender-fake and
receiver-fake — and then use the sender-fake and receiver-fake programs to “explain” the protocol messages
one by one. However, this does not yield a bideniable encryption scheme: the [SW14] technique is guaranteed
to work only when applied to independent algorithm executions, but here the algorithms are run on the same
keys and randomness, protocol messages are interrelated, and any convincing overall explanation must consist
of a sequence of consistent explanations across the algorithms.5 The problem in a nutshell is that although the
[SW14] technique could create a deniable version of any single program, applying the technique separately
to the key generation, encryption, and decryption programs fails to achieve deniability with respect to the
programs’ joint behavior.
More concretely, it is problematic that the adversary can manipulate any given transcript and randomness
to generate certain “related” transcripts and randomness, and then try running the decryption algorithm on
different combinations of them. Next, we give some intuition as to why this is a problem.
The Accumulating Attack. A fake r (i.e., receiver randomness) can be viewed as a string which “encodes”
or “remembers”, explicitly or implicitly, an instruction to decrypt a certain transcript to a certain fake plaintext.
An adversary can run RFake iteratively on a given r (and a series of related transcripts) to successively obtain
r1 , r2 , . . . , hoping that each new application of RFake will add a new (ith) instruction into the “memory”
of ri in addition to all the preceding instructions. Since ri is a bounded-length string which, information-
theoretically, can carry only a fixed amount of information, sooner or later, one of the instructions will be
lost from the “memory” of ri∗ for some i∗ . It can be shown that, assuming r was fake, an adversary running
RFake many times can obtain some ri which does not carry the original r’s instruction, and thus decrypts the
original transcript honestly. (This attack first appeared in [BNNO11] in the two-message setting and was
used to demonstrate impossibility of two-message receiver-deniable encryption.)
While the above attack does not carry over to the three-message case generically, it stills remains valid
for many protocols: namely, for those protocols where it is easy, given the challenge transcript tr∗ , to find
transcripts “related” to tr∗ . Here “related” means that these transcripts can be successfully decrypted using
the same true randomness r that was used to generate tr∗ . (In particular, in the two-message case, it is always
easy to generate related transcripts (pk, c) by setting pk = pk ∗ and setting c to be a fresh ciphertext with
respect to pk.)
Therefore our approach, based on the above ideas, involves: (1) designing a protocol that prevents the
adversary from computing related transcripts that force receiver randomness to “accumulate” information as
described above, and then (2) applying the [SW14] technique to the algorithms for generating each message
of this protocol. For the first step, we design such a protocol in the oracle-access model, where everyone
(parties and adversaries) has only oracle access to the programs for computing protocol messages. Then, we
adapt the construction to the setting where everyone has access to program code, obfuscated under IO.
Step 1 of our plan — designing a protocol resistant to the Accumulating Attack — itself consists of two key
steps, further detailed below: (1a) design a “Base Protocol” that resists only some attacks, then (1b) augment
the base protocol using the ideas of a level system and comparison-based decryption, to obtain a protocol
5
Indeed, if this approach worked, it would yield two-message bideniable encryption, which is impossible [BNNO11].
5
secure in the oracle-access model (the “Idealized Protocol”).
+ [SW14] technique
S TEP 1 A + Level system (§7) S TEP 1 B + Level system S TEP 2
Base Protocol + Comparison-based Idealized Protocol construction Full Protocol (§6)
Prevents some attacks decryption (§2) Fully deniable in from iO (§7.2) Fully deniable under
but ultimately insecure oracle-access model subexp. iO & OWF
Figure 1: The construction, step by step. The second arrow is dashed because while conceptually the
Idealized Protocol is a stepping-stone to the Full Protocol, technically the Full Protocol requires very different
techniques, and must be proven from scratch rather than “building on” the Idealized Protocol.
S TEP 1 A : We design the Base Protocol in the oracle-access model as follows. The first message µ1 is a PRF
output for input (s, m) where s is the sender randomness s and m is the plaintext. The second message µ2 is
a PRF output for input (r, µ1 ) where r is the receiver randomness r. The third message µ3 is an encryption of
(m, µ1 , µ2 ). All keys for PRFs and encryption are hidden inside these programs (and not known to anyone,
including parties). After exchanging µ1 , µ2 , µ3 with the sender, the receiver runs Dec, which decrypts the
ciphertext µ3 and outputs m. In addition, the programs contain certain consistency checks: Dec returns an
output only if it gets the correct r (i.e., consistent with µ2 ), and P3 only returns an output if it gets the correct
s (i.e., consistent with µ1 ).
The intuition for this design is as follows. The first two messages serve as “hashes” of the parties’ internal
state so far, and the next two programs — P3 and Dec — produce output only if the parties “prove” to the
programs (by giving randomness consistent with these “hashes”) that they are continuing to execute the
protocol on the same inputs used to generate these hashes. This design aims to prevent the adversary from
computing related transcripts (and thus prevent the Accumulating Attack): for instance, an adversary must
not be able to reuse µ1 , µ2 from a transcript (µ1 , µ2 , µ3 ) to compute a new µ3 0 such that (µ1 , µ2 , µ3 0 ) is also
a valid transcript with respect to the same r. Section 2 gives more intuition about this.
S TEP 1 B : Unfortunately, the intuition from Step 1a is only partially correct: it turns out that it is still
possible to generate related transcripts, although the design above indeed protects against “most” ways of
generating them. Concretely, we describe a method Ω (detailed in Section 2.1) to compute a series of related
transcripts differing only in the third message. Importantly, Ω is generic: it works for any three-message
bideniable encryption scheme. Ω takes any transcript (µ1 , µ2 , µ3 ) and, applied iteratively, produces a “chain”
of valid transcripts tr1 = (µ1 , µ2 , µ3 (1) ), tr2 = (µ1 , µ2 , µ3 (2) ), and so on. However, the scheme from Step
1a importantly ensures that Ω is the only way to compute valid related transcripts: this is crucial for the
security proof.
It remains to ensure that the adversary cannot learn the true plaintext from the chain of related transcripts
produced using Ω (e.g., by performing the Accumulating Attack). To do this, we augment the Base Protocol
with a level system, under which each µ3 (i) , generated using Ω, encodes a number which we call a level,
which is set to that transcript’s own index i.6 Concretely, µ3 (i) is an encryption of (m, µ1 , µ2 , i). Additionally,
any fake randomness ri — generated by running RFake on (µ1 , µ2 , µ3 (i) ) — also encodes the level i of the
transcript used to generate this ri . The level i is encrypted, and so hidden from parties and the adversary, but
the programs can decrypt and learn i using their internal keys. To complete the Idealized Protocol, we modify
the decryption algorithm such that any fake ri associated with level i may be used to decrypt transcripts with
µ3 (j) where j > i (“correctness forward”), but decryption will fail (i.e., output ⊥) if attempted with respect
6
Since Ω is inherently applied sequentially, the index i of each transcript produced by Ω is well defined.
6
to ri and µ3 (j) where j < i (“oblivious past”). We call this comparison-based decryption behavior.
Ω Ω ... Ω Ω Ω Ω Ω ...
tr tr1 tri−1 tri tri+1 tri+2
Oblivious past: RFake Correctness forward:
decrypting with ri fails ri decrypting with ri succeeds
Figure 2: Comparison-based decryption behavior
The Idealized Protocol, just described, is fully deniable in the oracle-access model. In particular, it prevents
the Accumulating Attack: intuitively, this is because comparison-based decryption ensures that an iteratively
faked r only encodes the most recent faked plaintext, rather than accumulating a sequence of past fake
plaintexts.
S TEP 2: We obtain the Full Protocol by applying the [SW14] technique to the Idealized Protocol, which
enables the parties to use obfuscated programs (not oracle access) to compute protocol messages and to
generate fake randomness. Proving security of the resulting protocol based on IO presents a number of
challenges. To start with, the security argument in the oracle-access model relies heavily on certain outputs
of programs being hard to find provided the corresponding inputs are hard to find. To make the analogous
argument with respect to IO, we need to show that such inputs don’t exist (rather than being hard to find).
Furthermore, as part of our construction, we introduce and construct a special primitive that could be
called “deterministic order-revealing encryption”: a variant of deterministic encryption where Enc(0) and
Enc(1) must be indistinguishable, even given programs which homomorphically increment ciphertexts
(producing Enc(2), Enc(3) and so on up to some superpolynomial bound) and homomorphically compare
them. (Intuitively, homomorphic comparison enables the comparison-based decryption behavior; see section
2). To argue security of this special deterministic encryption, we employ different primitives and techniques
from the literature, including the asymmetrically contrained encryption from [CHJV14], and the proof
techniques from [BPR15] to argue unreachability of the end of a superpolynomially-long chain.
This concludes the brief overview of our scheme. An in-depth technical overview of the scheme, including
the intuition for the construction and the proof, can be found in section 2 (technical overview). Impatient
readers may wish to jump ahead to the Idealized Protocol program descriptions in figures 6 and 7 or refer to
the complete description of the Full Protocol in section 6.
1.4 Directions for Future Progress

Can we remove obfuscation? Constructing fully deniable communication without IO is a great open
problem. Three seemingly unrelated “pieces” of our construction rely on obfuscation, as follows.
(1) We need a mechanism to make each algorithm “explainable” (our scheme uses the [SW14] technique
from sender-deniable encryption). Thus, removing obfuscation in 3-message bideniable encryption would
likely also lead to sender-deniable PKE without obfuscation, which is a great open problem by itself.
(2) Another reason for using obfuscation is that (as explained more in section 2) constructing deniable
encryption with comparison-based decryption logic requires a sort of “deterministic order-revealing en-
cryption” which we call a level system: concretely, encryptions of 0 and 1 must be indistinguishable even
given programs that homomorphically increment ciphertexts (up to a superpolynomial bound) and compare
them (with the result of the comparison in the clear). We build this level system from IO. While one could
envision building a level system from weaker assumptions such as LWE, integrating a non-obfuscation-based
7
level system into a deniable encryption scheme could present additional challenges (e.g., our construction
requires both (a) the code of deniable encryption programs to be obfuscated and (b) the level system to be
puncturable).
(3) Finally, obfuscation facilitates our use of programs whose functionality depends on the result of the secret
checks inside the program, while preventing the adversary from learning which “if” statement of the program
was executed. This is crucial both to prevent the adversary from generating related transcripts except by
running Ω, and to ensure that even if it does run Ω, the programs of the scheme can undetectably “exchange
information” with each other and thus adhere to comparison-based decryption behavior.
We will be happy to see progress on removing obfuscation from any of these three pieces, which could pave
the way for obfuscation-free fully deniable encryption. Based on (1), the right place to start may well be
focusing on obfuscation-free sender-deniable PKE.
Structured CRS with secrets. Our construction requires a CRS (consisting of obfuscated programs), where
the randomness used to generate the CRS (i.e., the randomness of obfuscation and secret keys inside the
programs) must remain hidden from everyone, including the parties to the protocol.
While removing this setup assumption would be desirable, it appears to be out of the reach of current
cryptographic techniques. This question is a special case of a very general question in cryptography: it
is possible to generate any structured CRS with secrets without knowing those secrets? This in turn is a
special case of the invertible sampling hypothesis (ISH) [IKOS10] which conjectures that for any distribution
(potentially dependent on secret information), there is a way to sample from it without learning those
secrets (e.g., to sample N = pq without knowing p, q). The ISH is related to several significant questions
in cryptography, such as adaptive security and the relationship between PKE and OT (see section 6 in
[IKOS10]). However, [IKOS10] shows, albeit under strong assumptions, that the ISH does not hold for
certain distributions. While this does not imply that our CRS cannot be generated in such a way, or that
deniable encryption is impossible without a CRS, it indicates these questions may be quite hard to answer.
1.5 Variants of Deniable Encryption and Other Related Concepts

Next, we overview some variants of deniable encryption, deniable communication, and surrounding concepts.
While they are not directly relevant to this work, clarifying these concepts may prevent confusion.
• Post-execution vs. adaptive coercion. This paper considers coercion that happens after protocol
execution. A broader definition, adaptive coercion, would capture coercion at some (arbitrary) point
during the protocol execution (with uncoerced parties possibly unaware of the coercion).
• Private vs. public deniability. The deniability of the sender (or receiver, or both) is public [SW14]
if the corresponding faking algorithm does not require the true randomness or the true plaintext as
input. Our scheme has public receiver deniability (our RFake has syntax RFake(m0 , tr; ρR )). This
means that anyone, not just the receiver, can produce fake random coins for the receiver. Note that any
publicly deniable faking algorithm must be randomized: otherwise, the adversary could easily check if
a claimed r is fake by comparing it to RFake(m0 , tr).
• “Coordinated” schemes. One can also consider “coordinated” schemes [OPW11] where a single
faking algorithm takes as input the true coins of both the sender and the receiver at the same time. Such
schemes require coordination between the sender and the receiver in order to compute fake randomness.
Our scheme does not require coordination, but we note that prior to this work, even coordinated fully
8
bideniable schemes were not known.
Deniable encryption is related to a number of other cryptographic concepts:
• Incoercible key exchange is equivalent to deniable encryption. The former can be used to establish
deniable one-time-pad keys for encryption. The latter enables a sender to pick a random key and
transmit it deniably to a receiver.
• Flexible deniability. [CDNO96] also proposed a weaker deniability notion, variously called flexible
deniability, multi-distributional deniability ([OPW11, BNNO11, Dac12, AFL16, CIO16]), or dual-
scheme deniability ([GKW17]). In a nutshell, this notion considers a setting where the coercer does not
know which scheme is actually in use, and the coerced party has the freedom to “lie” in an undetectable
way regarding the scheme that was actually used. (Equivalently, this notion assumes that the coercer
does not expect to see some of the randomness used by the coerced party.) We note that none of the
schemes in [OPW11, BNNO11, Dac12, AFL16, CIO16] are deniable in a setting where the coercer
knows the scheme used in full and expects to see all the random coins of the coerced party. Appendix
A provides detailed discussion of this notion and its limitations.
• Non-committing (adaptively secure) encryption (NCE, [CFGN96]) is weaker than deniable en-
cryption, and designed for a different purpose. NCE requires that a simulator can generate dummy
ciphertexts that can later be opened to any plaintext. The differences with deniable encryption are
twofold. First, deniable encryption enables faking of real ciphertexts (that carry plaintexts), while NCE
ciphertexts can either be faked (if simulated) or carry a plaintext (if real). Thus, in NCE, parties cannot
fake; only the simulator can. Secondly, fake opening on behalf of all parties in NCE is done by the
same entity, the simulator, while in deniable encryption the sender and the receiver fake independently
of each other.
Bideniable encryption is strictly stronger than NCE: any bideniable encryption is also an NCE
[CDNO96], but two-message NCE (e.g., [CDMW09]) is provably not bideniable, due to the three-
message lower bound of [BNNO11].
• Deniable authentication. Deniable encryption is incomparable to deniable authentication. Deniable
authentication allows the receiver of a message to authenticate the message’s origin and contents, while
preventing the receiver from convincing a third party who did not directly witness the communication
that the message came from the sender (see, e.g., [DKSW09]). In contrast, in deniable encryption, the
third party (adversary) may directly witness the communicated ciphertext and learn whether the parties
have communicated with each other. The goal of deniable encryption is not to hide whether a party
participated in a communication, but rather to preserve secrecy of the communication contents — even
when parties are coerced (separately or jointly) to reveal their internal secrets.
1.6 Prior Work on Deniable Encryption

The definition of deniable encryption was introduced in 1996 by [CDNO96]. However, the techniques of that
time fell short of achieving deniability: in fact, [CDNO96] presented a construction where the distinguishing
advantage between real and fake opening was inversely proportional to the length of the ciphertext, thus
requiring superpolynomially long ciphertexts in order to achieve cryptographic deniability. It was not until
2014 that Sahai and Waters presented the first (and, to date, the only) construction of sender-deniable
encryption [SW14]. Their construction is based on indistinguishability obfuscation.
The [SW14] scheme can be transformed into a three-message receiver-deniable protocol using a generic
9
transformation from sender- to receiver-deniable encryption (due to [CDNO96]) at the cost of one additional
round, as follows: the receiver first deniably sends a random bit b to the sender deniably using the sender-
deniable protocol, then the sender sends b ⊕ m to the receiver in the final round. Furthermore, if the sender
sends b ⊕ m using the sender-deniable protocol rather than in the clear, the resulting scheme will be sender-
or-receiver-deniable: that is, deniable against adversaries that coerce either one but not both of the parties.
This final step incurs no additional rounds if (as in [SW14]) the message needs not be decided until the last
round of the sender-deniable protocol. However, all these constructions rely heavily on the fact one of the
parties’ internal states remains hidden, and therefore fail to achieve bideniability.
Several prior works have focused on proving lower bounds for deniable encryption. [CDNO96] showed
that a certain class of schemes cannot achieve better distinguishing advantage than inverse polynomial.
[Dac12] extended this result to a broader class of constructions, showing that the same holds for any
black-box construction of sender-deniable encryption from simulatable encryption. [Nie02] showed that
any non-committing encryption, including bideniable encryption, can only reuse its public key an a priori
bounded number of times; and therefore deniable communication must be interactive, even if two messages.
Using different techniques, [BNNO11] showed that two-message receiver-deniable schemes, and hence also
bideniable schemes, do not exist.
1.7 Organization, and How to Read This Paper

Organization. Section 2 gives an informal yet almost complete description of the scheme, and outlines
the main proof steps. Section 3 formally defines bideniable and off-the-record deniable encryption.
Section 4 details the Idealized Protocol and security proof in the oracle-access model. Section 5 covers
preliminaries: iO, puncturable PRFs, and other cryptographic primitives necessary for our construction.
Section 6 gives a complete description of our deniable encryption scheme and states 4 main lemmas from
which security of the scheme follows. Section 7 formally defines, constructs, and proves security of the level
system which is an essential building block of our deniable encryption scheme. Finally, Sections 8 and 9
give the full proofs of bideniability and off-the-record deniability of our Full Protocol.
How to read this paper. For a general understanding and the quickest read, we recommend section 2,
which describes the scheme almost fully, albeit assuming ideal oracle access to the programs. The rest of
the paper focuses on instantiating the ideas from section 2 with concrete IO-friendly primitives, and arguing
security. To understand the details of how the scheme is implemented with IO, we additionally suggest
section 2.4, which overviews the changes between the idealized (oracle-access) scheme and the IO-based
scheme, and then section 6 for the full construction.7 To understand the details of the IO-based proof,
we suggest the proof overview in section 2.3 (four main proof steps with high-level intuition for the “iO
gymnastics” at each step), then sections 6.3 (formal statements of each proof step) and 8.1 (concise list of
hybrids). For those specifically interested in the security proof for the level system primitive, we suggest
sections 7.3 (main steps and logic) and 7.4 (concise list of hybrids).
Finally, although the proofs in this paper take a lot of space, they are geared to be readily accessible to
readers familiar with IO techniques. There is a clear strategy behind the low-level IO gymnastics, and the
proof structure is simply a hybrid argument that breaks down into a handful of modular steps.8 The hybrid
7
Especially section 6.2.1, which gives an overview, motivation and syntax for the level system, and the theorem in section 6.2.3,
which explains all the primitives used in the full protocol described in fig. 18 and fig. 19.
8
For example, the main security proof has four logical steps, and behind each step there is an intuitive high-level strategy behind
the low-level puncturing and “iO gymnastics”.
10
distributions themselves take a lot of the space: the scheme has six program descriptions, and their code can
take up to three pages of a hybrid description; arguing indistinguishability between hybrids takes relatively
little space in comparison. Yet most of the changes between hybrids are straightforward (e.g., puncturing
keys).9 We chose to make each hybrid self-contained (and hence unavoidably rather repetitive): this makes
the proof (much) longer, but for the sake of readability, as describing only the “diffs” between hybrids would
make it laborious for the reader to reconstruct exactly what the programs look like in any given hybrid.
2 Towards the Scheme: Technical Overview

This section provides an informal yet almost complete overview of our construction. The primary purpose of
this section is to guide the reader through the process of designing the scheme, outlining concrete attacks and
corresponding protection mechanisms. This should be helpful for readers who want to gain some intuition
about the scheme and its security, but are not willing to read the whole 250-page full version [?], and for
readers seeking to design a scheme from weaker assumptions (several issues described in this overview inhere
in any 3-round deniable encryption, and could arise in schemes with more rounds too).
In this overview we describe the scheme in the oracle-access model. That is, we assume that all parties and
the adversary have oracle access to programs P1, P2, P3 (which generate the three messages of the protocol),
decryption program Dec, and faking programs SFake, RFake.
We build our scheme in two main steps. As a first attempt, we try to avoid the known attacks on the 2-message
case by considering a 3-message scheme. Next, we discuss some attacks and augment our scheme with levels
and comparison-based decryption behavior, which yields our final scheme.
2.1 A First Attempt

Recall the [SW14] technique, mentioned above, that transforms any algorithm into a deniable version using
indistinguishability obfuscation. Given this, a natural attempt to build deniable encryption is to take any
(2-message) public-key encryption scheme and use the [SW14] technique to make each of its algorithms
Gen, Enc, and Dec deniable. Concretely, the [SW14] technique takes any randomized algorithm A (with
domain X and range Y ) and outputs two obfuscated programs A0 and F , where: A0 is the “deniable version”
of A; and F is a “faking algorithm” that, for any input (x, y) ∈ X × Y , outputs randomness ρ such that
A0 (x; ρ) = y. Using this technique, we can take any protocol and equip parties with a way to “explain” any
given protocol message they send: that is, to produce fake randomness which makes that protocol message
consistent with any plaintext of the parties’ choice.
This approach would allow, for example, the receiver to create a fake sk0 decrypting a given ciphertext c to
any plaintext of its choice. This sk0 would even be indistinguishable from the real sk, to an adversary that only
sees the purported secret key. But the problem is that the adversary sees other related information: e.g., it has
the public key, so can run the encryption algorithm and generate outputs related to sk. The [SW14] technique
does not work when applied to multiple programs with interrelated outputs: such as Gen, Enc and Dec.
Let us now outline the result of [BNNO11]: impossibility of bideniable encryption in 2 messages. This
will give us insight on how to construct a 3-message bideniable encryption scheme while “avoiding” the
9
For instance, the proof of security of the level system, despite taking almost 100 pages, almost entirely consists of applying one
of only two changes at each step: either puncturing a public key of a special encryption scheme (with a reduction to IO security), or
puncturing a corresponding secret key (with a reduction to a special security property of that encryption scheme).
11
impossibility. Also, the [BNNO11] result yields a concrete attack on the first-attempt scheme outlined above.
Impossibility of the 2-message case ([BNNO11]). [BNNO11] shows that even receiver-deniable (as op-
posed to bideniable) schemes are impossible with two messages. Their result is unconditional. Their proof
shows that any 2-message receiver-deniable encryption scheme, even for a single-bit plaintext, can be used to
deniably send any polynomial number of plaintexts, simply by reusing the first message (pk) and sending
multiple second messages c1 , . . . , cN (where N is arbitrarily, but polynomially, large); then they show that all
these ciphertexts can be faked simultaneously using a single fake decryption key. This implies a method for
compressing an arbitrary string beyond what is information-theoretically possible, as follows. To compress a
string b1 , . . . , bN from N bits (where N is larger than |sk|) to |sk| bits: (1) prepare N encryptions of 0 under a
single pk (call them c1 , . . . , cN );10 (2) compute sk(1) ← RFake(sk, c1 , b1 ), sk(2) ← RFake(sk(1) , c2 , b2 ), . . . ,
sk(N ) ← RFake(sk(N −1) , cN , bN ). The final string sk(N ) is a compressed description of b1 , . . . , bN , since
it is shorter than N and since the original string can be recovered by decrypting each bi as Dec(sk (N ) , ci ).
Since most strings cannot be compressed, we have a contradiction.
Stated differently, this impossibility says that a secret key which was faked multiple times to lie about different
ciphertexts has to “remember” or store information about each lie; but information-theoretically, it cannot
remember more information than its length allows. Thus, at some point, such a secret key has to “forget”
previous lies, and then it can be used to decrypt the original ciphertext to its real plaintext. That is, there is
always an attack on any 2-message scheme, which roughly goes as follows. Assume the adversary sees a
ciphertext c, claimed to encrypt plaintext m0 , together with a fake sk0 that decrypts c to m0 ; but in reality, c
encrypts m. The adversary can generate N > |sk| ciphertexts c1 , . . . , cN as above, and run RFake iteratively
to compute sk(N ) as above, and then compute Dec(sk(N ) ; c) = m to learn the true plaintext.
In summary, the core issue with the 2-message schemes is that for a single receiver message (i.e., pk) it
is possible to efficiently generate many different sender messages (i.e., ciphertexts), such that all these
ciphertexts are valid ciphertexts with respect to the same receiver key; this, in turn, means we must be able to
use a single secret key to fake all the ciphertexts at once, which is information-theoretically impossible.
What would be the analogous argument in the 3-message case? Consider a 3-message scheme with messages
(µ1 , µ2 , µ3 ). If the scheme has the property that, given a receiver message µ2 , one can efficiently generate
many different sender messages µ1 (i) , µ3 (i) yielding valid transcripts (µ1 (i) , µ2 , µ3 (i) ), then the scheme is
subject to the [BNNO11] impossibility. For example, consider a 3-message scheme where the third message
is a fresh encryption under freshly sampled random coins: this enables generating many third messages µ3 (i)
for any given µ1 , µ2 , and applying the [BNNO11] argument shows that any fake receiver randomness must
remember a lie for each µ3 (i) , so this scheme is susceptible to the same attack as two-message schemes.
Base Protocol. Now we present our Base Protocol, which is insecure but will be augmented later to achieve
a secure version. The scheme has parties first exchange two PRF values, then has the sender encrypt its
plaintext m into a ciphertext µ3 using program P3, which the receiver can decrypt using program Dec. Before
presenting the scheme formally, we give motivation for the design.
With the [BNNO11] impossibility in mind, a natural approach to building a 3-message scheme is to ensure
that for any given first two messages µ1 , µ2 , only one consistent third message µ3 can be efficiently computed.
The Base Protocol achieves this using the following ideas.
1. The first message µ1 “commits” to the sender’s coins s and message m.
10
These ciphertexts do not depend on the string to be compressed and thus can be thought of as public parameters of the
compression protocol.
12
2. The third message µ3 is a deterministic, symmetric-key encryption of m under a key K that is hardwired
in programs P3 and Dec and is unknown to parties.
3. P3(s, m, µ1 , µ2 ) does a validity check before its output: if µ1 is indeed a “commitment” to s and m,
P3 outputs µ3 ; otherwise, it outputs ⊥.
In other words, the only way for the sender to generate a valid µ3 is to “prove” to P3 that it is running P3 on
the same s, m used to compute µ1 . Thus, as long as K remains secret and the ciphertexts are sufficiently
sparse, for any µ1 , µ2 , there is only one (efficiently computable) consistent µ3 .
So far, since µ3 is computed under the same key K in each execution and it is not randomized, all executions
with the same m yield the same µ3 , which is clearly insecure. To fix this, we let µ3 encrypt not only m, but
the first two messages µ1 , µ2 as well, forcing different executions to have different third messages.
We have not yet discussed how the second message µ2 should be computed, which actually depends on an
extension of the attack based on [BNNO11], described above. Recall that we wanted it to be hard to compute
multiple transcripts with the same µ2 : say, (µ1 (i) , µ2 , µ3 (i) ). In fact, we also want it to be hard to convert a
transcript (µ1 , µ2 , µ3 ) with receiver randomness r into a different transcript (µ1 0 , µ2 0 , µ3 0 ) consistent with
the same r, since it is possible to extend the attack to this case as well. With this in mind, we design the
protocol as follows.
1. The second message µ2 is a pseudorandom function output PRF(r, µ1 ), for a PRF key that is hardwired
into P2 and Dec and not known to the parties.11 The PRF inputs are the receiver randomness r and the
first message µ1 .
2. Dec(r, µ1 , µ2 , µ3 ) does a validity check before decryption: if µ2 is the correct PRF output for input
(r, µ1 ), Dec outputs m; otherwise, it outputs ⊥.
Thus, the only way for the receiver to decrypt is to “prove” to Dec that it is running Dec on a valid r
(consistent with µ2 ). This ensures that it is hard to transform a transcript (µ1 , µ2 , µ3 ) into a different
(µ1 0 , µ2 0 , µ3 0 ) consistent with the same receiver randomness r, since that would require finding µ1 0 , µ2 0 such
that µ2 0 = PRF(r, µ1 0 ), for an unknown r and an unknown PRF key.
We conclude this protocol design with a couple of final notes. First, we instantiate our “commitment” using
a PRF as well, with its key hardwired into programs P1, P3 and not known to parties (thus, both µ1 and
µ2 are PRF outputs). Secondly, we augment each program P1, P2, P3, Dec with a “trapdoor step” which
makes each of these programs separately deniable, in the spirit of the [SW14] technique. Finally, we make
the validity check inside Dec accept if P2(r, µ1 ) = µ2 , rather than if PRF(r, µ1 ) = µ2 ; the difference is that
P2 also accepts “fake” values which are not real preimages of the PRF. We make a similar modification to
P3: its validity check verifies that P1(s, m) = µ1 and therefore would also accept fake s which is not a real
opening of the “commitment”. These changes are necessary because without them, an adversary could use
the validity check to test whether a given s is a real (PRF) preimage of µ1 or a fake one.
We present the programs P1, P2, P3, Dec, SFake, RFake as described so far, in fig. 3. For readability, the
program includes comments to explain what the code is doing. Despite the somewhat dense code, the
programs are very structured, and in a nutshell they behave as follows.
• Each program has a main step which is triggered when the program is run on uniformly random s or r
(which is the case during an honest execution);
11
In this high-level description we omit PRF keys to simplify notation.
13
• Programs P1, P2, P3, Dec each have a trapdoor step which is triggered when the programs are given
fake randomness (which has a special format recognizable to the programs). The set of fake randomness
is sufficiently sparse that the trapdoor steps are almost never triggered on uniform s or r. Fake
randomness contains an “instruction” of how the program should behave.
• Programs P3 and Dec run validity checks, as described and motivated above.
• Programs SFake and RFake generate fake randomness which can be recognized by other programs.
In particular, during an honest execution with uniformly random s and r and plaintext m, the parties exchange
messages µ1 , µ2 , µ3 (computed by programs P1, P2, P3, respectively), as follows: µ1 = PRF(s, m), µ2 =
PRF(r, µ1 ), µ3 = EncK (m, µ1 , µ2 ).12 The receiver decrypts (µ1 , µ2 , µ3 ) by running Dec(r, µ1 , µ2 , µ3 ),
which verifies that PRF(r, µ1 ) = µ2 , then decrypts µ3 and outputs m.
Base Protocol programs: first attempt at deniable encryption.

Program P1(s, m)
1. Trapdoor step: if DecKS (s) = (m0 , µ1 0 , µ2 0 , µ3 0 ) and m0 = m, then return µ1 0 //if s is fake and
encodes m, output encoded µ1 0
2. Main step: Return µ1 ← PRF(s, m). //otherwise output PRF(s, m)
Program P2(r, µ1 )
1. Trapdoor step: if DecKR (r) = (m0 , µ1 0 , µ2 0 , µ3 0 ) and µ1 0 = µ1 , then return µ2 0 . //if r is fake and
encodes µ1 , output encoded µ2 0
2. Normal step: else return PRF(r, µ1 ). //otherwise output PRF(r, µ1 )
Program P3(s, m, µ1 , µ2 )
1. Validity check: if P1(s, m) 6= µ1 , then abort;
2. Trapdoor step: if DecKS (s) = (m0 , µ1 0 , µ2 0 , µ3 0 ) and (m0 , µ1 0 , µ2 0 ) = (m, µ1 , µ2 ), then return µ3 0 .
//if s is fake and encodes correct (m, µ1 , µ2 ), output encoded µ3 0
3. Normal step: else return EncK (m, µ1 , µ2 ).//otherwise encrypt m
Program Dec(r, µ1 , µ2 , µ3 )
1. Validity check: if P2(r, µ1 ) 6= µ2 , then abort;
2. Trapdoor step: if DecKR (r) = (m0 , µ1 0 , µ2 0 , µ3 0 ) and (µ1 0 , µ2 0 , µ3 0 ) = (µ1 , µ2 , µ3 ), then return m0 .
//if r is fake and encodes correct (µ1 , µ2 , µ3 ), output encoded m0
3. Normal step: else decrypt (m00 , µ1 00 , µ2 00 ) ← DecK (µ3 ). If (µ1 00 , µ2 00 = µ1 , µ2 ) then output m00 , else
abort. //otherwise decrypt honestly
Program SFake(s, m, m̂, µ1 , µ2 , µ3 ; ρS )
1. Validity check: if P1(s, m) 6= µ1 , then abort;
2. Normal step: else return EncKS (m̂, µ1 , µ2 , µ3 , ρS ) // output fake s with fake plaintext and the tran-
script inside.
Program RFake(m̂, µ1 , µ2 , µ3 ; ρR )
1. Normal step: return EncKR (m̂, µ1 , µ2 , µ3 , ρR ) // output fake r with fake plaintext and the transcript
inside
Figure 3: Base Protocol programs: first attempt at deniable encryption. P1, P2, P3, Dec are determinis-
tic;14 SFake, RFake are randomized.
12
Note that s, m (and r, µ1 ) are both inputs to the PRF, not keys; we omit PRF keys for simplicity of notation.
14
We treat s, r as non-random inputs, even though they are supposed to be uniformly chosen, since they are reused across different
programs.
14
If the parties want to claim to a coercing adversary that they transmitted a different plaintext m̂, they can use
SFake, RFake to compute fake s0 and r0 , which are random-looking strings with m̂, µ1 , µ2 , and µ3 encrypted
inside. If the adversary decrypts the transcript (µ1 , µ2 , µ3 ) with fake r0 = EncKR (m̂, µ1 , µ2 , µ3 , ρR ), it will
get m̂ as a result (via the trapdoor step of the decryption program). Similarly, the other programs, when given
fake s0 or r0 as input, employ their trapdoor steps as well, making each protocol message appear consistent
with m̂.
The problem with the Base Protocol. We designed our scheme above with specific attacks in mind, but is
it secure against all attacks? The answer is “almost”: it is relatively easy to show security of the scheme in
an idealized model where parties (and the adversary) have only oracle access to the programs, but only as
long as the adversary cannot query the SFake oracle. Concretely, the adversary can use SFake to mount a
certain attack Ω on the scheme, but this turns out to be the only possible type of attack. In section 2.2, we
describe a special protection mechanism — comparison-based decryption behavior — which, when added
to the protocol, prevents this type of attack and yields a scheme that is fully deniable even if the adversary
has an access to all oracles including SFake. (And in the full version [?], we prove this result even when the
adversary can see the code of all programs, obfuscated under IO).
Let’s unpack why the protocol described so far is insecure. Recall that we wanted µ1 to serve as a “com-
mitment”, and we wanted P3 to output µ3 only if the sender uses the same s and m in the commitment and
as input to P3. This was important to make sure that for any µ1 , µ2 , at most one consistent µ3 is efficiently
computable. Then, however, we said that P3 should perform its validity check with respect to the whole
program P1 and not just the commitment; in particular, the validity check in P3 accepts not only the true
opening of the commitment, but also fake s. The problem is that P1, due to its trapdoor step, is not binding:
given any µ1 ∗ = PRF(s∗ , m0 ) and m1 6= m0 , it is easy to generate a different s1 that passes the verification
check. In fact, SFake does exactly that: given (s∗ , m0 , m1 , µ1 ∗ , µ2 , µ3 ) for some µ2 , µ3 , it outputs s1 such
that P1(s1 , m1 ) = µ1 ∗ .
While this is not yet a concrete attack, it exposes a problem with our initial hope of a committing first message:
sender deniability guarantees the first message is easily invertible, potentially with respect to inconsistent
plaintexts m, so µ1 cannot be committing. Thus, it is easy to create many fake si consistent with µ1 , and
therefore many third messages µ3 (1) , µ3 (2) , . . ., all consistent with a given (µ1 ∗ , µ2 ∗ ). A procedure Ω that
does this is detailed in fig. 4. For our purposes, the key features of the attack Ω are as follows.
• To generate such a µ3 (i) , encrypting some m1 for a given (µ1 ∗ , µ2 ∗ ), one has to run P3 on certain fake
sender randomness si .
• P3 can recognize when it is being used to generate such a µ3 (i) . (This is because P3 will be run on a
“mixed input”: that is, P3 should be run on s, m, µ1 ∗ , µ2 ∗ , and a fake si that encodes the same µ1 ∗ but
different µ˜2 6= µ2 ∗ .)
• The only way to generate such fake si efficiently is to run SFake (on a transcript different from the one
being attacked: specifically, with a different second message).
Since it is easy to generate many third messages, our scheme is subject to the same attack as all 2-message
schemes: namely, the adversary can generate many ciphertexts µ3 (i) , fake each of them to compute an
N -times-faked r(N ) , and then use it to correctly decrypt the original µ3 ∗ . While this attack inheres in
all 2-message schemes [BNNO11], in the 3-message case we can fix it. We do so by introducing levels
and comparison-based decryption behavior, which specify how the decryption program should behave
when the adversary tries to use such r(N ) to decrypt a transcript (µ1 ∗ , µ2 ∗ , µ3 (i) ) or a challenge transcript
15
A procedure Ω to generate a new third message encrypting m1
and consistent with given first and second messages µ1 , µ2 .
Inputs to Ω(µ1 ∗ , µ2 ∗ , µ3 ∗ , s∗ , m∗ , m1 ) are: transcript (µ1 ∗ , µ2 ∗ , µ3 ∗ ), sender randomness s∗ (which could
be real or fake), plaintext m∗ , and new desired plaintext m1 :
1. Compute an auxiliary transcript ter = (µ1 ∗ , µ˜2 , µ˜3 ) with the same first message µ1 ∗ , but different
second message µ˜2 , by choosing fresh receiver randomness r̃ and setting ter ← tr(s∗ , r̃, m∗ ). Note that
the first message of this transcript is P1(s∗ , m∗ ) = µ1 ∗ .
2. Compute s1 ← SFake(s∗ , m∗ , m1 , µ1 ∗ , µ˜2 , µ˜3 ). Note that s1 is fake randomness which remembers
m1 , µ1 ∗ and a new µ˜2 6= µ2 ∗ .
3. Compute µ3 (1) ← P3(s1 , m1 , µ1 ∗ , µ2 ∗ ).
Ω can now be repeated on input µ1 ∗ , µ2 ∗ , µ3 (1) , s1 , m1 , m2 to generate µ3 (2) , and so on.
Figure 4: Procedure Ω to compute many third messages consistent with given µ1 , µ2 .
(µ1 ∗ , µ2 ∗ , µ3 ∗ ).
2.2 Levels, Comparison-Based Decryption, and the Final Scheme

Comparison-based decryption behavior. Let (µ1 ∗ , µ2 ∗ , µ3 ∗ ) be a challenge transcript. For any superpoly-
nomial T and j ∈ {0, . . . , T }, let rj be the output of RFake on transcript (µ1 ∗ , µ2 ∗ , µ3 (j) ), where µ3 (j) is
computed by j iterations of Ω. Let µ3 (0) denote the challenge µ3 ∗ . When Dec is run on rj and µ3 (i) , for
i, j ∈ {0, . . . , T }, comparison-based decryption behavior requires the following.
1. Oblivious past: When j > i, Dec outputs ⊥.
2. Correctness forward: When j < i, Dec decrypts µ3 (i) correctly (as long as consistency checks pass).
3. When j = i, Dec should decrypt µ3 (i) according to the instruction in fake rj .
That is, if an adversary creates fake rj using µ3 (j) , the jth in the sequence of ciphertexts, this rj can be used
to honestly decrypt ciphertexts “after” µ3 (j) , but cannot be used to decrypt ciphertexts “before” µ3 (j) ; and
naturally, rj decrypts µ3 (j) itself according to the instruction inside fake rj .
Ω Ω ... Ω Ω Ω Ω Ω ...
tr tr1 tri−1 tri tri+1 tri+2
Oblivious past: RFake Correctness forward:
decrypting with ri fails ri decrypting with ri succeeds
Figure 5: Comparison-based decryption behavior
Comparison-based decryption behavior prevents the attack described above, despite the fact that Ω enables
the adversary to generate many third messages. Next, we give some intuition as to why. Recall that the attack
had the adversary generate a fake rj (by faking a ciphertext sequence µ3 (1) , µ3 (2) , . . .) and then return to the
challenge µ3 ∗ and decrypt it. Thus, a natural idea to mitigate this attack is to make Dec output ⊥ whenever
fake rj is used to try to decrypt the initial µ3 ∗ = µ3 (0) .15 This simple modification indeed stops the attack,
15
Such a restriction is not possible in the 2-message case, in contrast to the 3-message case. This relates to the fact that our
procedure Ω which generates µ3 (i) is “one way”, i.e., it is easy to generate µ3 (i+1) from µ3 (i) , but it could be hard — and is hard, in
our scheme — to generate µ3 (i) from µ3 (i+1) . In contrast, in any 2-message scheme, there is no order on the ciphertexts; they are
always easy to generate.
16
but introducing it alone would break security. To maintain security, we need to make sure that Dec on inputs
rj , µ3 (i) should output ⊥ for all j > i, and not just j > i = 0.16 In other words, the “oblivious past” rule is
the “minimum” modification which prevents fake rj from decrypting µ3 ∗ = µ3 (0) and maintains security of
the scheme.
Finally, the “correctness forward” rule must hold as well, since it is implied by sender-deniability. As a result,
the behavior of the decryption program depends on the comparison of “indices” of the transcript and the
receiver randomness; therefore, we call this comparison-based decryption behavior.
Implementing comparison-based decryption behavior: levels.
Next, we consider how to construct our programs such that comparison-based decryption behavior holds.
When we run Dec on some µ3 and some r, how does it know whether µ3 is “forward” of r in the chain
(meaning Dec should decrypt honestly), or “in the past” with respect to r (meaning Dec should output ⊥)?
To this end, we introduce levels. That is, we have all fake sender randomness, all fake receiver randomness,
and all third message µ3 (i) also encrypt a number ` between 0 and some superpolynomial T , as follows.
• Fake sender randomness encrypts, among other things, a level ` which is how many times this
randomness was faked. (E.g., to compute fake randomness, the sender would normally run SFake once,
so the level ` of the resulting fake randomness is 1. If it runs SFake on the resulting randomness again,
its level ` will be 2, and so on).
• Each potential third message µ3 (i) also encrypts, in addition to m and µ1 , µ2 , its level, which is its index
i in the chain. Note that the algorithm Ω which computes µ3 (i) outputs µ3 (1) , µ3 (2) , . . . sequentially,
and therefore their index i is well defined. In an honest execution, the level of µ3 is always set to 0.
• Fake receiver randomness encrypts, among other things, a level ` which is the level of its “parent”
transcript (i.e., the transcript which was used as input to RFake). (E.g., to compute fake randomness,
the receiver would normally run RFake on the honest transcript, which has level 0, so the resulting fake
randomness would have level 0 too).
We claim that storing this “level” information in fake randomness and third messages is enough for the
scheme to maintain the level information accurately and follow comparison-based decryption behavior. For
instance, Dec can decide its output behavior by comparing the levels inside r and µ3 . RFake can record the
correct level of r by copying the level of its parent ciphertext. SFake can maintain the correct number of
times something was faked, by reading the level in its input s and incrementing it. P3, as discussed above,
can detect when it is being run within Ω, and it can put inside its output third message the level it copied from
input s; since generating each new µ3 requires once-more fake s, the level in s — i.e., the number of times it
was faked — corresponds to the index of µ3 in the chain.
Our final protocol in the oracle-access model. We present our final protocol (albeit still in the oracle
model) in figs. 6–7. This scheme is a provably secure deniable encryption scheme in the oracle access model,
as we show in section 4.
The structure of the final protocol programs is summarized below.
16
To see this, suppose Dec outputs ⊥ whenever rj , j > 0 is used to decrypt µ3 ∗ = µ3 (0) . Now consider trying to decrypt some
µ3 with, say, ri+3 . r3 does not decrypt µ3 (0) , and the difference between (µ3 (0) , r3 ) and (µ3 (i) , ri+3 ) is that µ3 (0) was generated
(i)
with truly random s whereas µ3 (i) used si which was faked i times. Sender deniability requires these two cases be indistinguishable,
so µ3 (i) must not be decrypted by ri+3 .
17
• Each program has a main step which is triggered when the program is run on uniformly random s or r,
which is the case during an honest execution.
• Programs P1, P2, P3, and Dec also have a trapdoor step which is triggered when the programs receive
fake randomness (which has a special format recognizable to the programs). The set of fake randomness
is sufficiently sparse that the trapdoor step is almost never triggered on uniformly chosen s or r. Fake
randomness contains an “instruction” of how the program should behave on some particular input.
• Programs P3 and Dec also have a “mixed input” step which serves to prevent attacks using Ω to
generate many third messages µ3 . P3’s mixed input step copies the level from its input s into the third
message µ3 , ensuring µ3 encrypts its own index in the sequence. Dec’s mixed input step implements
comparison-based decryption behavior by comparing the levels of µ3 and r.
The mixed input steps are triggered when the programs receive fake s (or r) as input, but the program’s
other inputs do not match the inputs in the instruction inside s (or r). P3 enters its mixed input step
when its input and fake s contain the same µ1 but different second messages, and Dec enters its mixed
input step when its input and fake r contain the same µ1 , µ2 but different third messages.
• Programs P3 and Dec’s output behavior depends on validity checks, as in the Base Protocol (and for
the same reasons as in the Base Protocol).
• Programs SFake and RFake generate fake randomness that is recognizable to the other programs, and
maintain accurate level information inside the fake randomness as follows: SFake increments the
level of sender randomness with respect to its input sender randomness (unless the latter is honest, in
which case SFake sets the level to 0); and RFake copies the level from the parent transcript into fake
randomness.
The interesting cases of protocol execution are summarized next.
• Normal protocol execution. Executing the programs on randomly chosen s∗ , r∗ and plaintext m∗0
triggers the main step, yielding outputs µ1 ∗ = PRF(s∗ , m∗0 ), µ2 ∗ = PRF(r∗ , µ1 ∗ ), and µ3 ∗ =
EncK (m∗0 , µ1 ∗ , µ2 ∗ , 0), where the last 0 is the level. Dec, given the resulting transcript as input,
outputs m∗0 via its main step.
• Fake randomness of parties. A sender wishing to claim that it sent plaintext m∗1 6= m∗0 can run SFake
to obtain fake s0 encoding (m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 1), where the last 1 is the level. A receiver wishing
to claim that it received m∗1 6= m∗0 can run RFake to obtain fake r0 encoding (m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0),
where the last 0 is the level. Executing programs on fake s0 or fake r0 and m∗1 triggers the trapdoor step,
so programs will output the values hardwired into the fake s0 or r0 . Thus, P1 will output µ1 ∗ , P2 will
output µ2 ∗ , P3 will output µ3 ∗ , and Dec will output m∗1 via their trapdoor steps, making the transcript,
originally for plaintext m∗0 , appear consistent with m∗1 .
• Efficiently computable related transcripts. It is only possible to compute related transcripts of the
form (µ1 ∗ , µ2 ∗ , µ3 ), where µ3 = EncK (m, µ1 ∗ , µ2 ∗ , `), ` ≥ 1; moreover, the only way of doing so
is to use the procedure Ω described above (which invokes SFake). Trying to compute µ3 a for such
transcript will cause program P3 to execute its “mixed input step”, ensuring that such µ3 receives level
` ≥ 1; for this, it is important that SFake increments the level inside s. Trying to decrypt such a related
transcript (µ1 ∗ , µ2 ∗ , µ3 ) will cause program Dec to execute its “mixed input step”, ensuring that the
requisite decryption behavior is observed (that fake r decrypts correctly transcripts with larger level,
but fails to decrypt transcripts with smaller level); for this, it is important that RFake copies the level
18
Programs P1, P3, SFake.
Program P1(s, m)
1. Trapdoor step:
(a) out ← DecKS (s); if out = 0 fail0 goto main step, else parse out as (m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m = m0 then return µ1 0 ; //if s is fake and encodes m, output encoded µ1 0
2. Main step:
(a) Return µ1 ← PRFkS (s, m). //otherwise output PRF(s, m)
1. Validity check: if P1(s, m) 6= µ1 then abort;
2. Trapdoor step:
(b) If m, µ1 , µ2 = m0 , µ1 0 , µ2 0 then return µ3 0 ; //if s is fake and encodes correct (m, µ1 , µ2 ), output
encoded µ3 0
3. Mixed input step: If m, µ1 = m0 , µ1 0 but µ2 6= µ2 0 then return µ3 ← EncK (m, µ1 , µ2 , `0 ); //if s is
fake and encodes correct (m, µ1 ) but incorrect µ2 0 , encrypt m with level copied from s
4. Main step:
(a) Return µ3 ← EncK (m, µ1 , µ2 , 0). //otherwise encrypt m with level 0
Program SFake(s, m, m̂, µ1 , µ2 , µ3 )
2. Trapdoor step:
(b) If m, µ1 = m0 , µ1 0 then
i. If ` ≥ T then abort;
ii. Return EncKS (m̂, µ1 , µ2 , µ3 , ` + 1). //if input s is already fake then output new fake s with
fake plaintext, the transcript, and incremented level
3. Main step:
(a) Return EncKS (m̂, µ1 , µ2 , µ3 , 1). //otherwise output fake s with fake plaintext, the transcript, and
level 1
Figure 6: Programs P1, P3, SFake.
from the transcript to r.
2.3 Outline of security proof in oracle-access model.

Since the proof even in this simpler (oracle-access) model is somewhat lengthy, we only outline the main steps
here, with intuition for each. The proof proceeds in four main hybrid steps. We start with a real execution
corresponding to plaintext m∗0 , where the adversary receives real randomness s∗ , r∗ .
• Step I: indistinguishability of sender explanations. Instead of giving the adversary real s∗ , we give
it s0 = EncKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , ` = 0) (note that this s0 contains level 0, unlike fake randomness
produced by SFake which contains level at least 1).
Intuitively, the reason why we can switch from s∗ to s0 indistinguishably is because all programs treat
s∗ and s0 indistinguishably. That is:
– either the programs output the same value, possibly via different branches of execution (e.g., P1
19
Programs P2, Dec, RFake.
Program P2(r, µ1 )
1. Trapdoor step:
(a) out ← DecKR (r); if out = 0 fail0 then goto main step, else parse out as (m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
(b) If µ1 = µ1 0 then return µ2 0 ; //if r is fake and encodes µ1 , output encoded µ2 0
2. Main step:
(a) Return µ2 ← PRFkR (r, µ1 ). //otherwise output PRF(r, µ1 )
1. Validity check: if P2(r, µ1 ) 6= µ2 then abort;
2. Trapdoor step:
(a) out ← DecKR (r); if out0 = 0 fail0 then goto main step; else parse out0 as (m0 , µ1 0 , µ2 0 , µ3 0 , `0 , ρ̂);
(b) if µ1 , µ2 , µ3 = µ1 0 , µ2 0 , µ3 0 then return m0 ; //if r is fake and encodes correct (µ1 , µ2 , µ3 ), output
encoded m0
(c) out ← DecK (µ3 ); if out00 = 0 fail0 then abort, else parse out00 as (m00 , µ1 00 , µ2 00 , `00 );
3. Mixed input step: If µ1 , µ2 = µ1 0 , µ2 0 but µ3 6= µ3 0 then
(a) If (µ1 0 , µ2 0 ) = (µ1 00 , µ2 00 ) and `0 < `00 then return m00 ; //if r is fake and encodes correct (µ1 , µ2 )
but incorrect µ3 0 , decrypt honestly or abort, depending on whether the level in r is smaller than in
µ3 or not
(b) Else abort.
4. Main step:
(a) out ← DecK (µ3 ); if out = 0 fail0 then abort, else parse out as (m00 , µ1 00 , µ2 00 , `00 );
(b) If (µ1 , µ2 ) = (µ1 00 , µ2 00 ) then return m00 ; //otherwise decrypt honestly
(c) Else abort.
Program RFake(m̂, µ1 , µ2 , µ3 ; ρ)
1. out ← DecK (µ3 ); if out = 0 fail0 then abort, else parse out as (m00 , µ1 00 , µ2 00 , `00 );
2. Return r0 ← EncKR (m̂, µ1 , µ2 , µ3 , `00 , prg(ρ)). // output fake r with fake plaintext, the transcript, and
the level copied from µ3
Figure 7: Programs P2, Dec, RFake.
on input (s∗ , m∗0 ) outputs µ1 ∗ via its main step and on input (s0 , m∗0 ) outputs µ1 ∗ via its trapdoor
step);
– or the programs execute the same code, possibly outputting different results (e.g., P1, on input
(s∗ , m∗1 ) or (s0 , m∗1 ), evaluates a PRF on its input and outputs the result).
The above, and the fact that s0 is pseudorandom, allow us to change s∗ to s0 (similarly to the [SW14]
proof for sender-deniable encryption).
• Step II: indistinguishability of receiver explanations. Instead of giving the adversary real r∗ , we
give it fake r0 , i.e., r0 = EncKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , ` = 0, ρR ). Unlike in Step I, here there is a
transcript with respect to which the decryption program treats r∗ and r0 distinguishably.
Recall that r∗ honestly decrypts all related transcripts, while r0 only honestly decrypts “forward”, i.e.,
for related transcripts with level ` ≥ 1. Thus, the two programs may treat level-0 transcripts differently.
Consider a transcript (µ1 ∗ , µ2 ∗ , µ3 ∗ ), where µ3 ∗ = EncK (m∗1 , µ1 ∗ , µ2 ∗ , ` = 0) is like µ3 ∗ except that
it encrypts the wrong plaintext m∗1 . This transcript decrypts correctly to m∗1 with r∗ , but decrypting it
with r0 returns ⊥ due to the level comparison logic.
20
This single transcript makes r∗ and r0 distinguishable. As a result, the proof of Step I does not work
here. Therefore, we first move to a hybrid where this “differing” transcript doesn’t exist, as follows.
First, since s∗ (the preimage of PRF output µ1 ∗ ) is not part of the distribution anymore, we can move
µ1 ∗ outside the PRF image. Then we argue that P3 never outputs µ3 ∗ :
– The main step cannot output µ3 ∗ , since it is executed only if the validity check passes via a
correct PRF preimage, which now does not exist.
– The mixed step cannot output µ3 ∗ , since P3 can only output a ciphertext with level 0 (like µ3 ∗ )
via the mixed step if its input randomness has level 0, and such input randomness is hard to find
since SFake never outputs randomness with level 0.
– The trapdoor step cannot output µ3 ∗ , since P3 can only output µ3 ∗ via the trapdoor step if it
receives as input fake randomness that has µ3 ∗ inside to begin with. Since there are no other
means of computing µ3 ∗ , such randomness is also hard to find.
Once the differing transcript (µ1 ∗ , µ2 ∗ , µ3 ∗ ) is eliminated, we can switch r∗ to r0 similarly to Step I.
• Step III: indistinguishability of plaintexts. The next step is to switch µ3 ∗ from encrypting m∗0 to
encrypting m∗1 . This is done by “detaching” µ3 ∗ from its key K in programs P3 and Dec. Concretely:
– P3 can only output µ3 ∗ via the trapdoor thread (which does not use the key K). The reason is
very similar to the case-by-case analysis of P3 in Step II: the main step requires a PRF preimage,
which does not exist, and the mixed step requires level-0 sender randomness, which is hard to
find.
– Dec can only “decrypt” µ3 ∗ via the trapdoor thread (which, again, does not use K). To guarantee
this, we first move µ2 ∗ outside of the PRF image (this is possible since r∗ is no longer part of the
distribution). Then µ3 ∗ is never decrypted via the main step because the preimage for µ2 ∗ does
not exist. Further, µ3 ∗ cannot be decrypted via the mixed step either, because the “correctness
forward” decryption rule outputs ⊥ unless the input receiver randomness has level smaller than
the level in µ3 ∗ , and this is not possible since µ3 ∗ has the smallest possible level, 0.
In other words, neither P3 nor Dec need to use K to encrypt or decrypt µ3 ∗ . Therefore we can “detach”
K and µ3 ∗ and change the plaintext to m∗1 .
Note that the transcript now contains m∗1 , and both sender and receiver randomness s0 , r0 are consistent
with m∗0 . However, the proof is not finished yet, since parties cannot produce such s0 themselves (since
s0 has level 0).
• Step IV: indistinguishability of levels. The last step is to change the level inside s0 from 0 to 1, i.e.,
let s0 = EncKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , ` = 1). To understand the challenge of this step, it is instructive to
take a “level-centric” perspective: let’s put aside that the scheme is about transmitting plaintexts, and
instead think of fake s as an encryption of level (0 or 1), think of µ3 ∗ as an encryption of level 0, and
think of the programs of deniable encryption as implementing homomorphic operations on encrypted
levels. For example, program SFake outputs fake randomness which is an encryption of incremented
level, and thus implements a homomorphic Increment operation on levels. Program Dec compares
levels inside µ3 and r and, based on that, decrypts or outputs ⊥, and thus it implements a homomorphic
isLess function on levels, which reveals (in the clear) if one level is smaller than the other.
From this perspective, step IV essentially requires switching s0 from an encryption of 0 to an encryption
21
of 1, while the adversary has access to homomorphic functions Increment and isLess.17 In the
oracle-access model, it can be easily shown that polynomially bounded adversaries cannot distinguish
between Enc(0) and Enc(1), even given oracle access to isLess and Increment, as long as the largest
allowed level T is superpolynomial: this is because the adversary can only generate polynomial-length
sequences of encryptions — Enc(1), Enc(2), . . . or Enc(2), Enc(3), . . . (depending on whether the
challenge ciphertext was Enc(0) or Enc(1)) — and the oracles’ behavior will be identical on both
sequences.
This concludes the proof outline in the oracle-access model. We underline that in the actual construction we
need special types of PRFs, encryption schemes, and a special level system primitive in order to prove security
with iO. The proofs of steps I-III in the final construction roughly follow the same outline (sometimes with
several hybrids per each logical step), but the proof of the step IV (indistinguishability of levels) requires
substantial additional work when the adversary possesses the code of the programs. We outline the intuition
and the main steps of the proof for this step in section 7.3.
2.4 Changes to the construction due to iO.

To be able to prove security of this construction while only relying on iO, we instantiate certain primitives in
iO-friendly way, as follows:
• The three underlying encryption schemes (sender-fake scheme with key KS , receiver-fake scheme
with key KR , and main scheme with key K) are all instantiated using a special encryption scheme
called assymetric constrained encryption, or ACE [CHJV14]18 . This scheme allows us to translate
the reasoning used in the oracle-access model - that it is hard to learn the output of an oracle without
querying it on a certain input - into the obfuscation setting.
• We implement levels in a different way: instead of using plain numbers and doing increments and
comparisons in the clear (within the programs), we use a primitive called a level system, where
levels are implemented as encrypted numbers, and in addition there are programs which perform
homomorphic increment and compare on these numbers. Further, we “tie” each level to messages in
our deniable encryption protocol, by encrypting the numbers (representing levels) together with these
messages.
• Some of the PRFs we use need to have special properties: we need an injective PRF with sparse image,
and another PRF with sparse image which is also a computational extractor.
3 Defining Bideniable and Off-the-Record Deniable Encryption

We present the definition of interactive deniable encryption, or, more formally, interactive deniable message
transmission. In Section 3.1 we present the definition in the CRS model; this definition corresponds to our
main construction. In Section 3.2 we present the definition for the idealized, oracle access model.
Recall that the adversary also has µ3 ∗ which is an encryption of level 0. For simplicity, we ignore this fact in this high-level
17
overview.
18
We note that our main encryption scheme is actually implemented using a relaxed ACE, as opposed to a standard ACE. This is
only done to avoid extra security loss in certain reductions, and can be ignored for the purposes of understanding the paper.
22
3.1 Deniability in the CRS Model
Syntax. An interactive deniable encryption scheme π consists of seven algorithms π =
(Setup, P1, P2, P3, Dec, SFake, RFake), where Setup is used to generate the public programs (i.e., the
CRS), programs P1, P3 and SFake are used by the sender, and programs P2, Dec and RFake are used by
the receiver. Let tr = π(s, r, m) denote the transcript of a protocol execution on input plaintext m, sender
randomness s, and receiver randomness r, i.e., the sequence of three messages sent in the protocol execution.
That is, π(s, r, m) = tr = (µ1 , µ2 , µ3 ), where µ1 = P1(s, m), µ2 = P2(r, µ1 ), and µ3 = P3(s, m, µ1 , µ2 ).
The faking algorithms have the following syntax: SFake(s, m, m0 , tr; ρ) expects to take as input a transcript
tr along with the true random coins s and true plaintext m which were used to compute tr, and a desired fake
plaintext m0 . SFake is randomized and ρ denotes its randomness. RFake has the same syntax except that it
expects receiver randomness r instead of sender randomness s.
Bideniable and off-the-record-deniable encryption in the CRS model. Next, we define standard and
off-the-record deniability for interactive deniable encryption in the CRS model. For simplicity, we focus on
bit encryption. The definitions are naturally extensible to multi-bit plaintexts.
Formally, the deniable encryption algorithms should take the CRS as input. We omit this for notational
simplicity as it is unnecessary in our construction (where the CRS contains the programs, and the programs
do not take the CRS as input).
Definition 1. Bideniable bit encryption in the CRS model. π = (Setup, P1, P2, P3, Dec, SFake, RFake)
is a 3-message bideniable interactive encryption scheme for message space M = {0, 1}, if it satisfies the
following correctness and bideniability properties.
• Correctness: There exists a negligible function ν(λ) such that for at least a (1 − ν) fraction of
randomness rSetup ∈ {0, 1}|rSetup | , for any m ∈ M,
 
CRS ← Setup(rSetup )
s ← {0, 1}|s|
 
 
Pr  m0 6= m : r ← {0, 1} |r|
 ≤ ν(λ) .
 
 
 tr ← π(s, r, m) 
m0 ← Dec(r, tr)
• Bideniability: No PPT adversary Adv has more than negligible advantage in the following game, for
any m0 , m1 ∈ M:
1. The challenger chooses random rSetup and generates CRS ← Setup(rSetup ). It also chooses a
bit b at random.
2. If b = 0, then the challenger behaves as follows:
(a) It chooses random s∗ , r∗ and computes tr∗ = π(s∗ , r∗ , m0 ).
(b) It gives the adversary (CRS, m0 , m1 , s∗ , r∗ , tr∗ ).
(a) It chooses random s∗ , r∗ and computes tr∗ ← π(s∗ , r∗ , m1 ).
(b) It sets s0 ← SFake(s∗ , m1 , m0 , tr∗ ; ρS ) for random ρS .
23
(c) It sets r0 ← RFake(r∗ , m1 , m0 , tr∗ ; ρR ) for random ρR .
(d) It gives the adversary (CRS, m0 , m1 , s0 , r0 , tr∗ ).
4. Adv outputs b0 and wins if b = b0 .
Next, we define off-the-record deniability. We define it for an arbitrary message space instead of bit encryption,
since having |M| > 2 allows for an extra case when plaintexts claimed by the sender, by the receiver, and the
real plaintext are three different strings (case b = 2 in the definition below).
Definition 2. Off-the-record deniable encryption in the CRS model. We say that a scheme is off-the-
record deniable, if it satisfies correctness as above and also has the following property.
Off-the-record deniability: No PPT adversary Adv wins with more than negligible advantage in the
following game, for any m0 , m1 , m2 ∈ M:
1. The challenger chooses random rSetup and generates CRS ← Setup(rSetup ). It also chooses random
b ∈ {0, 1, 2}.
2. If b = 0, then the challenger generates the following variables:
(a) The challenger chooses random s∗ , r∗ and computes tr∗ ← π(s∗ , r∗ , m0 );
(b) It sets r0 ← RFake(r∗ , m0 , m1 , tr∗ ; ρR ) for randomly chosen ρR .
(c) It gives the adversary (CRS, m0 , m1 , m2 , s∗ , r0 , tr∗ ).
(b) It sets s0 ← SFake(s∗ , m1 , m0 , tr∗ ; ρS ) for randomly chosen ρS .
(c) It gives the adversary (CRS, m0 , m1 , m2 , s0 , r∗ , tr∗ ).
(b) It sets s0 ← SFake(s∗ , m2 , m0 , tr∗ ; ρS ) for randomly chosen ρS .
(c) It sets r0 ← RFake(r∗ , m2 , m1 , tr∗ ; ρR ) for randomly chosen ρR .
(d) It gives the adversary (CRS, m0 , m1 , m2 , s0 , r0 , tr∗ ).
We say that an encryption scheme is bideniable (resp., off-the-record deniable) with (t, ε)-security, if the
distinguishing advantage of any any size-t adversary in the bideniability (resp., off-the-record deniability)
game is at most ε.
Single-execution security implies multi-execution security. In definitions 4 and 2, the CRS is global (i.e.,
non-programmable). These definitions do not involve simulation and the same set of programs is used
throughout. Furthermore, even though definitions 4 and 2 consider a single protocol execution, a simple
hybrid argument shows that security of a single execution implies security of arbitrarily polynomially many
executions with the same set of programs.19
19
We can change all executions from real to fake one by one, where the reduction from a single-execution security will generate
24
Definition 3. Public receiver deniability. A deniable scheme has public receiver-deniability if the receiver
faking algorithm RFake takes as input only the transcript tr and fake plaintext m0 (not true random coins of
the receiver r∗ and true plaintext m).
3.2 Deniability in The Oracle Access Model

In the oracle access model the algorithms P1, P2, P3, Dec, SFake, RFake are replaced by oracles. That
is, an interactive deniable encryption scheme π in the oracle access model consists of six oracles π =
(P1, P2, P3, Dec, SFake, RFake). As before, oracles P1, P3 and SFake are used by the sender, and oracles
P2, Dec and RFake are used by the receiver. As begfore, we let the transcript tr = π(s, r, m) of an execution
of the scheme on inputs m and random input s of the sender, and random input r of the receiver denote
the sequence of three messages sent in this execution. That is, π(s, r, m) = tr = (µ1 , µ2 , µ3 ), where
µ1 = P1(s, m), µ2 = P2(r, µ1 ), and µ3 = P3(s, m, µ1 , µ2 ).
The faking oracles have the following syntax: SFake(s, m, m0 , tr; ρ) expects to take a transcript tr along with
the true random coins s and true plaintext m, which were used to compute tr. It also needs the desired fake
plaintext m0 , and its own randomness ρ. RFake follows the same syntax except that it expects the receiver
randomness r instead of sender randomness s.
Deniable encryption in the oracle access model. For the oracle access model, we concentrate on plain
bideniability. As before, the definitions can be naturally extended to multi-bit plaintexts.
Definition 4. Bideniable bit encryption in the Oracle Access Model. π = (P1, P2, P3,
Dec, SFake, RFake) is a 3-message bideniable interactive encryption scheme for message space M = {0, 1},
if it satisfies the following correctness and bideniability properties:
• Correctness: For any m ∈ M Pr[m0 6= m : s ← {0, 1}|s| , r ← {0, 1}|r| , tr ← π(s, r, m), m0 ←
Dec(r, tr)] = 0. (Here the probability is taken over the initial random choices of the oracles and rhw
choices of s and r.
• Bideniability: No PPT adversary Adv wins with more than negligible advantage in the following
game, for any m0 , m1 ∈ M:
1. The challenger samples the six oracles and gives Adv access to them. It also chooses a bit b at
random.
(a) It chooses random s∗ , r∗ and computes tr∗ = π(s∗ , r∗ , m0 ).
(b) It gives the adversary (m0 , m1 , s∗ , r∗ , tr∗ ).
(a) It chooses random s∗ , r∗ and computes tr∗ ← π(s∗ , r∗ , m1 );
(b) s0 ← SFake(s∗ , m1 , m0 , tr∗ ; ρS ) and r0 ← RFake(r∗ , m1 , m0 , tr∗ ; ρR ), for randomly cho-
sen ρS , ρR .
(c) It gives the adversary (m0 , m1 , s0 , r0 , tr∗ ).
other executions on its own, since knowing the CRS (but not its generation randomness) suffices to run all programs.
25
4 Deniable Encryption in Oracle-Access model
In this section we construct and prove security of our deniable encryption scheme assuming that parties and
adversaries only have oracle access to the programs of deniable encryption.
We stress that our main result — deniable encryption in the CRS model described in section 6 — does not
use any results from this section and can be read independently. The goal of this section is to describe a
simplified construction with a relatively short proof of security, to help the reader verify the result.
Our scheme is described on fig. 8, and it assumes that all parties — senders, receivers, and adversaries —
have access to oracles described in fig. 9, fig. 10. These oracles compute messages of deniable encryption, as
well as compute fake random coins for parties.
Notation and primitives.
Let s and r denote thte randomness of the sender and the receiver, respectively, and let µ1 , µ2 , µ3 denote the
three messages of the protocol. P1, P2, P3, Dec, SFake, RFake are the oracles computing the corresponding
messages of deniable encryption, performing decryption, and faking coins for the sender and the receiver,
respectively. For instance, to compute the first message, the sender should query the oracle P1 on input
(s∗ , m) for uniformly chosen s∗ .
We now specify the syntax. P1(s, m) takes as input sender randomness s and plaintext m and outputs
the first message µ1 . P2(r, µ1 ) takes as input receiver randomness r and first message µ1 and outputs
the second message µ2 . P3(s, m, µ1 , µ2 ) takes as input sender randomness s, plaintext m, and protocol
messages µ1 , µ2 and outputs the last message µ3 . Dec(r, µ1 , µ2 , µ3 ) takes as input receiver randomness r
and protocol messages µ1 , µ2 , µ3 and outputs the plaintext m. SFake(s, m, m̂, µ1 , µ2 , µ3 ) takes as input
sender randomness s, true plaintext m, new (fake) plaintext m̂, and protocol messages µ1 , µ2 , µ3 and outputs
fake randomness s0 which makes µ1 , µ2 , µ3 look consistent with m̂. RFake(m̂, µ1 , µ2 , µ3 ) takes as input new
(fake) plaintext m̂ and protocol messages µ1 , µ2 , µ3 and outputs fake randomness r0 which makes µ1 , µ2 , µ3
look consistent with m̂.
Our oracles use hashes H1 , H2 , H3 and encryption schemes with keys KS , KR , K. We underline that these
primitives are “ideal”: that is, the description of each hash H1 , H2 , H3 is a table {(xi , yi )} specifying the
output yi for each input xi . The description of each key KS , KR , K is a table specifying the ciphertext ci for
each input xi ; all three encryption schemes are deterministic (that is, they only take the plaintext as input, and
do not sample any additional random coins.). All these primitives are ideal in the sense that all images of all
encryption schemes and hashes are chosen uniformly at random.
For convenience, we denote by S, R, M, H1 , H2 , H3 the image of sender-fake encryption scheme (with key
KS ), receiver-fake encryption scheme (with key KR ), the main encryption scheme (with key K), and hashes
H1 , H2 , H3 , respectively.
In our construction fake randomness is itself an encryption of several variables - e.g. fake sender randomness
s encrypts m, µ1 , µ2 , µ3 , `. Because of this, it is convenient to refer to a particular “field” of a decrypted
value, which we will denote, following programming languages notation, by DecKS (s).m, DecKS (s).µ1 ,
DecKS (s).µ2 , DecKS (s).µ3 , DecKS (s).`; similarly, we will be referring to different fields of µ3 by using
DecK (µ3 ).m, DecK (µ3 ).µ1 , DecK (µ3 ).µ2 , DecK (µ3 ).`.
The choice of parameters. We set T to be superpolynomial in the security parameter (e.g. T = λlog λ ). We
set the size of each ciphertext and hash image to be large enough so that the image of each encryption or hash
26
is sparse. In particular, let us set |µ1 | = |µ2 | = 2λ, |µ3 | = 7λ, |s| = |r| = 16λ, |`| = λ. Further, we make
the images size of H1 and H2 to be 2λ each. This means that H1 is a function from |s| + 1 bits to 2λ bits
(with image size 2λ ), H2 is a function from |µ1 | + |r| bits to 2λ bits (with image size 2λ ), H3 is a function
from λ bits to 2λ bits. This choice of parameters ensures that each encryption and hash have sufficiently
sparse images and therefore the probability of randomly chosen string to be in their image is negligible in λ20 .
Finally, note that the set S should be sparse enough so that T ∗ |S|/2|s| remains negligible (indeed, this is
true for our choice of parameters: the size of S is 2|m|+|µ1 |+|µ2 |+|µ3 |+|`| = 21+2λ+2λ+7λ+λ < 213λ , T < 2λ ,
and 2|s| = 216λ ).
Finally, we note that this choice of parameters also ensures correctness of encryption schemes with keys
K, KS , KR : namely, it ensures that for any fixed µ3 ∈ M, the probability over the choice of K that it has
more than one preimage is negligible (indeed, this probability is bounded by |M|2−|µ3 | < 2−λ ). The same
holds for any fixed s over the choice of key KS , and any fixed r over the choice of key KR .
4.1 Construction
The protocol is described in fig. 8. It simply instructs parties to run the programs P1, P2, P3, Dec to encrypt
and decrypt, and SFake, RFake to fake (described in fig. 9 and 10). Note that deniability of the receiver is
public, since the knowledge of randomness of the receiver is not required in order to run RFake.
We assume that a program outputs ⊥ if any of its underlying primitives outputs ⊥, except where it is explicitly
written otherwise. For instance, if a program tries to decrypt a ciphertext which is not in the image of the
corresponding encryption scheme, this program outputs ⊥.
4.2 Proof of correctness and security.

In short, correctness of the scheme follows from correctness of underlying ideal encryption and the fact that
the sets S and R of fake randomness are sparse (the latter is important because oracles do not perform correct
encryption / decryption operations when run on randomness from S, R, which parties may accidentally pick
as their random coins).
More concretely, recall that s∗ , chosen uniformly at random, belongs to set S only with negligible probability;
the same holds for r∗ and R. This means that, in the protocol execution for plaintext m and uniformly chosen
s∗ , r∗ , except with negligible probability, the transcript (µ1 ∗ , µ2 ∗ , µ3 ∗ ) will be generated as follows:
• µ1 ∗ = H1 (s∗ , m);
• µ2 ∗ = H2 (r∗ , µ1 ∗ );
• µ3 ∗ = EncK (m, µ1 ∗ , µ2 ∗ , 0),
and therefore Dec(r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ) will return the correct plaintext m via the main step.
To prove security of the scheme, we show that for any (potentially unbounded) adversary A which makes only
polynomial number of queries to the oracle, the distributions H0 and H11,7 are statistically indistinguishable,
20
The exact choice of parameters comes from the following: the purpose of setting |µ1 | = |µ2 | = 2λ is to make sure that the
images of hashes H1 , H2 are sparse enough (each hash H1 , H2 has 2λ different images). By setting |µ3 | = 7λ, we make sure
the set of valid ciphertexts µ3 under key K is also sparse (indeed, note that the size of the plaintext which is encrypted in µ3 is
|m| + |µ1 | + |µ2 | + |`| = 1 + 2λ + 2λ + λ < 6λ). Finally, by setting |s| = |r| = 16λ we make sure that the set of valid
ciphertexts under keys KS , KR is sparse as well: indeed, note that the size of plaintexts encrypted inside fake s, r is at most
|m| + |µ1 | + |µ2 | + |µ3 | + |`| + |H3 (ρ)| < 1 + 2λ + 2λ + 7λ + λ + 2λ < 15λ.
27
Programs: P1, P2, P3, Dec, SFake, RFake, described in fig. 9, fig. 10. These programs are only accessible
via oracle access.
Our interactive deniable encryption:

Inputs: plaintext m ∈ {0, 1} of the sender.
1. Message 1: The sender chooses random s∗ , computes µ1 ∗ ← P1(s∗ , m) and sends µ1 ∗ to the receiver.
2. Message 2: The receiver chooses random r∗ , computes µ2 ∗ ← P2(r∗ , µ1 ∗ ) and sends µ2 ∗ to the
sender.
3. Message 3: The sender computes µ3 ∗ ← P3(s∗ , m, µ1 ∗ , µ2 ∗ ) and sends µ3 ∗ to the receiver.
4. The receiver runs m0 ← Dec(r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ).
Sender Coercion:
Inputs: real plaintext m ∈ {0, 1}, fake plaintext m̂ ∈ {0, 1}, real random coins s∗ of the sender, and the
protocol transcript µ1 ∗ , µ2 ∗ , µ3 ∗ .
1. Upon coercion, the sender computes fake randomness s0 ← SFake(s∗ , m, m̂, µ1 ∗ , µ2 ∗ , µ3 ∗ ).
Receiver Coercion:
Inputs: fake plaintext m̂ ∈ {0, 1} and the protocol transcript µ1 ∗ , µ2 ∗ , µ3 ∗ .
1. Upon coercion, the receiver chooses random ρ∗ and computes fake randomness r0 ←
RFake(m̂, µ1 ∗ , µ2 ∗ , µ3 ∗ ; ρ∗ ).
Figure 8: Our interactive deniable encryption scheme.
where H0 corresponds to the output of the adversary which sees the real execution of the protocol for plaintext
m0 , together with real randomness s∗ , r∗ , and H11,7 corresponds to the output of the adversary which sees
the execution of the protocol for plaintext m1 , together with fake randomness s0 , r0 which makes it look
consistent with m0 . To prove this, we consider intermediate hybrid distributions {Hi } and show that for each
i the distributions Hi and Hi−1 are statistically indistinguishable. For this proof in the oracle-access model,
we will consider the case m0 6= m1 ∈ {0, 1}.
Below we describe each hybrid experiment. For convenience, we mark the changes from the previous
experiment in red.
By writing AO (x) we mean the output of adversary A on input x, where the adversary has oracle access to
algorithm O.
• H0 : AP1,P2,P3,Dec,SFake,RFake (m0 , m1 , s∗ , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where s∗ , r∗ are chosen uniformly at
random, µ1 ∗ = P1(s∗ , m0 ), µ2 ∗ = P2(r∗ , µ1 ∗ ), µ3 ∗ = P3(s∗ , m0 , µ1 ∗ , µ2 ∗ ).
This experiment corresponds to the adversary observing the execution of the protocol with plaintext
m0 , who is given true randomness s∗ , r∗ .
• H1 : AP1,P2,P3,Dec,SFake,RFake (m0 , m1 , s∗ , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where s∗ , r∗ are chosen uniformly at
random, µ1 ∗ = H1 (s∗ , m0 ), µ2 ∗ = H2 (r∗ , µ1 ∗ ), µ3 ∗ = EncK (m0 , µ1 ∗ , µ2 ∗ , 0). If s∗ ∈ S or r∗ ∈ R,
the experiment aborts.
This experiment is similar to the previous one, except that it aborts if s∗ ∈ S or r∗ ∈ R, which happens
with negligible probability. Thus, this experiment is statistically close to the previous one.
Since s∗ 6∈ S, we explicitly write µ1 ∗ = H1 (s∗ , m0 ), instead of µ1 ∗ = P1(s∗ , m0 ); similar with
28
Oracles P1, P3, SFake.
Oracle P1(s, m)
Inputs: sender randomness s, plaintext m.
Hardwired values: key KS of sender-fake encryption scheme, hash H1 with sparse image.
1. Trapdoor step:
(a) If s ∈ S and DecKS (s).m = m, then return DecKS (s).µ1 ;
2. Main step:
(a) Else return H1 (s, m).
Oracle P3(s, m, µ1 , µ2 )
Inputs: sender randomness s, plaintext m, the first and the second messages µ1 , µ2 in the protocol.
Hardwired values: key KS of sender-fake encryption scheme, key K of main encryption scheme.
1. Validity check:
(a) If P1(s, m) 6= µ1 then ⊥;
2. Trapdoor step:
(a) If s ∈ S and (DecKS (s).m, DecKS (s).µ1 , DecKS (s).µ2 ) = (m, µ1 , µ2 ) then return
DecKS (s).µ3 ;
3. Mixed input step:
(a) Else if s ∈ S and (DecKS (s).m, DecKS (s).µ1 ) = (m, µ1 ) then return
EncK (m, µ1 , µ2 , DecKS (s).`);
4. Main step:
(a) Else return EncK (m, µ1 , µ2 , 0).
Oracle SFake(s, m, m̂, µ1 , µ2 , µ3 )
Inputs: sender randomness s, real plaintext m, fake plaintext m̂, protocol transcript µ1 , µ2 , µ3 .
Hardwired values: key KS of sender-fake encryption scheme, upper bound T .
1. Validity check:
(a) If P1(s, m) 6= µ1 then ⊥;
2. Trapdoor step:
(a) If s ∈ S and (DecKS (s).m, DecKS (s).µ1 ) = (m, µ1 ) then
i. If DecKS (s).` = T then ⊥;
ii. Else return EncKS (m̂, µ1 , µ2 , µ3 , DecKS (s).` + 1).
3. Main step:
(a) Else return EncKS (m̂, µ1 , µ2 , µ3 , 1).
Figure 9: Programs P1, P3, SFake. S, R, M, H1 , H2 , H3 denote the image of sender-fake encryption
scheme (with key KS ), receiver-fake encryption scheme (with key KR ), the main encryption scheme (with
key K), and hashes H1 , H2 , H3 , respectively.
29
Oracles P2, Dec, RFake.
Oracle P2(r, µ1 )
Inputs: receiver randomness r, the first message µ1 in the protocol.
Hardwired values: key KR of receiver-fake encryption scheme, hash H2 with sparse image.
1. Trapdoor step:
(a) If r ∈ R and DecKR (r).µ1 = µ1 , then return DecKR (r).µ2 ;
2. Main step:
(a) Return H2 (r, µ1 ).
Oracle Dec(r, µ1 , µ2 , µ3 )
Inputs: receiver randomness r, protocol transcript µ1 , µ2 , µ3 .
Hardwired values: key KR of receiver-fake encryption scheme, key K of the main encryption scheme,
upper bound T .
1. Validity check:
(a) If P2(r, µ1 ) 6= µ2 then ⊥;
2. Trapdoor step:
(a) If r ∈ R and (DecKR (r).µ1 , DecKR (r).µ2 , DecKR (r).µ3 ) = (µ1 , µ2 , µ3 ) then return
DecKR (r).m;
(a) If r ∈ R and (DecKR (r).µ1 , DecKR (r).µ2 ) = (µ1 , µ2 ) then
i. If µ3 ∈ M and (µ1 , µ2 ) = (DecK (µ3 ).µ1 , DecK (µ3 ).µ2 ) and DecKR (r).` < DecK (µ3 ).`
then return DecK (µ3 ).m;
ii. Else ⊥.
4. Main step:
(a) If µ3 ∈ M and (DecK (µ3 ).µ1 , DecK (µ3 ).µ2 ) = (µ1 , µ2 ) then return DecK (µ3 ).m;
(b) Else ⊥.
Oracle RFake(m̂, µ1 , µ2 , µ3 ; ρ)
Inputs: fake plaintext m̂, protocol transcript µ1 , µ2 , µ3 , random coins ρ.
function H3 with a sparse image.
1. If µ3 ∈ M and DecK (µ3 ).µ1 = µ1 and DecK (µ3 ).µ2 = µ2 then return
EncKR (m̂, µ1 , µ2 , µ3 , DecK (µ3 ).`, H3 (ρ));
2. Else ⊥.
Figure 10: Oracles P2, Dec, RFake. S, R, M, H1 , H2 , H3 denote the image of sender-fake encryption
scheme (with key KS ), receiver-fake encryption scheme (with key KR ), the main encryption scheme (with
key K), and hashes H1 , H2 , H3 , respectively.
30
µ2 ∗ , µ3 ∗ .
• H2 : AP1,P2,P3,Dec,SFake,RFake (m0 , m1 , s0 , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where s∗ , r∗ are chosen uniformly
at random, µ1 ∗ = H1 (s∗ , m0 ), µ2 ∗ = H2 (r∗ , µ1 ∗ ), µ3 ∗ = EncK (m0 , µ1 ∗ , µ2 ∗ , 0), and s0 =
EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0). If s∗ ∈ S or r∗ ∈ R, the experiment aborts.
This experiment is similar to the previous one, except that the adversary receives sender randomness s0
which comes from a fake set S, instead of true s∗ . Note that s0 = EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0), i.e. s0
so far has level 0, and contains the fake plaintext m0 which is the same as the real plaintext.
We argue that this experiment is identical to the previous one. Roughly, this is because all oracles,
given s∗ or s0 as input, output either the same values or identically distributed ones. Indeed, lets analyze
how s∗ and s0 are used within the oracles:
1. Oracle P1 contains the following entries which include s∗ or s0 :
(a) Entries s∗ , m0 → µ1 ∗ (in the main step) and s0 , m0 → µ1 ∗ (in the trapdoor step),
(b) Entries s∗ , m1 → H1 (s∗ , m1 ) and s0 , m1 → H1 (s0 , m1 ) (both in the main step).
2. Oracle P3 contains the following entries which include s∗ or s0 :
(a) Entries s∗ , m0 , µ1 ∗ , µ2 ∗ → µ3 ∗ (in the main step) and s0 , m0 , µ1 ∗ , µ2 ∗ → µ3 ∗ (in the
trapdoor step),
(b) For every string µ2 6= µ2 ∗ of the correct length, there are entries
s , m0 , µ1 , µ2 → EncK (m, µ1 , µ2 , 0) (in the main step) and s0 , m0 , µ1 ∗ , µ2 →
∗ ∗ ∗
EncK (m, µ1 ∗ , µ2 , DecKS (s0 ).`) = EncK (m, µ1 ∗ , µ2 , 0) (in the mixed input step)21 ,
(c) For every string (m, µ1 , µ2 ) of the correct length, such that µ1 = H1 (s∗ , m), there is an
entry s∗ , m, µ1 , µ2 → EncK (m, µ1 , µ2 , 0) (in the main step). Since these entries for the
case (m, µ1 ) = (m0 , µ1 ∗ ) were already accounted for in steps 1 and 2, here we consider
the case (m, µ1 ) 6= (m0 , µ1 ∗ ). For all remaining strings (m, µ1 , µ2 ) there is an entry
s∗ , m, µ1 , µ2 → ⊥ (in the validity check).
In addition, for every string (m, µ1 , µ2 ) of the correct length, such that µ1 = H1 (s0 , m)
and (m, µ1 ) 6= (m0 , µ1 ∗ )22 , there is an entry s0 , m, µ1 , µ2 → EncK (m, µ1 , µ2 , 0) (in the
main step). For all remaining strings (m, µ1 , µ2 ) there is an entry s∗ , m, µ1 , µ2 → ⊥ (in the
validity check).
3. Oracle SFake contains the following entries which include s∗ or s0 :
(a) For every string (m̂, µ2 , µ3 ) of the correct length, there is an entry s∗ , m0 , m̂, µ1 ∗ , µ2 , µ3 →
EncKS (m̂, µ1 ∗ , µ2 , µ3 , 1) (in the main step), and an entry s0 , m0 , m̂, µ1 ∗ , µ2 , µ3 →
EncKS (m̂, µ1 ∗ , µ2 , µ3 , 1) (in the trapdoor step)23 .
(b) For every string (m, m̂, µ1 , µ2 , µ3 ) of the correct length, such that µ1 = H1 (s∗ , m), there
is an entry s∗ , m, m̂, µ1 , µ2 , µ3 → EncKS (m̂, µ1 , µ2 , µ3 , 1) (in the main step). Since these
entries for the case (m, µ1 ) = (m0 , µ1 ∗ ) were already accounted for in step 1, here we
consider the case (m, µ1 ) 6= (m0 , µ1 ∗ ). For all remaining strings (m, m̂, µ1 , µ2 , µ3 ) there
21
Indeed, note that DecKS (s0 ).` = 0.
22
Indeed, if (m, µ1 ) = (m0 , µ1 ∗ ), then P3 on input s0 uses either trapdoor step or mixed input step, but never the main step.
23
Indeed, note that DecKS (s0 ).` + 1 = 1
31
is an entry s∗ , m, m̂, µ1 , µ2 , µ3 → ⊥ (in the validity check).
In addition, for every string (m, m̂, µ1 , µ2 , µ3 ) of the correct length, such that µ1 =
H1 (s0 , m) and (m, µ1 ) 6= (m0 , µ1 ∗ )24 , there is an entry s0 , m, m̂, µ1 , µ2 , µ3 →
EncKS (m̂, µ1 , µ2 , µ3 , 1) (in the main step). For all remaining strings (m, m̂, µ1 , µ2 , µ3 )
there is an entry s0 , m, m̂, µ1 , µ2 , µ3 → ⊥ (in the validity check).
Note that in all cases s∗ and s0 participate either in identical entries (such as cases 1(a), 2(a), 2(b), 3(a))
or in entries which have the same distribution (cases 1(b), 2(c), 3(b)), and recall that s∗ and s0 are
themselves uniformly chosen strings. Therefore this experiment is identical to the previous one.
• H3 : AP1,P2,P3,Dec,SFake,RFake (m0 , m1 , s0 , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where s∗ , r∗ are chosen uniformly
at random, µ1 ∗ = H1 (s∗ , m0 ), µ2 ∗ = H2 (r∗ , µ1 ∗ ), µ3 ∗ = EncK (m0 , µ1 ∗ , µ2 ∗ , 0), and s0 =
EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0). If s∗ ∈ S or r∗ ∈ R, the experiment aborts. If the adversary queries any
oracle on any input containing s∗ , the experiment aborts.
This experiment is similar to the previous one, except that it aborts if the adversary ever issues a query
containing s∗ . Note that s∗ is a uniformly random variable which is independent of the oracles’ output;
thus the adversary could query s∗ only by guessing it, which happens with negligible probability.
Therefore, this experiment is statistically close to the previous one.
• H4 : AP1,P2,P3,Dec,SFake,RFake (m0 , m1 , s0 , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where r∗ is chosen uniformly at ran-
dom, µ1 ∗ is chosen uniformly at random independently of H1 , µ2 ∗ = H2 (r∗ , µ1 ∗ ), µ3 ∗ =
EncK (m0 , µ1 ∗ , µ2 ∗ , 0), and s0 = EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0). If r∗ ∈ R or µ1 ∗ ∈ H1 , the ex-
periment aborts.
This experiment is similar to the previous one, except that µ1 ∗ which is given to the adversary is chosen
uniformly at random, instead of being set to its proper value H1 (s∗ , m0 ) (in particular, µ1 ∗ is different
from the value H1 (s∗ , m0 ) which is stored by the oracles). Further, we also change the experiment to
abort if uniformly random µ1 ∗ is in the image H1 of H1 , which happens with negligible probability.
Finally, note that s∗ is not part of the experiment anymore and there is no need to generate it.
Note that the only way for the adversary to check if the oracle stores µ1 ∗ or H1 (s∗ , m0 ) is to query it
on some preimage (s, m) of H1 (s∗ , m0 ), which can only happen with negligible probability. Therefore
this experiment is statistically close to the previous one.
EncK (m0 , µ1 ∗ , µ2 ∗ , 0), and s0 = EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0). If r∗ ∈ R or µ1 ∗ ∈ H1 , the
experiment
n aborts. If the adversary queries any oracle on any input o containing s ∈ S00 , where
S00 = EncKs (m̂, µ1 , µ2 , µ3 , 0) : (m̂, µ1 , µ2 , µ3 ) ∈ {0, 1}1+|µ1 |+|µ2 |+|µ3 | \ s0 , the experiment aborts.
This experiment is similar to the previous one except that it aborts if the adversary ever makes a query
containing sender randomness of a fake format with level 0 (except s0 , which is given to the adversary).
Note that the oracles’ outputs are independent of S00 (in particular, note that neither oracle outputs
fake sender randomness with level 0: indeed, in the output of SFake levels start with 1), therefore the
adversary cannot find such s ∈ S00 except for guessing it, which happens with negligible probability.
24
Indeed, if (m, µ1 ) = (m0 , µ1 ∗ ), then SFake on input s0 uses trapdoor step, but never the main step.
32
Therefore this experiment is statistically close to the previous one.
EncK (m0 , µ1 ∗ , µ2 ∗ , 0), and s0 = EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0). If r∗ ∈ R or µ1 ∗ ∈ H1 , the
experiment
n aborts. If the adversary queries any oracle on any input o containing s ∈ S00 , where
S00 = EncKs (m̂, µ1 , µ2 , µ3 , 0) : (m̂, µ1 , µ2 , µ3 ) ∈ {0, 1}1+|µ1 |+|µ2 |+|µ3 | \ s0 , the experiment aborts.
If the adversary queries any oracle on any input containing µ3 ∗ = EncK (m1 , µ1 ∗ , µ2 ∗ , 0) the experi-
ment aborts.
This experiment is similar to the previous one except that it aborts if the adversary ever queries any
oracle on µ3 ∗ = EncK (m1 , µ1 ∗ , µ2 ∗ , 0) (this ciphertext can be thought of as “complement” of the
challenge ciphertext µ3 ∗ = EncK (m0 , µ1 ∗ , µ2 ∗ , 0) since it encrypts the same µ1 ∗ , µ2 ∗ , 0, but the
opposite bit m1 ).
We argue that µ3 ∗ can only be found by the adversary by guessing certain variables, with negligible
chance of success. First, we will give some intuition: we claim that the adversary can find µ3 ∗ only by
doing one of the following:
1. Guessing µ3 ∗ ;
2. Forcing P3 to output µ3 ∗ via trapdoor step, by running P3 on some fake s which encrypts µ3 ∗ ;
3. Forcing P3 to output µ3 ∗ via mixed input step, by running P3 on a certain fake s 6= s0 with level
0.
Intuitively, the adversary’s chance of succeeding in case one is negligible due to sparseness of the
encryption scheme; in the second case, to generate such an s, the adversary would have to know µ3 ∗
to begin with; and in the third case the adversary would have to find fake s 6= s0 with level 0, which
is not an output of any oracle and therefore it can only be guessed by the adversary with negligible
probability.
Now we give a formal argument. We claim that the ciphertext µ3 ∗ = EncK (m1 , µ1 ∗ , µ2 ∗ , 0) can
be removed from the description of oracle P3, without changing the experiment. First, recall that
µ1 ∗ 6∈ H1 (otherwise the experiment aborts). This means that the only way to satisfy the validity
check in P3 with µ1 ∗ is to provide P3 with an input (s, m, µ1 ∗ , µ2 ) such that DecKS (s).m = m,
DecKS (s).µ1 = µ1 ∗ . However, in this case oracle P3 never executes the main step (either trapdoor
step or mixed input step will be executed). Therefore we can remove the description of µ3 ∗ from K in
the main step.
Second, we claim that we can remove the description of µ3 ∗ from K in the mixed input step as
well. Indeed, note that µ3 ∗ is an encryption of level 0 (together with other values). Note that
the mixed input step copies the level DecKS (s).` into the ciphertext EncK (m, µ1 , µ2 , DecKS (s).`);
this means that the only way to force the mixed input step to encrypt level 0 is to query P3 on
some s ∈ S such that DecKS (s).` = 0. However, in our experiment the adversary never queries
s ∈ S00 (otherwise the experiment aborts), therefore the only level-0 s which can be queried is
s0 = EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0). Finally, for P3 to output µ3 ∗ = EncK (m1 , µ1 ∗ , µ2 ∗ , 0) on inputs
s0 , m, µ1 , µ2 via mixed input step, its inputs (m, µ1 , µ2 ) should be set to (m1 , µ1 ∗ , µ2 ∗ ). However,
inputs (s0 , m1 , µ1 ∗ , µ2 ∗ ) to oracle P3 will not pass the validity check, since P1(s0 , m1 ) 6= µ1 ∗ (indeed,
µ1 ∗ 6∈ H1 , and DecKS (s).m = m0 6= m1 , thus neither trapdoor step nor main step of P1 results in
33
µ1 ∗ ).
Third, we note that, formally speaking, the string µ3 ∗ is present in the trapdoor step of P3, since this
step outputs DecKS (s).µ3 , which could happen to be µ3 ∗ . However, this step contains the description
of all binary strings of length |µ3 |, since any such string could be equal to DecKS (s).µ3 for some s. In
other words, the description of trapdoor step is independent of µ3 ∗ .
Therefore we can remove the description of µ3 ∗ from P3 without changing the experiment. Finally, we
note that all other oracles’ outputs are independent of µ3 ∗ . Therefore the probability that the adversary
queries µ3 ∗ is at most the probability of guessing it, which is negligible.
Thus, this experiment is statistically close to the previous one.
• H7 : AP1,P2,P3,Dec,SFake,RFake (m0 , m1 , s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where r∗ is chosen uniformly at ran-
EncK (m0 , µ1 ∗ , µ2 ∗ , 0), s0 = EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0), r0 = EncKR (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0, ρ̂∗ )
for uniformly chosen ρ̂∗ . If r∗ ∈ R or µ1 ∗ ∈ H1 or ρ̂∗ ∈ H3 , the experiment
aborts.
n If the adversary queries any oracle on any input containing o s ∈ S00 , where S00 =
EncKs (m̂, µ1 , µ2 , µ3 , 0) : (m̂, µ1 , µ2 , µ3 ) ∈ {0, 1}1+|µ1 |+|µ2 |+|µ3 | \ s0 , the experiment aborts. If
the adversary queries any oracle on any input containing µ3 ∗ = EncK (m1 , µ1 ∗ , µ2 ∗ , 0) the experiment
aborts.
This experiment is similar to the previous one, except that the adversary receives fake r0 and not the
real r∗ as the randomness of the receiver.
We argue that this experiment is identical to the previous one. Roughly, this is because all oracles,
given r∗ or r0 as input, output either the same values or identically distributed ones; while this is not
true for some bad inputs, our experiment aborts if the adversary ever queries such an input. Indeed, lets
analyze how r∗ and r0 are used within the oracles:
1. Oracle P2 contains the following entries which include r∗ or r0 :
(a) Entries r∗ , µ1 ∗ → µ2 ∗ (in the main step) and r0 , µ1 ∗ → µ2 ∗ (in the trapdoor step),
(b) For all µ1 6= µ1 ∗ , entries r∗ , µ1 → H2 (r∗ , µ1 ) and r0 , µ1 → H2 (r0 , µ1 ) (both in the main
step).
2. Oracle Dec contains the following entries which include r∗ or r0 :
(a) For every string µ3 = EncK (m, µ1 ∗ , µ2 ∗ , `) such that m ∈ {0, 1}, ` ∈ [0, . . . , T ], there is
an entry r∗ , µ1 ∗ , µ2 ∗ , µ3 → m (in the main step).
For every string µ3 = EncK (m, µ1 ∗ , µ2 ∗ , `) such that m ∈ {0, 1}, ` ∈ [1, . . . , T ], there is
an entry r0 , µ1 ∗ , µ2 ∗ , µ3 → m (in the mixed input step).
Note that entries for r0 do not contain entries for µ3 with level ` = 0. In particular, so far we
listed two entries for r∗ which r0 doesn’t have:
i. r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ → m0 , where µ3 ∗ = EncK (m0 , µ1 ∗ , µ2 ∗ , 0)
ii. r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ → m1 , where µ3 ∗ = EncK (m1 , µ1 ∗ , µ2 ∗ , 0).
However, one of these entries for r0 (r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ → m0 ) appears in the trapdoor
step. The other entry however is different from r∗ -entry: indeed, while r∗ -entry says
34
r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ → m1 , r0 -entry says r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ → ⊥ (in the mixed input step), since
the condition DecKR (r).` < DecK (µ3 ).` is violated due to both levels being 0. However,
our experiment aborts if the adversary ever queries any oracle on input µ3 ∗ , and therefore
the fact that Dec outputs different output on input r0 or r∗ doesn’t change the distribution of
the experiment, since such “differing input” is not queried by the adversary.
(b) For every string (µ1 , µ2 , µ3 ) of the correct length, such that µ2 = H2 (r∗ , µ1 ) and µ3 =
EncK (m, µ1 , µ2 , `) for m ∈ {0, 1}, ` ∈ [0, . . . , T ], there is an entry r∗ , µ1 , µ2 , µ3 → m
(in the main step). Since these entries for the case (µ1 , µ2 ) = (µ1 ∗ , µ2 ∗ ) were already
accounted for in steps 1 and 2, here we consider the case (µ1 , µ2 ) 6= (µ1 ∗ , µ2 ∗ ). For all
strings (µ1 , µ2 , µ3 ) which are not already considered, there is an entry r∗ , µ1 , µ2 , µ3 → ⊥.
For every string (µ1 , µ2 , µ3 ) of the correct length, such that µ2 = H2 (r0 , µ1 ) and µ3 =
EncK (m, µ1 , µ2 , `) for m ∈ {0, 1}, ` ∈ [0, . . . , T ], there is an entry r0 , µ1 , µ2 , µ3 → m (in
the main step). (Note that in this case (µ1 , µ2 ) 6= (µ1 ∗ , µ2 ∗ ), since µ2 6= H2 (r0 , µ1 )) For all
strings (µ1 , µ2 , µ3 ) which are not already considered, there is an entry r0 , µ1 , µ2 , µ3 → ⊥.
3. Oracle RFake doesn’t r as input.
Note that in all cases r∗ and r0 participate either in identical entries (such as case 1(a)) or in identically
distributed ones (cases 2(a), 2(b)), and recall that r∗ and r0 are themselves uniformly chosen strings.
Therefore this experiment is identical to the previous one.
• H8 : AP1,P2,P3,Dec,SFake,RFake (m0 , m1 , s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where µ1 ∗ is chosen uniformly at ran-
dom independently of H1 , µ2 ∗ is chosen uniformly at random independently of H2 , µ3 ∗ =
for uniformly chosen ρ̂∗ . If µ1 ∗ ∈ H1 or µ2 ∗ ∈ H2 or ρ̂∗ ∈ H3 , the experiment
aborts.
n If the adversary queries any oracle on any input containing o s ∈ S00 , where S00 =
EncKs (m̂, µ1 , µ2 , µ3 , 0) : (m̂, µ1 , µ2 , µ3 ) ∈ {0, 1}1+|µ1 |+|µ2 |+|µ3 | \ s0 , the experiment aborts. If
aborts.
This experiment is similar to the previous one except that µ2 ∗ is chosen uniformly at random, indepen-
dently of the value H2 (r∗ , µ1 ∗ ). In addition, r∗ is now not part of the experiment and doesn’t have to
be generated. Further, we also make the experiment abort if uniformly random µ2 ∗ is in the image H2
of H2 , which happens with negligible probability.
Note that the only way for the adversary to check if the oracle stores µ2 ∗ or H2 (r∗ , µ1 ∗ ) is to query it on
some preimage (r, µ1 ) of H2 (r∗ , µ1 ∗ ), which can only happen with negligible probability. Therefore
this experiment is statistically close to the previous one.
• H9 : AP1,P2,P3,Dec,SFake,RFake (m0 , m1 , s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where µ1 ∗ is chosen uni-
formly at random independently of H1 , µ2 ∗ is chosen uniformly at random indepen-
dently of H2 , µ3 ∗ = EncK (m1 , µ1 ∗ , µ2 ∗ , 0), s0 = EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0), r0 =
EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0, ρ̂∗ ) for uniformly chosen ρ̂∗ . If µ1 ∗ ∈ H1 or µ2 ∗ ∈ H2 or
ρ̂∗ ∈ H3 , thenexperiment aborts. If the adversary queries any oracle on any input 0
o containing s ∈ S0 ,
where S00 = EncKs (m̂, µ1 , µ2 , µ3 , 0) : (m̂, µ1 , µ2 , µ3 ) ∈ {0, 1}1+|µ1 |+|µ2 |+|µ3 | \ s0 , the experiment
aborts. If the adversary queries any oracle on any input containing µ3 ∗ = EncK (m0 , µ1 ∗ , µ2 ∗ , 0) the
experiment aborts.
35
In this experiment we switch the roles of µ3 ∗ and µ3 ∗ : that is, we give the adversary µ3 ∗ =
EncK (m1 , µ1 ∗ , µ2 ∗ , 0) encrypting m1 , instead of µ3 ∗ = EncK (m0 , µ1 ∗ , µ2 ∗ , 0) encrypting m0 . Next,
we use µ3 ∗ instead of µ3 ∗ to generate fake s0 , r0 . Next, we make the experiment abort if the adversary
queries any input containing µ3 ∗ = EncK (m0 , µ1 ∗ , µ2 ∗ , 0), instead of µ3 ∗ = EncK (m1 , µ1 ∗ , µ2 ∗ , 0)
as before.
We claim that this experiment is identical to the previous one. Let us analyze how µ3 ∗ and µ3 ∗ are
used in the programs:
1. Program P3:
(a) In the trapdoor step, for every entry of the form (s, m, µ1 , µ2 ) → µ3 ∗ , there is an entry
(s, m, µ1 , µ2 ) → µ3 ∗ (and vice versa), where s and s are such that DecKS (s).µ3 = µ3 ∗ ,
DecKS (s).µ3 = µ3 ∗ , and all other fields of s and s are the same.
(b) In the mixed input step, we can remove all entries containing µ3 ∗ , µ3 ∗ , without changing the
experiment. This is because of the following: in order for P3 to output µ3 ∗ or µ3 ∗ via mixed
input step, it should be run on inputs (s, m, µ1 ∗ , µ2 ∗ ) for some s, m such that s ∈ S and s
has level 0. Recall that our experiment aborts if the adversary queries any level-0 s except
for s0 . Finally, in order for P3(s0 , m, µ1 ∗ , µ2 ∗ ) to output non-⊥ on input s0 , m should be
equal to m0 to pass the validity check, in which case P3 uses the trapdoor step (and outputs
µ3 ∗ ); in particular, doesn’t use the mixed input step.
(c) Finally, in the main step we can also remove all entries containing µ3 ∗ , µ3 ∗ without changing
the experiment. Indeed, since µ1 ∗ 6∈ H1 , they only way to pass the the validity check in P3
with µ1 ∗ is to give it some s ∈ S , which forces P3 to execute either trapdoor step or mixed
input step.
2. Program SFake has the same set of entries for all possible strings µ3 of proper length;
3. Program Dec:
(a) In the trapdoor step, for every entry of the form (r, µ1 , µ2 , µ3 ∗ ) → m, there is an entry
(r, µ1 , µ2 , µ3 ∗ ) → m (and vice versa), where r and r are such that DecKR (r).µ3 = µ3 ∗ ,
DecKR (r).µ3 = µ3 ∗ , and all other fields of r and r are the same.
(b) In the mixed input step, we can remove all entries containing µ3 ∗ , µ3 ∗ , without changing the
experiment. This is because of the following: in order for Dec to output non-⊥ via mixed
input step, the condition DecKR (r).` < DecK (µ3 ).` should hold. However, both µ3 ∗ and
µ3 ∗ have level 0, therefore there doesn’t exist r which satisfies this consition.
(c) Finally, in the main step we can remove all entries containing µ3 ∗ , µ3 ∗ , without changing
the experiment, since µ2 ∗ 6∈ H2 , and therefore, if the input passes the the validity check with
µ2 ∗ , it must be that r ∈ R, which forces Dec to execute either trapdoor step or mixed input
step.
4. Program RFake has the same set of entries for strings µ3 ∗ and µ3 ∗ , since the only information
from µ3 used by RFake is its level, which is the same (0) in µ3 ∗ and µ3 ∗ .
To conclude the argument, it remains to note that other programs do not use µ3 ∗ nor µ3 ∗ , and that in
both experiments 8 and 9 fake randomness of the sender and the receiver corresponds to the claimed
third message: that is, in experiment 8 s0 and r0 are both generated using µ3 ∗ , and in experiment 9 s0
36
and r0 are both generated using µ3 ∗ . Thus, this experiment is identical to the previous one.
• H11,1 : AP11 ,P2,P31 ,Dec,SFake1 ,RFake (m0 , m1 , s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where µ1 ∗ is chosen uniformly at
random independently of H1 , µ2 ∗ is chosen uniformly at random independently of H2 , µ3 ∗ =
for uniformly chosen ρ̂∗ . If µ1 ∗ ∈ H1 or µ2 ∗ ∈ H2 or ρ̂∗ ∈ H3 , the exper-
0
iment aborts. nIf the adversary queries any oracle on any input containing o s ∈ S0 ∪ S1 ,
where S0 = EncKs (m̂, µ1 , µ2 , µ3 , 0) : (m, µ1 , µ2 , µ3 ) ∈ {0, 1}1+|µ1 |+|µ2 |+|µ3 | , and S10 =
n o
EncKs (m̂, µ1 ∗ , µ2 , µ3 , 1) : (m, µ2 , µ3 ) ∈ {0, 1}1+|µ2 |+|µ3 | \ s0 , the experiment aborts. If the ad-
versary queries any oracle on any input containing µ3 ∗ = EncK (m0 , µ1 ∗ , µ2 ∗ , 0) the experiment
aborts.
In this experiment we change the encryption table of the key KS and adjust the code of the programs
of the sender, as shown on fig. 13, to preserve the distribution of the experiment. (For convenience
of verification, we also rewrote the code of the original programs of the sender but made the bound
on ` explicit on fig. 11). In addition, we change s0 from s0 = EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0) to
s0 = EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 1), and we change the set (which aborts the experiment when being
queried by the adversary) from S00 to S0 ∪ S10 .
We now describe the changes in detail. First, we change the key KS of a sender-fake encryption scheme
as follows. Recall that key KS is a table of all plaintext-ciphertext pairs, i.e. a table containing entries
of the form s ↔ (m, µ1 , µ2 , µ3 , `) for all strings s, m, µ1 , µ2 , µ3 of the proper length and ` ∈ [0, T ].
In this experiment we replace each entry where µ1 = µ1 ∗ with another entry: that is, for each entry of
the form s ↔ (m, µ1 ∗ , µ2 , µ3 , `) we replace it with another entry s ↔ (m, µ1 ∗ , µ2 , µ3 , ` + 1), thus
incrementing by 1 the value of level in some ciphertexts. In particular, the set of levels for which
encryptions exist changes to [1, T + 1] from [0, T ] for µ1 = µ1 ∗ . Note that this change affects the
challenge s0 , which is switched from EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0) to EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 1).
Second, we change the code of the programs so that they subtract 1 from the level of affected ciphertexts
s, before using it, thus nullifying the change from the above and preserving the distribution. The
resulting code is presented on fig. 13, and the changes are highlighted in red. Below we list the
changes:
– In the mixed input step of program P3, we consider the cases µ1 = µ1 ∗ and µ1 6= µ1 ∗ separately.
For the case µ1 6= µ1 ∗ the code remains unchanged. For the case µ1 = µ1 ∗ , the program checks
that the level in s is within [1, T + 1] (instead of [0, T ]), and the program outputs an encryption
of DecKS (s).` − 1 instead of DecKS (s).`.
– In the trapdoor step of program SFake, we consider the cases µ1 = µ1 ∗ and µ1 6= µ1 ∗ separately.
that the level in s is within [1, T ] (instead of [0, T − 1]).
– In the main step of program SFake, we do not need to make any changes to the program. Recall
that the experiment aborts if µ1 ∗ ∈ H1 , and therefore the main step of SFake cannot be triggered
on input µ1 ∗ . As a result, the main step of SFake never needs to encrypt µ1 ∗ and is therefore not
affected by our change of shifting the levels by 1.
Due to adjusted code, this experiment is identical to the previous one.
37
• H11,2 : AP12 ,P22 ,P32 ,Dec2 ,SFake2 ,RFake2 (m0 , m1 , s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where µ1 ∗ is chosen uniformly
at random independently of H1 , µ2 ∗ is chosen uniformly at random independently of H2 , µ3 ∗ =
for uniformly chosen ρ̂∗ . If µ1 ∗ ∈ H1 or µ2 ∗ ∈ H2 or ρ̂∗ ∈ H3 , the experi-
ment aborts. If nthe adversary queries any oracle on any input containing os ∈ S0 ∪
S10 , where S0 = EncKs (m̂, µ1 , µ2 , µ3 , 0) : (m, µ1 , µ2 , µ3 ) ∈ {0, 1}1+|µ1 |+|µ2 |+|µ3 | , and S10 =
n o
aborts.
In this experiment we change the encryption table of the key K and adjust the code of the programs
of the sender and the receiver, as shown on fig. 14, fig. 15. (For convenience of verification, we also
rewrote the code of the original programs of the receiver but made the bound on ` explicit on fig. 12).
We now describe the changes in detail. First, we change the key K of the main encryption scheme
as follows. Recall that key K is a table of all plaintext-ciphertext pairs, i.e. a table containing
entries of the form µ3 ↔ (m, µ1 , µ2 , `) for all strings m, µ1 , µ2 of the proper length and ` ∈ [0, T ].
In this experiment we replace each entry where µ1 = µ1 ∗ , except for µ3 ∗ and µ3 ∗ , with another
entry: that is, for each entry of the form µ3 ↔ (m, µ1 ∗ , µ2 , `) we replace it with another entry
µ3 ↔ (m, µ1 ∗ , µ2 , ` + 1) (as long as µ3 6= µ3 ∗ , µ3 ∗ ), thus incrementing by 1 the value of level in some
ciphertexts. In particular, the set of levels for which encryptions exist changes to [1, T + 1] from [0, T ]
for µ1 = µ1 ∗ . Note that this change does not affect the challenge µ3 ∗ .
Second, we change the code of the programs so that they add 1 to the level before encrypting with
key K, and subtract 1 from the level of decrypted µ3 before using it, thus nullifying the change from
the above and preserving the distribution. The resulting code is presented on fig. 14, fig. 15, and the
changes are highlighted in red. Below we list the changes:
– In the mixed input step of program P3, we consider the cases µ1 = µ1 ∗ and µ1 6= µ1 ∗ separately.
For the case µ1 6= µ1 ∗ the code remains unchanged. For the case µ1 = µ1 ∗ , the program outputs
an encryption of DecKS (s).` instead of DecKS (s).` − 1.
Recall that the levels of the two ciphertexts - µ3 ∗ and µ3 ∗ encrypting (1, µ1 ∗ , µ2 ∗ , 0) and
(0, µ1 ∗ , µ2 ∗ , 0) - were not incremented in a table of K. However, the mixed input step never
needs to encrypt (0, µ1 ∗ , µ2 ∗ , 0) or (1, µ1 ∗ , µ2 ∗ , 0). Indeed, to force P3 to output an encryption
of, say, (0, µ1 ∗ , µ2 ∗ , 0) via mixed input step, one has to run it on fake s with level 0(i.e. S ∈ S0 ),
but the experiment aborts in this case.
– In the mixed input step of program Dec, we consider the cases µ1 = µ1 ∗ and µ1 6= µ1 ∗ separately.
that the level in µ3 is within [1, T + 1] (instead of [0, T ]), and compares DecKR (r).` against
DecK (µ3 ).` − 1 instead of DecK (µ3 ).`, to account for an incremented levels of some ciphertexts.
Recall that the levels of the two ciphertexts - µ3 ∗ and µ3 ∗ - were not incremented in a table of K.
However, the mixed input step never outputs non-⊥ on input µ3 ∗ or µ3 ∗ . Indeed, this is because
the condition DecKR (r).` < DecK (µ3 ).` can never be satisfied due to level of µ3 ∗ , µ3 ∗ being 0.
– In program RFake, we consider three cases: µ3 = µ3 ∗ , µ3 ∗ , and else µ1 = µ1 ∗ and µ1 6= µ1 ∗ .
For the case µ1 6= µ1 ∗ and µ3 = µ3 ∗ , µ3 ∗ the code remains unchanged. For the case µ1 = µ1 ∗ ,
38
the program checks that the level in µ3 is within [1, T + 1] (instead of [0, T ]), and decrements
DecK (µ3 ).` by one before using it to compute the output.
for uniformly chosen ρ̂∗ . If µ1 ∗ ∈ H1 or µ2 ∗ ∈ H2 or ρ̂∗ ∈ H3 , the experi-
ment aborts. If nthe adversary queries any oracle on any input containing os ∈ S0 ∪
S10 , where S0 = EncKs (m̂, µ1 , µ2 , µ3 , 0) : (m, µ1 , µ2 , µ3 ) ∈ {0, 1}1+|µ1 |+|µ2 |+|µ3 | , and S10 =
n o
aborts.
In this experiment we change the encryption table of the receiver-faking key KR and adjust the code of
the programs of the receiver, as shown on fig. 16.
We now describe the changes in detail. First, we change the key KR of the receiver faking scheme
as follows. Recall that key KR is a table of all plaintext-ciphertext pairs, i.e. a table containing
entries of the form r ↔ (m̂, µ1 , µ2 , µ3 , `, ρ̂) for all strings m, µ1 , µ2 , µ3 , ρ̂ of the proper length and
` ∈ [0, T ]. In this experiment we replace each entry where µ1 = µ1 ∗ , except for (µ1 , µ2 , µ3 , `) =
(µ1 ∗ , µ2 ∗ , µ3 ∗ , 0) and (µ1 , µ2 , µ3 , `) = (µ1 ∗ , µ2 ∗ , µ3 ∗ , 0), with another entry: that is, for each entry of
the form r ↔ (m, µ1 ∗ , µ2 , µ3 , `, ρ̂) we replace it with another entry r ↔ (m, µ1 ∗ , µ2 , µ3 , ` + 1, ρ̂) (as
long as (µ2 , µ3 , `) 6= (µ2 ∗ , µ3 ∗ , 0) and (µ2 , µ3 , `) 6= (µ2 ∗ , µ3 ∗ , 0)), thus incrementing by 1 the value
of level in some ciphertexts. Note that this change does not affect the challenge r0 .
Second, we change the code of the programs so that they add 1 to the level before encrypting with key
KR , and subtract 1 from the level of decrypted r before using it, thus nullifying the change from the
above and preserving the distribution. The resulting code is presented on fig. 16, and the changes are
highlighted in red. Below we list the changes:
– In the mixed input step of program Dec, we consider the cases µ1 = µ1 ∗ and µ1 6= µ1 ∗ separately.
For the case µ1 6= µ1 ∗ the code remains unchanged. For the case µ1 = µ1 ∗ , the program uses
DecKR (r).` − 1 instead of DecKR (r).` when comparing to DecK (µ3 ).` − 1.
Recall that the levels of the ciphertexts of the form (m, µ1 ∗ , µ2 ∗ , µ3 ∗ , 0, ρ̂) were not incremented
in a table of KR . However, we claim that, even though we have adjusted the code without
adjusting the table of KR for these cases, the distribution of the experiment doesn’t change.
Indeed, to force Dec to output non-⊥ via mixed input step, given some r which is an encryption
of (m, µ1 ∗ , µ2 ∗ , µ3 ∗ , 0, ρ̂), one has to run it on inputs (r, µ1 ∗ , µ2 ∗ , µ3 ) where µ3 is itself an
encryption of µ1 ∗ , µ2 ∗ . Consider the following three cases of µ3 which encrypts µ1 ∗ , µ2 ∗ :
∗ µ3 = µ3 ∗ . In this case the trapdoor step would have been executed, and the program never
reaches the mixed input step.
∗ µ3 = µ3 ∗ . In this case the experiment aborts.
∗ µ3 6= µ3 ∗ and µ3 6= µ3 ∗ . In this case the level of µ3 is at least 2 (indeed, µ3 ∗ and µ3 ∗
are the only two possible ciphetexts with level 0, and all other levels were incremented
39
by 1, thus there are no level-1 ciphertexts). But if DecK (µ3 ).` ≥ 2, then the conditions
DecKR (r).` − 1 < DecK (µ3 ).` − 1 and DecKR (r).` < DecK (µ3 ).` − 1 are equivalent,
since DecKR (r).` = 0.
– In program RFake, we consider three cases: µ3 = µ3 ∗ , µ3 ∗ , and else µ1 = µ1 ∗ and µ1 6= µ1 ∗ .
For the case µ1 6= µ1 ∗ and µ3 = µ3 ∗ , µ3 ∗ the code remains unchanged. For the case µ1 = µ1 ∗ ,
the program encrypts the value DecK (µ3 ).` instead of DecK (µ3 ).` − 1.
for uniformly chosen ρ̂∗ . If µ1 ∗ ∈ H1 or µ2 ∗ ∈ H2 or ρ̂∗ ∈ H3 , the experiment aborts.
If the adversary queries any oracle on an input s ∈ S such that DecKS (s).µ1 = µ1 ∗ and
(DecKS (s).` = 0 or DecKS (s).` = T + 1 or DecKS (s).` = T ), the experiment aborts. If
the adversary queries any oracle on an input r ∈ R such that DecKR (r).µ1 = µ1 ∗ and
(DecKR (r).` = 0 or DecKR (R).` = T + 1), the experiment aborts. If the adversary queries
any oracle on an input µ3 ∈ M such that DecK (µ3 ).µ1 = µ1 ∗ and (DecK (µ3 ).` = 0 or
DecK (µ3 ).` = T + 1), the experimentn aborts. If the adversary queries any oracle on any input contain- o
ing s ∈ S0 ∪ S1 , where S0 = EncKs (m̂, µ1 , µ2 , µ3 , 0) : (m, µ1 , µ2 , µ3 ) ∈ {0, 1}1+|µ1 |+|µ2 |+|µ3 | ,
0
n o
and S10 = EncKs (m̂, µ1 ∗ , µ2 , µ3 , 1) : (m, µ2 , µ3 ) ∈ {0, 1}1+|µ2 |+|µ3 | \ s0 , the experiment aborts. If
aborts.
This experiment is similar to the previous one, except that it aborts if the adversary queries any variable
encrypting µ1 ∗ with level 0 or T + 1. Informally, both happen with negligible probability because none
of the programs ever output a value with µ1 ∗ and level 0, and because finding any value with level T
requires the adversary to query SFake at least T − 1 times, which is infeasible for a polynomial-time
adversary since T is superpolynomial.
More formally, note that the following is required for the adversary to find level-0 variables encrypting
µ1 ∗ : to output r with level 0 , the adversary needs to run RFake on µ3 with level 0; to find µ3 with
level 0, it needs to run P3 on s with level 0 or s 6∈ S. Since such µ3 should have µ1 ∗ encrypted, and
µ1 ∗ 6∈ H1 , there doesn’t exist s 6∈ S which outputs such µ3 . Further, s ∈ S with level 0 is never an
output of any program, and therefore the adversary can only guess any of these values, which happens
with negligible probability.
Now we show that the adversary queries any variable with level T with at most negligible probability.
Concretely, let ε be the sparseness of the sender-fake encryption scheme, i.e. ε = 2|S|
|s| . We claim that
the probability that any polynomial-time adversary queries the programs on s ∈ S with level T + 1 or
T is at most T ε, which we are going to show by proving that if the adversary makes n queries, the
probability of asking a query containing s ∈ S with ` ∈ [n + 1, T + 1] is at most εn. In turn, εn < εT
since the number of queries is polynomial. We prove this statement by induction:
For the base case, note that for n = 1, the probability that the adversary queries s ∈ S with level
` ∈ [2, . . . , T + 1] is bounded by the probability of guessing s ∈ S, which is equal to ε.
Assume the hypothesis holds for n. Assume the adversary makes n + 1 queries and happens to ask a
40
query containing s ∈ S with ` ∈ [n + 1, T + 1]. Let’s split this probability by considering the case
when it did or did not query s ∈ S with level ` − 1 within first n queries. The first event happens with
probability at most εn by induction hypothesis, and the second happens with probability at most ε
since the adversary can only guess such s ∈ S. Thus the probability of the adversary succeeding with
n + 1 queries is at most ε(n + 1), thus proving induction hypothesis for n + 1.
Finally, note that in order to query any µ3 or r with level T or T + 1, the adversary needs to either
guess it or query its “parent” variable with level T or T + 1 first (that is, s in case of µ3 , and µ3 in case
of r), and therefore the probability ad the adversary querying any variable with level T or T + 1 is
negligible.
• H11,5 : AP1,P2,P3,Dec,SFake,RFake (m0 , m1 , s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where µ1 ∗ is chosen uniformly at
for uniformly chosen ρ̂∗ .If µ1 ∗ ∈ H1 or µ2 ∗ ∈ H2 or ρ̂∗ ∈ H3 , the experiment aborts.
If the adversary queries any oracle on an input s ∈ S such that DecKS (s).µ1 = µ1 ∗ and
(DecKS (s).` = 0 or DecKS (s).` = T + 1 or DecKS (s).` = T ), the experiment aborts. If
the adversary queries any oracle on an input r ∈ R such that DecKR (r).µ1 = µ1 ∗ and
(DecKR (r).` = 0 or DecKR (R).` = T + 1), the experiment aborts. If the adversary queries
any oracle on an input µ3 ∈ M such that DecK (µ3 ).µ1 = µ1 ∗ and (DecK (µ3 ).` = 0 or
DecK (µ3 ).` = T + 1), the experiment
n aborts. If the adversary queries any oracle on any input contain- o
ing s ∈ S0 ∪ S1 , where S0 = EncKs (m̂, µ1 , µ2 , µ3 , 0) : (m, µ1 , µ2 , µ3 ) ∈ {0, 1}1+|µ1 |+|µ2 |+|µ3 | ,
0
n o
and S10 = EncKs (m̂, µ1 ∗ , µ2 , µ3 , 1) : (m, µ2 , µ3 ) ∈ {0, 1}1+|µ2 |+|µ3 | \ s0 , the experiment aborts. If
aborts.
In this experiment we revert to using the original programs of the deniable encryption scheme, without
any modifications.
We argue that this experiment is identical to the previous one. Indeed, note that there are the following
differences between the programs in this experiment and the previous experiment:
– Some programs check that the level is in [1, . . . , T + 1] instead of [0, . . . , T ], for some variables
encrypting µ1 ∗ . Also, program SFake2 checks that the level is in [1, . . . , T ] instead of [0, . . . , T −
1]. This change in the programs doesn’t change the distribution of the experiment, since the
experiment aborts when the adversary queries variables with levels 0, T, T + 1 encrypting µ1 ∗ .
– Program Dec3 checks the levels in the mixed input step by checking that DecKR (r).` − 1 <
DecK (µ3 ).` − 1, instead of DecKR (r).` < DecK (µ3 ).`. The two conditions are equivalent and
therefore this change doesn’t affect the functionality of the program.
• H11,6 : AP1,P2,P3,Dec,SFake,RFake (m0 , m1 , s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where µ1 ∗ is chosen uniformly at
EncK (m1 , µ1 ∗ , µ2 ∗ , 0), s0 = EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 1), r0 = EncKR (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0, ρ̂∗ ) for
uniformly chosen ρ̂∗ .
That is, we remove the condition that we abort when the adversary queries certain values. This is
statistically close to the previous experiment, since the adversary can only query these values with
negligible probability. The argument is similar to the argument made in previous hybrid distributions
41
where these abort conditions were introduced.
• H11,7 : AP1,P2,P3,Dec,SFake,RFake (m0 , m1 , s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where s∗ , r∗ are chosen uni-
formly at random, µ1 ∗ = P1(s∗ , m1 ), µ2 ∗ = P2(r∗ , µ1 ∗ ), µ3 ∗ = EncK (m1 , µ1 ∗ , µ2 ∗ , 0), s0 =
EncKS (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 1), r0 = EncKR (m0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , 0, H3 (ρ∗ )) for uniformly chosen ρ∗ .
That is, we set µ1 ∗ and µ2 ∗ to be their values in the protocol execution with m1 , and we set r0 to use
H3 (ρ∗ ) instead of an independent random value as randomness.
The reasoning is similar to the reasoning used in experiments H1 to H5 and H8 .
Note that this experiment corresponds to an execution on input m1 , where s0 , r0 are both fake and
consistent with m0 .
5 Preliminaries: IO, DIO, and ACE

5.1 Indistinguishability Obfuscation for Circuits
Definition 5 (Indistinguishability Obfuscation (iO)). A uniform PPT machine iO is called an indistinguisha-
bility obfuscator if the following conditions are satisfied:
• For all security parameters λ ∈ N, for all C ∈ Cλ , for all inputs x, we have that
Pr[C 0 (x) = C(x) : C 0 ← iO(1λ , C)] = 1
• There is a polynomial p such that for every circuit C ∈ Cλ , it holds that |iO(c)| ≤ p(|C|).
• For any (not necessarily uniform) PPT distinguisher D, there exists a negligible function α such that
the following holds: For all security parameters λ ∈ N, for all circuit families C0 = {Cλ0 }λ∈N , C1 =
{Cλ1 }λ∈N of size |Cλ0 | = |Cλ1 |, we have that if Cλ0 (x) = Cλ1 (x) for all inputs x, then
Pr D(iO(1λ , Cλ0 )) = 1 − Pr D(iO(1λ , Cλ1 )) = 1 ≤ negl(λ).

We say that indistinguishability obfuscation is (t(λ), ε(λ))-secure if the distinguishing advantage of all
distinguishers of size t(λ) is at most ε(λ).
5.2 Equivalence of iO and diO for programs differing on one point

In the proof of security of the level system we use the following lemma from [BPR15] (which is a special
case of theorem 6.2 from [BCP14], with exact parameters):
Lemma 1. ([BPR15, BCP14]) Let iO be a (t, δ)-secure indistinguishability obfuscator for P/poly. There
exists a PPT oracle-aided extractor E, such that for any tO(1) -size distinguisher D, and two equal-size
circuits C0 , C1 differing on exactly one input x∗ , the following holds. Let C00 , C10 be padded versions
of C0 , C1 of size s ≥ 3 · |C0 |. If |Pr[D(iO(C00 )) = 1] − Pr[D(iO(C10 )) = 1]| = η ≥ δ(s)o(1) , then
Pr[x∗ ← E D(·) (11/η , C0 , C1 )] ≥ 1 − 2−Ω(s) .
42
Oracles P1, P3, SFake.
Oracle P1(s, m)
1. Trapdoor step:
2. Main step:
Oracle P3(s, m, µ1 , µ2 )
1. Validity check:
(a) If P1(s, m) 6= µ1 then ⊥;
2. Trapdoor step:
DecKS (s).µ3 ;
(a) Else if s ∈ S and (DecKS (s).m, DecKS (s).µ1 ) = (m, µ1 ) then
i. If DecKS (s).` 6∈ [0, . . . , T ] then ⊥
ii. Else return EncK (m, µ1 , µ2 , DecKS (s).`)
4. Main step:
Oracle SFake(s, m, m̂, µ1 , µ2 , µ3 )
1. Validity check:
(a) If P1(s, m) 6= µ1 then ⊥;
2. Trapdoor step:
(a) If s ∈ S and (DecKS (s).m, DecKS (s).µ1 ) = (m, µ1 ) then
i. If DecKS (s).` 6∈ [0, . . . , T − 1] then ⊥
3. Main step:
Figure 11: Oracles P1, P3, SFake. The code of the programs is unchanged, but we make the bounds on `
explicit in relevant places; we highlight them in red for convenience.
43
Oracles P2, Dec, RFake.
Oracle P2(r, µ1 )
Hardwired values: key KR of receiver-fake encryption scheme, hash H2 with sparse image.
1. Trapdoor step:
2. Main step:
Oracle Dec(r, µ1 , µ2 , µ3 )
upper bound T .
1. Validity check:
(a) If P2(r, µ1 ) 6= µ2 then ⊥;
2. Trapdoor step:
DecKR (r).m;
(a) If r ∈ R and (DecKR (r).µ1 , DecKR (r).µ2 ) = (µ1 , µ2 ) then
i. If µ3 ∈ M and (µ1 , µ2 ) = (DecK (µ3 ).µ1 , DecK (µ3 ).µ2 ) and DecKR (r).` < DecK (µ3 ).`
and DecKR (r).` ∈ [0, . . . , T ] and DecK (µ3 ).` ∈ [0, . . . , T ] return DecK (µ3 ).m;
ii. Else ⊥.
4. Main step:
(a) If µ3 ∈ M and (DecK (µ3 ).µ1 , DecK (µ3 ).µ2 ) = (µ1 , µ2 ) then return DecK (µ3 ).m;
(b) Else ⊥.
Oracle RFake(m̂, µ1 , µ2 , µ3 ; ρ)
1. If µ3 ∈ M and DecK (µ3 ).` ∈ [0, . . . , T ] and DecK (µ3 ).µ1 = µ1 and DecK (µ3 ).µ2 = µ2 then return
EncKR (m̂, µ1 , µ2 , µ3 , DecK (µ3 ).`, H3 (ρ));
2. Else ⊥.
Figure 12: Oracles P2, Dec, RFake. The code of the programs is unchanged, but we make the bounds on `
explicit in relevant places; we highlight them in red for convenience.
44
Oracles P11 , P31 , SFake1 .
Oracle P11 (s, m)
1. Trapdoor step:
2. Main step:
Oracle P31 (s, m, µ1 , µ2 )
1. Validity check:
(a) If P11 (s, m) 6= µ1 then ⊥;
2. Trapdoor step:
DecKS (s).µ3 ;
(a) Else if s ∈ S and (DecKS (s).m, DecKS (s).µ1 ) = (m, µ1 ) and µ1 = µ1 ∗ then
i. If DecKS (s).` 6∈ [1, . . . , T + 1] then ⊥
ii. Else return EncK (m, µ1 , µ2 , DecKS (s).` − 1);
(b) Else if s ∈ S and (DecKS (s).m, DecKS (s).µ1 ) = (m, µ1 ) and then
i. If DecKS (s).` 6∈ [0, . . . , T ] then ⊥
ii. Else return EncK (m, µ1 , µ2 , DecKS (s).`);
4. Main step:
Oracle SFake1 (s, m, m̂, µ1 , µ2 , µ3 )
1. Validity check:
(a) If P11 (s, m) 6= µ1 then ⊥;
2. Trapdoor step:
(a) If s ∈ S and (DecKS (s).m, DecKS (s).µ1 ) = (m, µ1 ) and µ1 = µ1 ∗ then
i. If DecKS (s).` 6∈ [1, . . . , T ] then ⊥
(b) Else if s ∈ S and (DecKS (s).m, DecKS (s).µ1 ) = (m, µ1 ) then
i. If DecKS (s).` 6∈ [0, . . . , T − 1] then ⊥
3. Main step:
Figure 13: Oracles P11 , P31 , SFake1 .
45
Oracles P12 , P32 , SFake2 .
Oracle P12 (s, m)
1. Trapdoor step:
2. Main step:
Oracle P32 (s, m, µ1 , µ2 )
1. Validity check:
(a) If P12 (s, m) 6= µ1 then ⊥;
2. Trapdoor step:
DecKS (s).µ3 ;
(a) Else if s ∈ S and (DecKS (s).m, DecKS (s).µ1 ) = (m, µ1 ) and µ1 = µ1 ∗ then
i. If DecKS (s).` 6∈ [1, . . . , T + 1] then ⊥
i. If DecKS (s).` 6∈ [0, . . . , T ] then ⊥
4. Main step:
Oracle SFake2 (s, m, m̂, µ1 , µ2 , µ3 )
1. Validity check:
(a) If P12 (s, m) 6= µ1 then ⊥;
2. Trapdoor step:
(a) If s ∈ S and (DecKS (s).m, DecKS (s).µ1 ) = (m, µ1 ) and µ1 = µ1 ∗ then
i. If DecKS (s).` = 0 or DecKS (s).` = T + 1 then ⊥;
i. If DecKS (s).` = T then ⊥;
3. Main step:
Figure 14: Oracles P12 , P32 , SFake2 .
46
Oracles P22 , Dec2 , RFake2 .
Oracle P22 (r, µ1 )
Hardwired values: key KR of receiver-fake encryption scheme, sparse hash H2 .
1. Trapdoor step:
2. Main step:
Oracle Dec2 (r, µ1 , µ2 , µ3 )
upper bound T .
1. Validity check:
(a) If P22 (r, µ1 ) 6= µ2 then ⊥;
2. Trapdoor step:
DecKR (r).m;
(a) Else if r ∈ R and (DecKR (r).µ1 , DecKR (r).µ2 ) = (µ1 , µ2 ) then
i. If µ3 ∈ M and (µ1 , µ2 ) = (DecK (µ3 ).µ1 , DecK (µ3 ).µ2 )and DecK (µ3 ).µ1 = µ1 ∗
and DecKR (r).` < DecK (µ3 ).` − 1 and DecKR (r).` ∈ [0, . . . , T ] and DecK (µ3 ).` ∈
[1, . . . , T + 1] then return DecK (µ3 ).m;
ii. Else if µ3 ∈ M and (µ1 , µ2 ) = (DecK (µ3 ).µ1 , DecK (µ3 ).µ2 ) and DecKR (r).` <
DecK (µ3 ).` and DecKR (r).` ∈ [0, . . . , T ] and DecK (µ3 ).` ∈ [0, . . . , T ] then return
DecK (µ3 ).m;
iii. Else ⊥.
4. Main step:
(a) Else if µ3 ∈ M and (DecK (µ3 ).µ1 , DecK (µ3 ).µ2 ) = (µ1 , µ2 ) then
i. Else return DecK (µ3 ).m;
(b) Else ⊥.
Oracle RFake2 (m̂, µ1 , µ2 , µ3 ; ρ)
1. If µ3 = µ3 ∗ or µ3 = µ3 ∗ then
(a) (µ1 , µ2 ) = (µ1 ∗ , µ2 ∗ ) then return EncKR (m̂, µ1 , µ2 , µ3 , 0, H3 (ρ));
(b) Else ⊥;
2. Else if µ3 ∈ M and DecK (µ3 ).µ1 = µ1 ∗ and DecK (µ3 ).` ∈ [1, . . . , T + 1] and DecK (µ3 ).µ1 = µ1
and DecK (µ3 ).µ2 = µ2 then return EncKR (m̂, µ1 , µ2 , µ3 , DecK (µ3 ).` − 1, H3 (ρ));
3. Else if µ3 ∈ M and DecK (µ3 ).` ∈ [0, . . . , T ] and DecK (µ3 ).µ1 = µ1 and DecK (µ3 ).µ2 = µ2 then
return EncKR (m̂, µ1 , µ2 , µ3 , DecK (µ3 ).`, H3 (ρ));
4. Else ⊥.
Figure 15: Oracles P22 , Dec2 , RFake2 .
47
Oracles P23 , Dec3 , RFake3 .
Oracle P23 (r, µ1 )
Hardwired values: key KR of receiver-fake encryption scheme, sparse hash H2 .
1. Trapdoor step:
2. Main step:
Oracle Dec3 (r, µ1 , µ2 , µ3 )
upper bound T .
1. Validity check:
(a) If P23 (r, µ1 ) 6= µ2 then ⊥;
2. Trapdoor step:
DecKR (r).m;
(a) Else if r ∈ R and (DecKR (r).µ1 , DecKR (r).µ2 ) = (µ1 , µ2 ) then
i. If µ3 ∈ M and (µ1 , µ2 ) = (DecK (µ3 ).µ1 , DecK (µ3 ).µ2 )and DecK (µ3 ).µ1 = µ1 ∗ and
DecKR (r).` − 1 < DecK (µ3 ).` − 1 and DecKR (r).` ∈ [1, . . . , T + 1] and DecK (µ3 ).` ∈
[1, . . . , T + 1] then return DecK (µ3 ).m;
ii. Else if µ3 ∈ M and (µ1 , µ2 ) = (DecK (µ3 ).µ1 , DecK (µ3 ).µ2 ) and DecKR (r).` <
DecK (µ3 ).` and DecKR (r).` ∈ [0, . . . , T ] and DecK (µ3 ).` ∈ [0, . . . , T ] then return
DecK (µ3 ).m;
iii. Else ⊥.
4. Main step:
(a) Else if µ3 ∈ M and (DecK (µ3 ).µ1 , DecK (µ3 ).µ2 ) = (µ1 , µ2 ) then
i. Else return DecK (µ3 ).m;
(b) Else ⊥.
Oracle RFake3 (m̂, µ1 , µ2 , µ3 ; ρ)
1. If µ3 = µ3 ∗ or µ3 = µ3 ∗ then
(a) (µ1 , µ2 ) = (µ1 ∗ , µ2 ∗ ) then return EncKR (m̂, µ1 , µ2 , µ3 , 0, H3 (ρ));
(b) Else ⊥;
2. If µ3 ∈ M and DecK (µ3 ).µ1 = µ1 ∗ and DecK (µ3 ).` ∈ [1, . . . , T + 1] and DecK (µ3 ).µ1 = µ1 and
DecK (µ3 ).µ2 = µ2 then return EncKR (m̂, µ1 , µ2 , µ3 , DecK (µ3 ).`, H3 (ρ));
3. Else if µ3 ∈ M and DecK (µ3 ).` ∈ [0, . . . , T ] and DecK (µ3 ).µ1 = µ1 and DecK (µ3 ).µ2 = µ2 then
return EncKR (m̂, µ1 , µ2 , µ3 , DecK (µ3 ).`, H3 (ρ));
4. Else ⊥.
Figure 16: Oracles P23 , Dec3 , RFake3 .
48
5.3 Puncturable Pseudorandom Functions and their variants
Puncturable PRFs. In puncrurable PRFs it is possible to create a key that is punctured at a set S of
polynomial size. A key k punctured at S (denoted k{S}) allows evaluating the PRF at all points not in S.
Furthermore, the function values at points in S remain pseudorandom even given k{S}.
Definition 6. A puncturable pseudorandom function family for input size n(λ) and output size m(λ) is a
tuple of algorithms {Sample, Puncture, Eval} such that the following properties hold:
• Functionality preserved under puncturing: For any PPT adversary A which outputs a set S ⊂
{0, 1}n , for any x 6∈ S,
Pr[Fk (x) = Fk{S} (x) : k ← Sample(1λ ), k{S} ← Puncture(k, S)] = 1.
• Pseudorandomness at punctured points: For any PPT adversaries A1 , A2 , define a set S and state
state as (S, state) ← A1 (1λ ). Then
Pr[A2 (state, S, k{S}, Fk (S))] − Pr[A2 (state, S, k{S}, U|S|·m(λ) )] < negl(λ),
where Fk (S) denotes concatenated PRF values on inputs from S, i.e. Fk (S) = {Fk (xi ) : xi ∈ S}.
The GGM PRF [GGM84] satisfies this definition.
Statistically injective puncturable PRFs. Such PRFs are injective with overwhelming probability over the
choice of a key. Sahai and Waters [SW14] show that if F is a puncturable PRF with arbitrary input length n
and output length m ≥ 2n + λ, and h is 2-universal hash function, then F0k,h = Fk (x) ⊕ h(x) is a statistically
injective puncturable PRF with probability 1 − 2−λ over the choice of a key.
Extracting puncturable PRFs. Such PRFs have a property of a strong extractor: even when a full key is
known, the output of the PRF is statistically close to uniform, as long as there is enough min-entropy in the
input. Sahai and Waters [SW14] show that if the input has min-entropy at least m + 2λ + 2 (where m is the
output size), then such PRF can be constructed from any puncturable PRF F as F0k,h = h(Fk (x)), where h is
2-universal hash function; it can be shown that the output of this PRF together with the key is 2−λ -close to
the uniform distribution.
Sparse computationally extracting puncturable PRFs. We need a slightly modified version of extracting
PRFs: we relax the extracting requirement from statistical to computational, but require our PRF to have a
sparse image. Such a PRF can be built from computationally extracting PRF by applying a PRF on top of it
[CPR17].
Definition 7. A PRF family with a key k mapping {0, 1}n(λ) to {0, 1}l(λ) is a sparse computationally
extracting family for min-entropy t(λ), if, in addition to the standard definition of a puncturable PRF, the
following two conditions hold:
• Sparseness: Pr[r ∈ Im(Fk ) : k ← Sample(1λ ), r ← Ul ] < ν(λ) for some negligible function ν;
• Computational extractor: If distribution X has min-entropy at least t(λ), then with overwhelming
probability over the choice of key k for any PPT adversary A
| Pr [ A(k, Fk (x)) = 1 | x ← X ] − Pr [ A(k, r) = 1 | r ← UI ] | < negl(λ).
49
We say that such a PRF is (t(λ), ε(λ))-secure, if for any t-sized distinguishers the distinguishing advantage in
the puncturable PRF game and in the computational extractor game is at most ε, and sparseness ν(λ) < ε(λ).
[CPR17] show that, assuming one-way functions, such PRFs exist if t(λ), the entropy of the input, is at least
m/2 + 2λ + 2, and m is superlogarithmic. Their construction uses a PRF with security parameter λ and
a PRG with security parameter m/2 and therefore the construction can be made exponentially secure, by
requiring (possibly stronger) subexponential security of the underlying PRF and PRG.
5.4 Asymmetrically constrained encryption (ACE) and its relaxed variant

ACE at a high level. Asymmetrically constrained encryption ([CHJV14], see also the journal version
[BCG+ 18]), or ACE for short, is a public-key, deterministic encryption scheme with special security prop-
erties. Intuitively, it allows to puncture both the public key and the secret key, at possibly different sets,
such that EK{m} doesn’t allow to compute the encryption of m, and DK{m} doesn’t allow to decrypt the
encryption of m. The scheme has to satisfy the following security properties, which we only roughly outline
in this paragraph (see the formal definition below for precise correctness and security requirements):
• Indistinguishability of ciphertexts: EncEK (m0 ) and EncEK (m1 ) are indistinguishable even given
punctured EK{m0 , m1 }, DK{m0 , m1 } (or given EK, DK punctured at bigger sets including m0 , m1 ).
Intuitively, the adversary can neither encrypt m0 , m1 nor decrypt EncEK (m0 ) and EncEK (m1 ), and
thus cannot distinguish between encryptions of m0 , m1 .
• Security of constrained decryption: Given EK{U }, it is hard to distinguish between DK{S0 } and
DK{S1 }, where S0 ⊆ S1 ⊆ U . Intuitively, the adversary cannot distinguish between these two cases
since it is hard to find a “differing ciphertext” EncEK (m), m ∈ S1 \ S0 , which DK{S0 } and DK{S1 }
decrypt differently (to m and ⊥). Such ciphertexts are hard to find since such m ∈ U , and EK is
punctured at U .
Relaxed ACE at a high level. In addition to ACE, we require a slightly different version of it, which we
call a relaxed ACE. Relaxed ACE does not require indistinguishability of ciphertexts, but instead requires a
different property called symmetry. We show how to modify the construction of [CHJV14] to build relaxed
ACE with small security loss in constrained decryption game for certain sets. More concretely, we have the
following differences:
• In [CHJV14], security of constrained decryption allows for security loss proportional to the size of
S1 \ S0 , since they change DK{S0 } to DK{S1 }, one point at a time. This is too much in our case,
since our sets have size 2O(λ) . However, our sets have nice structure (e.g. all strings ending with the
same suffix, or all such strings except one), and we can slightly modify the construction such that
security loss is only polynomial on such sets. Essentially, our ciphertexts, instead of having a single
signature of a plaintext like in [CHJV14], have signatures of each prefix of the plaintext, which allows
to puncture DK at a lot of points at once (this technique is similar to [GPS16]).
• We require additional property which we call symmetry. To define it, we first need a syntactically
different way of puncturing the decryption key. In [CHJV14] puncturing is plaintext-based (i.e. the
punctured key DK{m} has the description of the plaintext but not the ciphertext). We need, in
addition to that, a ciphertext-based way to puncture (we denote it as DK{c}). Symmetry then says
that distributions (c∗ , c0 , EK{m}, DK{c∗ , c0 }) and (c0 , c∗ , EK{m}, DK{c∗ , c0 }) are indistinguishable,
where m is an arbitrary plaintext, c0 is its ciphertext, and c∗ is randomly chosen. We note that for
ciphertext-based punctured key symmetry is the only required security property, although we still
50
require all applicable correctness properties.
Definition of ACE. Now we present a formal definition:
Definition 8. [CHJV14], [BCG+ 18] An asymmetrically constrained encryption (ACE) scheme is a 5-tuple
of PPT algorithms (Setup, GenEK, GenDK, Enc, Dec) satisfying syntax, correctness, security of constrained
decryption, and selective indistinguishability of ciphertexts as described below.
Syntax. The algorithms (Setup, GenEK, GenDK, Enc, Dec) have the following syntax.
• Setup: Setup(1λ , 1n , 1s ) is a randomized algorithm that takes as input the security parameter λ, the
message length n, and a “circuit succinctness” parameter s, all in unary. Setup then outputs a secret
key SK. We think of secret keys as consisting of two parts: an encryption key EK and a decryption
key DK.
Let M = {0, 1}n denote the message space.
• (Constrained) Key Generation: Let S ⊂ M be any set whose membership is decidable by a circuit
CS . We say that S is admissible if |CS | ≤ s. Intuitively, the set size parameter s denotes the upper
bound on the size of circuit description of sets to which encryption and decryption keys can be
constrained.
– GenEK(SK, CS ) takes as input the secret key SK of the scheme and the description of circuit
CS for an admissible set S. It outputs an encryption key EK{S}. We write EK to denote
EK{∅}.
– GenDK(SK, CS ) also takes as input the secret key SK of the scheme and the description of
circuit CS for an admissible set S. It outputs a decryption key DK{S}. We write DK to denote
DK{∅}.
Unless mentioned otherwise, we will only consider admissible sets S ⊂ M.
• Encryption: Enc(EK 0 , m) is a deterministic algorithm that takes as input an encryption key EK 0
(that may be constrained) and a message m ∈ M and outputs a ciphertext c or the reject symbol ⊥.
• Decryption: Dec(DK 0 , c) is a deterministic algorithm that takes as input a decryption key DK 0 (that
may be constrained) and a ciphertext c and outputs a message m ∈ M or the reject symbol ⊥.
Correctness. An ACE scheme is correct if the following properties hold:
1. Correctness of Decryption: For all n, all m ∈ M, all sets S, S 0 ⊂ M s.t. m ∈
/ S ∪ S0,
SK ← Setup(1λ ),
 
Pr Dec(DK, Enc(EK, m)) = m EK ← GenEK(SK, CS 0 ),  = 1.

DK ← GenDK(SK, CS )
Informally, this says that Dec ◦ Enc is the identity on messages which are in neither of the punctured
sets.
2. Equivalence of Constrained Encryption: Let SK ← Setup(1λ ). For any message m ∈ M and any
sets S, S 0 ⊂ M with m not in the symmetric difference S∆S 0 (i.e., we are requiring that m is in both
51
S and S 0 or m is in neither S nor S 0 ).
SK ← Setup(1λ ),
 
Pr Enc(EK, m) = Enc(EK 0 , m) EK ← GenEK(SK, CS ),  = 1.

EK 0 ← GenEK(SK, CS 0 )
3. Unique Ciphertexts: With high probability over SK ← Setup(1λ ), it holds for any c and c0 that if
Dec(DK, c) = Dec(DK, c0 ) 6= ⊥, then c = c0 .
4. Safety of Constrained Decryption: For all strings c, all S ⊂ M,
Pr Dec(DK, c) ∈ S SK ← Setup(1λ ), DK ← GenDK(SK, CS ) = 0

This says that a punctured key DK{S} will never decrypt a string c to a message in S.
/ S 0 , then
5. Equivalence of Constrained Decryption: If Dec(DK{S}, c) = m 6= ⊥ and m ∈
Dec(DK{S 0 }, c) = m.
Security of Constrained Decryption. Intuitively, this property says that for any two sets S0 , S1 , no
adversary can distinguish between the constrained key DK{S0 } and DK{S1 }, even given additional
auxiliary information in the form of a constrained encryption key EK 0 and ciphertexts c1 , . . . , ct . To rule
out trivial attacks, EK 0 is constrained at least on S0 ∆S1 . Similarly, each ci is an encryption of a message
m∈ / S0 ∆S1 .
Formally, we describe security of constrained decryption as a multi-stage game between an adversary adv
and a challenger.
• Setup: A chooses sets S0 , S1 , U s.t. S0 ∆S1 ⊆ U ⊆ M and sends their circuit descriptions
(CS0 , CS1 , CU ) to the challenger. adv also sends arbitrary polynomially many messages m1 , . . . , mt
such that mi ∈ / S0 ∆S1 .
The challenger chooses a bit b ∈ {0, 1} and computes the following:
1. SK ← Setup(1λ ),
2. DK{Sb } ← GenDK(SK, CSb ),
3. EK ← GenEK(SK, ∅),
4. ci ← Enc(EK, mi ) for every i ∈ [t], and
5. EK{U } ← GenEK(SK, CU ).
Finally, it sends the tuple (EK{U }, DK{Sb }, {ci }) to adv.
• Guess: A outputs a bit b0 ∈ {0, 1}.
The advantage of A in this game (on security parameter λ) is defined as advA = Pr[b0 = b] − 1
2 . We require
that for all PPT A, advA (λ) is negl(λ)|S1 \ S0 | .
Selective Indistinguishability of Ciphertexts. Intuitively, this property says that no adversary can distin-
guish encryptions of m0 from encryptions of m1 , even given certain auxiliary information. The auxiliary
information corresponds to constrained encryption and decryption keys EK 0 , DK 0 , as well as some ci-
phertexts c1 , . . . , ct . In order to rule out trivial attacks, EK 0 and DK 0 should both be punctured on at
52
least {m0 , m1 }, and none of c1 , . . . , ct should be an encryption of m0 or m1 . Let both F1 and F2 be
sub-exponentially secure.
Formally, we require that for all sets S, U ⊂ M, for all m∗0 , m∗1 ∈ S ∩ U , and all m1 , . . . , mt ∈ M \
{m∗0 , m∗1 }, the distribution
EK{S}, DK{U }, c∗0 , c∗1 , c1 , . . . , ct
is computationally indistinguishable from
EK{S}, DK{U }, c∗1 , c∗0 , c1 , . . . , ct
in the probability space defined by sampling SK ← Setup(1λ ), EK ← GenEK(SK, ∅), EK{S} ←

GenEK(SK, CS ), DK{U } ← GenDK(SK, CU ), c∗b ← Enc(EK, m∗b ), and ci ← Enc(EK, mi ).
As shown in [CHJV14], there exists subexponentially secure ACE assuming subexponentially secure injective
PRGs and iO. We note that their construction and the proof can be based on injective OWFs instead of
injective PRGs, similar to the proof of our relaxed ACE (section C).
Definition of relaxed ACE. As noted earlier, we also consider a relaxed ACE where indistinguishability of
ciphertexts doesn’t necessarily hold. Instead, we require a different property called symmetry, and we show
how to modify the construction of [CHJV14] to build relaxed ACE with small security loss in the constrained
decryption game for certain sets.
Definition 9. A relaxed asymmetrically constrained encryption (relaxed ACE) scheme for message space
{0, 1}n and suffix parameter t is a 6-tuple of PPT algorithms (Setup, GenEK, GenDK, Enc, Dec, Puncture)
satisfying the the following:
1. Syntax: Setup, GenEK, GenDK, Enc, Dec) have syntax as in the definition of ACE. Ciphertext-based
puncturing algorithm Puncture(SK, c1 , c2 ) is an algorithm which takes as input the secret key SK,
a ciphertext c2 and a random string c1 of the same length and outputs a ciphertext-based punctured
key DK{c1 , c2 }. (We use this notation to distinguish ciphertext-based puncturing DK{c1 , c2 } from
plaintext-based puncturing DK{S}, where S is a set of plaintexts).
2. Correctness: We require all correctness properties as in the ACE definition. In addition, we require
correctness of decryption and equivalence of constrained decryption to hold even for ciphertext-
based punctured decryption keys. Namely, if DK{c1 , c2 } = Puncture(SK, c1 , c2 )) where c1 is
random and c2 is Enc(EK, m), then we require that the mentioned properties hold for the constrained
set S = {m}.
3. Security: We require security of constrained decryption (from the definition of ACE) to hold for
the case when there are no plaintext queries, and only for the case when S1 \ S0 is either of the form
Ssuf (that is, a set of all strings ending with arbitrary, but the same for all strings, suffix suf of length t),
or of the form Ssuf \ {m∗ } (where again suf has the size t, and m∗ also ends with suf). Further, we
require that distinguishing advantage depends on |S1 \ S0 | at most logarithmically; in particular, it
should be negligible even when |S1 \ S0 | = O(2λ ) (alternatively, we can require that the advantage is
smaller than a concrete negligible function).
In addition, for ciphertext-based punctured key we require a property called symmetry, which is
defined with respect to the following game.
53
1. A chooses plaintext m and sends it to the challenger. Let U = Ssuffixt (m) be the set of all strings ending
with the same t bits as m. the challenger computes the following:
2. SK ← Setup(1λ ),
3. c1 is chosen at random from {0, 1}|c| ;
4. EK ← GenEK(SK, ∅),
5. EK{U } ← GenEK(SK, U ),
6. c2 ← Enc(EK, m)
7. DK{c1 , c2 } ← Puncture(SK, c1 , c2 ),
8. Finally the challenger chooses random b and gives the adversary (c1 , c2 , EK{U }, DK{c1 , c2 }) if
b = 0 and (c2 , c1 , EK{U }, DK{c1 , c2 }) if b = 1;
9. A outputs a bit b0 ∈ {0, 1}.
The advantage of A in this game (on security parameter λ) is defined as advA = Pr[b0 = b] − 21 . We require
that for all PPT A, advA (λ) is negligible in λ (alternatively, we can require that it is smaller than a concrete
negligible function ).
In the appendix (section C) we show that there exists subexponentially secure relaxed ACE assuming
subexponentially secure OWFs and iO.
Sparse relaxed ACE. We remark that our relaxed ACE from appendix C has sparse image, that is, the
probability that a randomly chosen string of a proper length is a valid ACE ciphertext is at most 2−λ .
6 Construction of interactive deniable encryption

In this section we describe a construction of interactive deniable encryption for a single-bit message space.
Notation.
We denote by s and r the variables corresponding to randomness of the sender and the receiver, respectively,
and let µ1 , µ2 , µ3 denote the three messages of the protocol. P1, P2, P3, Dec, SFake, RFake are programs of
the deniable encryption.
P1(s, m) takes as input sender randomness s and plaintext m and outputs the first message µ1 . P2(r, µ1 ) takes
as input receiver randomness r and first message µ1 and outputs the second message µ2 . P3(s, m, µ1 , µ2 )
takes as input sender randomness s, plaintext m, and protocol messages µ1 , µ2 and outputs the last message
µ3 . Dec(r, µ1 , µ2 , µ3 ) takes as input receiver randomness r and protocol messages µ1 , µ2 , µ3 and outputs
the plaintext m. SFake(s, m, m̂, µ1 , µ2 , µ3 ) takes as input sender randomness s, true plaintext m, new (fake)
plaintext m̂, and protocol messages µ1 , µ2 , µ3 and outputs fake randomness s0 which makes µ1 , µ2 , µ3
look consistent with m̂. RFake(m̂, µ1 , µ2 , µ3 ) takes as input new (fake) plaintext m̂ and protocol messages
µ1 , µ2 , µ3 and outputs fake randomness r0 which makes µ1 , µ2 , µ3 look consistent with m̂.
To avoid cumbersome notation, we use the same name for both unobfuscated and obfuscated programs.
In particular, the parties and the adversary only see obfuscated programs and never the actual code of the
programs. For example, on fig. 17 the instruction to the sender to run P1 means taking the obfuscation of the
program P1 from the CRS and running it.
54
The CRS: Programs P1, P2, P3, Dec, SFake, RFake (fig. 18, fig. 19)), obfuscated under iO.
Our Interactive deniable encryption:

Inputs: plaintext m ∈ {0, 1} of the sender.
1. Message 1: The sender chooses random s∗ , computes µ1 ∗ ← P1(s∗ , m) and sends µ1 ∗ .
2. Message 2: The receiver chooses random r∗ , computes µ2 ∗ ← P2(r∗ , µ1 ∗ ) and sends µ2 ∗ .
3. Message 3: The sender computes µ3 ∗ ← P3(s∗ , m, µ1 ∗ , µ2 ∗ ) and sends µ3 ∗ .
4. The receiver runs m0 ← Dec(r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ).
Sender Coercion:
Inputs: real plaintext m ∈ {0, 1}, fake plaintext m̂ ∈ {0, 1}, real random coins s∗ of the sender, and the
protocol transcript µ1 ∗ , µ2 ∗ , µ3 ∗ .
1. Upon coercion, the sender computes fake randomness s0 ← SFake(s∗ , m, m̂, µ1 ∗ , µ2 ∗ , µ3 ∗ ).
Receiver Coercion:
Inputs: fake plaintext m̂ ∈ {0, 1} and the protocol transcript µ1 ∗ , µ2 ∗ , µ3 ∗ .
1. Upon coercion, the receiver chooses random ρ∗ and computes fake randomness r0 ←
RFake(m̂, µ1 ∗ , µ2 ∗ , µ3 ∗ ; ρ∗ ).
Figure 17: Our interactive deniable encryption scheme.
Everywhere throughout the paper we will be assuming that any program outputs ⊥, if any of its underlying
primitives outputs ⊥, except for the cases where it is explicitly written otherwise.
6.1 Construction
The protocol is described in fig. 17. It simply instructs parties to run the programs from the CRS, which
consists of 6 obfuscated programs P1, P2, P3, Dec, SFake, RFake (described in fig. 18, fig. 19). Note that
deniability of the receiver is public, since the knowledge of randomness of the receiver is not required in
order to run RFake.
In the introduction we described the reasons behind the logic of the programs we are using. Here we give
an overview of the overall structure of protocol messages and fake randomness. For simplicity, for this
discussion we will use integer levels to count how many times s was faked (in the full construction, the
programs of deniable encryption make use of a “level system” primitive instead of integers in the clear; level
systems are defined formally in Section 7).
The structure of protocol messages. The first two messages in the protocol are simply “hashes” (imple-
mented as a PRF) of internal state of parties so far: that is, µ1 is PRF(s, m) and µ2 is PRF(r, µ1 ). The third
message µ3 is an encryption of m, µ1 , µ2 , and level 0. After running the protocol, the receiver can run Dec
which decrypts µ3 and outputs m.
The structure of fake randomness. Fake randomness s0 of the sender is an encryption (under a special
sender-fake key which is known to programs but not known to parties) of m0 , µ1 0 , µ2 0 , µ3 0 , and level 1. This
encryption has pseudorandom ciphertexts, and for an external observer s0 looks like a truly random value.
Programs can decrypt s0 using hardwired key and interpret (m0 , µ1 0 , µ2 0 , µ3 0 , `0 ) as an instruction to output
µ1 0 on input m0 (for program P1) and an instruction to output µ3 0 on input m0 , µ1 0 , µ2 0 (for program P3).
Thus, such s0 makes the transcript look consistent with m0 , regardless of the actual plaintext which was used
55
to generate the transcript.
Similarly, fake randomness r0 of the receiver is an encryption (under a special receiver-fake key which is
known to programs but not known to parties) of m0 , µ1 0 , µ2 0 , µ3 0 , and level 0 (together with prg(ρ) which
is for randomizing this ciphertext). This encryption has pseudorandom ciphertexts, and for an external
observer r0 looks like a truly random value. Programs can decrypt r0 using hardwired key and interpret
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 ) as an instruction to output µ2 0 on input µ1 0 (for program P2) and an instruction to
output m0 on input µ1 0 , µ2 0 , µ3 0 (for program Dec). Thus, such r0 makes the transcript looks consistent with
m0 (and in particular decrypts it to m0 ), regardless of the actual plaintext which was used to generate the
transcript.
Both programs P3, Dec also have special instructions for the “mixed input” case, i.e., for the case when P3
gets as input fake s0 encrypting (m0 , µ1 0 , µ2 0 , µ3 0 , `0 ), but input µ2 of the program P3 is different from µ2 0
in s0 (in case of Dec, when µ3 0 in fake r0 is different from input µ3 to Dec). The correct treatment of the
mixed case is crucial for security of the scheme. See the explanation in the introduction for the logic of the
programs on mixed inputs.
6.2 Building blocks and main theorem stating security

6.2.1 Level system
The level system, mentioned in earlier sections of this paper, is a primitive introduced in this work that is a
critical building block of our deniable encryption protocol. This subsection provides detailed intuition about
the level system primitive followed by a formal definition (the latter being a prerequisite to formally stating
the security guarantees of our main construction). This subsection’s scope is purely definitional; see Section 7
for a construction and security proof.
Motivation and overview. The idea of a level system is to have an encryption scheme which allows to
increment ciphertexts and compare them homomorphically. However, in order for this encryption to be useful
in our construction of deniable protocol, we require the following properties of this "encryption scheme":25
• There should be two types of ciphertexts, which we call single-tag levels and double-tag levels;
• A single-tag level is an encryption of number i between 0 and upper bound T , together with some
string m1 ∈ M1 , which we call a tag. (In our construction of deniable encryption, we use the first
message of the deniable protocol as a tag. This is done to “tie” the level to the instance of the protocol).
• A double-tag level is an encryption of number i between 0 and upper bound T , together with two tags
m1 ∈ M1 , m2 ∈ M2 . (In our construction of deniable encryption, we use the first and the second
messages of the deniable protocol as tags. This, again, is done to “tie” the level to the instance of the
protocol).
• It should be possible to perform the following operations:
1. Sample a single-tag level 0 for any tag m1 ;
2. Homomorphically increment the value inside any single-tag level (keeping its tag the same);
3. Transform any single-tag level into a double-tag level, for any second tag m2 (the value and the
first tag remain the same);
25
Note that even though we call it encryption, we don’t require this primitive to have decryption.
56
4. Compare two double-tag levels, as long as their both tags are the same;
5. Given any level, retrieve its tag(s).
Notation. We use notation [i, m1 ] to denote a single-tag level with value i and tag m1 . We also use `i to
denote a single-tag level with value i, when the tag is clear from the context.
We use notation [i, m1 , m2 ] to denote a double-tag level with value i and tags m1 , m2 . We also use Li to
denote a double-tag level with value i, when its tags are clear from the context.
Security property. The security requirement of a level system is that it should be hard to distinguish between
`∗0 = [0, m∗1 ], L∗0 = [0, m∗1 , m∗2 ] and `∗1 = [1, m∗1 ], L∗0 = [0, m∗1 , m∗2 ], even given (limited) ability to perform
homomorphic operations described above.
This will be used in the proof of security of deniable encryption scheme as follows. Recall that in that proof
we need to start with the real transcript and real randomness s, r (having levels L∗0 , `∗0 , L∗0 , respectively) and
eventually switch to the (same) real transcript but fake randomness s0 , r0 (with levels L∗0 , `∗1 , L∗0 ). We can use
security of the level system in the proof of deniable encryption as follows: given challenge `∗b , L∗0 (where
`∗b = [b, m∗1 ], b ∈ {0, 1}, L∗0 = [0, m∗1 , m∗2 ]), we use `∗b inside fake s and we use L∗0 inside the transcript and
fake r. Since security of levels only holds when programs are punctured, in the proof of deniable encryption
we first move to a hybrid with only punctured level programs, and then invoke security of the level system.
Definition We start with describing the syntax of a level system for tag space M and upper bound T :
• Setup(1λ ; T ; GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags; rSetup ) → PP =
(PGenZero , PIncrement , PTransform , PisLess , PRetrieveTag , PRetrieveTags ) is a randomized algorithm which
takes as input security parameter, the largest allowed level T , description of programs, and randomness.
It uses random coins to sample all necessary keys for each program26 , and outputs those programs
obfuscated under iO.
• GenZero(m1 ) → ` is a deterministic algorithm which takes message m1 ∈ M as input and outputs a
string ` = [0, m1 ], which is a single-tag level with tag m1 and value 0. We also require that there exists
a punctured version of this algorithm denoted GenZero[m∗1 ](m1 ) which outputs 0 fail0 on input m∗1 .
• Increment(`) → `0 is a deterministic algorithm which takes a single-tag level ` = [i, m1 ] for some
0 ≤ i ≤ T − 1, m1 ∈ M , and outputs a single-tag level with the same tag and incremented value, i.e.
`0 = [i + 1, m1 ]. If i ≥ T , it instead outputs 0 fail0 .
• Transform(`, m2 ) → ` is a deterministic algorithm which takes a single-tag level ` = [i, m1 ] for some
0 ≤ i ≤ T, m1 ∈ M , and some message m2 ∈ M , and outputs L = [i, m1 , m2 ], which is a double-tag
level with tags m1 , m2 , and value i. We also require that there exists a punctured version of this
algorithm denoted Transform[(`∗ , m∗2 )](`, m2 ) which outputs 0 fail0 on input (`∗ , m∗2 ).
• isLess(L0 , L00 ) → out ∈ {true, false} is a deterministic algorithm which takes as input two double-tag
levels L0 = [i0 , m01 , m02 ] and L00 = [i00 , m001 , m002 ]. If (m01 , m02 ) 6= (m001 , m002 ), then it outputs 0 fail0 .
Otherwise it outputs true if i0 < i00 and false if i0 ≥ i00 .
• RetrieveTag(`) → m1 is a deterministic algorithm which takes a single-tag level ` and outputs its tag.
• RetrieveTags(L) → (m1 , m2 ) is a deterministic algorithm which takes a double-tag level L and
outputs both tags.
26
We assume that Setup is implicitly given generation algorithms for all underlying primitives of the programs.
57
We emphasize that all programs except Setup are deterministic.
Definition 10. A tuple of parametrized, deterministic27 algorithms
(GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags, GenZero[m∗1 ], Transform[l∗ , m∗2 ])
is a level system for tag space M , if algorithms have syntax described above, and the correctness and security
properties described below hold.
Notation: Let T be superpolynomial in λ, and PP = (PGenZero , PIncrement , PTransform , PisLess , PRetrieveTag ,
PRetrieveTags ) ← Setup(1λ ; T ; GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags; rSetup )
for randomly chosen rSetup .
Next, let m∗1 ∈ M , m∗2 ∈ M , and let `∗ be an arbitrary string (not necessarily a level). Let
PP0 = (P0GenZero , P0Increment , P0Transform , P0isLess , P0RetrieveTag , P0RetrieveTags ) ← Setup(1λ , T, GenZero[m∗1 ],
Increment, Transform[(`∗ , m∗2 )], isLess, RetrieveTag, RetrieveTags; rSetup ) with the same randomness
rSetup as above.
For any fixed rSetup consider the following notation:
• For every m1 ∈ M denote [0, m1 ] = PGenZero (m1 );
• For every m1 ∈ M , 1 ≤ i ≤ T denote [i, m] = PIncrement ([i − 1, m]);
• For every m2 ∈ M and every [i, m1 ], where 0 ≤ i ≤ T, m1 ∈ M , denote [i, m1 , m2 ] =
PTransform ([i, m1 ], m2 ).
Correctness: The following properties should hold, except with negligible probability over the choice of
rSetup :
• Uniqueness of levels:
– For all ` ∈
/ {[i, m1 ] : 0 ≤ i ≤ T, m1 ∈ M }:
∗ PIncrement (`) = 0 fail0 ;
∗ PTransform (`, m2 ) = 0 fail0 for any m2 ∈ M ;
∗ PRetrieveTag (`) = 0 fail0 .
– For all L ∈
/ {[i, m1 , m2 ] : 0 ≤ i ≤ T, m1 ∈ M, m2 ∈ M }:
∗ PisLess (L, L0 ) = 0 fail0 , PisLess (L0 , L) = 0 fail0 , for any string L0 ;
∗ PRetrieveTags (L) = 0 fail0 .
• Upper bound is respected: For every m1 ∈ M PIncrement ([T, m1 ]) = 0 fail0 .
• Correctness of comparison: For every m1 , m2 ∈ M and for every 0 ≤ i, j ≤ T :
– PisLess ([i, m1 , m2 ], [j, m1 , m2 ]) = true for i < j,
27
We prefer to use the notion of parametrized, deterministic algorithms to keep the definition simple. To formally define this
notion, consider a randomized Turing machine with the restriction that the number of random bits written on its random tape is fixed
and independent of the input (only dependent on security parameter λ). Such a Turing machine can first use these random coins to
generate all necessary parameters (e.g., keys) and then run the actual code of the algorithm using generated parameters. In particular,
we assume that this TM has the code of all necessary generation algorithms.
58
– PisLess ([i, m1 , m2 ], [j, m1 , m2 ]) = false for i ≥ j.
• Comparison is possible only on matching levels: If (m01 , m02 ) 6= (m001 , m002 ), then
PisLess ([i, m01 , m02 ], [j, m001 , m002 ]) = 0 fail0 for all i, j.
• Correctness of tags retrieval: For every m1 , m2 ∈ M and for every 0 ≤ i ≤ T :
– PRetrieveTag ([i, m1 ]) = m1 ,
– PRetrieveTags ([i, m1 , m2 ]) = (m1 , m2 ).
• Functionality is preserved under puncturing:
– PGenZero (m) = P0GenZero (m) for all m ∈ M , m 6= m∗1 ;
– PIncrement (`) = P0Increment (`) for all strings `;
– PTransform (`, m2 ) = P0Transform (`, m2 ) for all strings l and for all m2 ∈ M , except (`∗ , m∗2 );
– PisLess (L0 , L00 ) = P0isLess (L00 , L00 ) for all strings L0 , L00 ;
– PRetrieveTag (`) = P0RetrieveTag (`) for all strings `;
– PRetrieveTags (L) = P0RetrieveTags (L) for all strings L.
Note that it follows from the correctness properties that [i, m1 ] = [i0 , m01 ] if and only (i, m1 ) = (i0 , m01 ), and
[i, m1 , m2 ] = [i0 , m01 , m02 ] if and only (i, m1 , m2 ) = (i0 , m01 , m02 ).
Security: For any m∗1 ∈ M, m∗2 ∈ M , the following distributions are computationally indistinguishable:
(`∗0 , L∗0 , PP0 ) ≈ (`∗1 , L∗0 , PP1 ),
where rSetup is randomly chosen, PP = (PGenZero , PIncrement , PTransform , PisLess , PRetrieveTag , PRetrieveTags ) ←
Setup(GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags; rSetup ),
`∗0 ← PGenZero (m∗1 ), `∗1 ← PIncrement (`∗0 ), L∗0 ← PTransform (`∗0 , m∗2 ),
PPb ← Setup(GenZero[m∗1 ], Increment, Transform[(`∗b , m∗2 )], isLess, RetrieveTag, RetrieveTags; rSetup ).
6.2.2 Primitives required for the main construction, and their parameters
We require the primitives listed below. Note that these primitives can be constructed from iO, injective PRFs
(which in turn can be constructed from standard OWFs, [SW14]) and injective OWFs (which in turn can be
constructed from iO and standard OWFs, [BPW16]); thus it is enough to require iO and OWFs. By starting
with subexponentially-secure iO and OWFs, we can get subexponential security of these primitives.
Definitions can be found in section 5.
Notation. We denote security parameter by λ. We parametrize sizes in our construction by τ (λ), which is
the length of the first message in the protocol (also equal to the size of a tag for the level system, since we use
µ1 , µ2 as tags), and T (λ), which is an upper bound of the level system.
Injective PRFs with sparse image. As shown in [SW14], for any length l there exists a family of PRFs {Fk }λ
mapping l-sized inputs to 2l + λ-sized outputs, such that with probability at least 1 − 2−λ (over the choice of
the key), the PRF is injective. Note that PRF with these parameters has exponentially sparse image, i.e. a
59
randomly chosen element is in its image with probability 2−l−λ .
These PRFs are used in the construction of ACE and relaxed ACE.
Sparse extracting PRF. As shown in [SW14], for any length l, as long as the input has entropy at least
l ≥ τ /2 + 2λ + 2, there exists a family of extracting PRFs {Fk }λ mapping at least l-sized inputs to τ /2-sized
outputs, which are strong extractors with statistical distance at most 2−λ . It can be shown in a simple
reduction that applying a length-doubling prg to the output of such a PRF results in a (computationally)
extracting PRF, such that a random string is in its image with probability 2τ /2 .
These PRFs are used to compute the first two messages in the protocol.
ACE. As shown in [CHJV14], for any plaintext length l, there exists an ACE with ciphertexts of size 3l + λ
(as long as injective PRFs used are from l bits to 2l + λ bits).
ACE is used as the main encryption scheme (used to compute the third message of the protocol).
Relaxed ACE. As we show in the appendix C by modifying the construction of [CHJV14], for any plaintext
length l and suffix parameter t, there exists a relaxed ACE with ciphertexts of size (l − t + 1)(2l − t + λ) + λ
(as long as each injective PRF Fi , i = t, . . . , l, is from i bits to 2i + λ bits). . Further, ciphertexts of this ACE
are sparse, with ratio of ciphertexts at most 2−λ . Relaxed ACE is used as an encryption scheme to generate
fake sender and receiver randomness.
Length-doubling PRG. We use a prg from λ to 2λ bits. It is used in program RFake to randomize fake
randomness of the receiver. (In addition, as part of the construction of a sparse extracting PRF, we also use a
prg from τ (λ)/2 to τ (λ) bits).
Level system. We require a level system for any superpolynomial upper bound T and any sublinear tag size.
Length of variables as a function of the first message size τ and level upper bound T . Below we express
sizes in our construction (which in turn specify parameters of all primitives) as a function of the first message
size τ (λ) and the upper bound of the level system T (λ). We require that both τ (λ)and log T (λ) are sublinear
in λ. We assume that the plaintext of the deniable encryption scheme is one bit long. Somewhat abusing
notation, in this discussion we will be denoting the size of the ACE ciphertext of l-size input as ACE(l); size
of levels as |`|, |L|; size of the output of a prg as |prg|.
• |µ1 | = τ ;
• |µ2 | = τ ;
• |`| = |ACE(|µ1 | + log T )| = 3(τ + log T ) + λ = O(λ);
• |L| = |ACE(|µ1 | + |µ2 | + log T )| = 3(2τ + log T ) + λ = O(λ);
• |µ3 | = |ACE(1 + |µ1 | + |µ2 | + |L|)| = 3(1 + 2τ + 3(2τ + log T ) + λ) + λ = 3 + 24τ + 9 log T + 4λ =
O(λ);
• |s| = relaxedACE(1 + |µ1 | + |µ2 | + |µ3 | + |`|) (for suffix parameter t = |`|), thus the size is equal to
(1 + 2τ + (3 + 15τ + 9 log T + 4λ) + 1)(2(1 + 2τ + (3 + 15τ + 9 log T + 4λ) + 3(τ + log T ) + λ) −
(3(τ + log T ) + λ) + λ) + λ = (5 + 17τ + 9 log T + 4λ)(8 + 37τ + 21 log T + 20λ) + λ = O(λ2 );
• |r| = relaxedACE(1 + |µ1 | + |µ2 | + |µ3 | + |L| + |prg|) (for suffix parameter t = |prg|), thus the size is
equal to ((1+2τ +3+24τ +9 log T +4λ+3(2τ +log T )+λ+2λ)−2λ+1)(2(1+2τ +3+24τ +9 log T +
4λ+3(2τ +log T )+λ+2λ)−2λ+λ)+λ = (5+32τ +12 log T +5λ)(8+64τ +24 log T +13λ)+λ =
60
O(λ2 ).
Further, since in our construction of deniable encryption we use the first message µ1 as a tag for the level
system, we need a level system for upper bound T and tag size τ .
The size of the programs, and removing layers of iO. Note that the source code on fig. 18, fig. 19 includes
the description of obfuscated programs of the level system. In turn, the source code of programs of the level
system contains ACE keys which are again obfuscations of some other programs. Thus, the CRS contains
programs which have 3 layers of obfuscation.
However, this layering is only for convenience: it enables proving the security of component primitives (e.g.,
ACE and the level system) separately and then combine them into a bigger proof (e.g., of deniable encryption
or the level system). It is possible to prove security of our deniable encryption where programs of deniable
encryption are obfuscated only once. That is, programs of deniable encryption can use unobfuscated code of
the programs of the level system and ACE. However, to show security in this case, one would have to “unroll”
all proofs, i.e., substitute the proof of, say, ACE instead of each reduction to security of ACE in the main
proof. Needless to say, writing, and more importantly, verifying such a proof would be very onerous (certainly
from the perspective of the authors, who think of themselves as polynomially-bounded Turing machines).
Nevertheless, in appendix B we briefly explain why such a proof could be written. Intuitively, this holds
because of the following: let’s say in the proof of ACE we punctured the PRF and reduced it to security of
the obfuscation (of ACE source code). Then we can do the same reduction in the “unrolled” proof, since that
punctured PRF key, which is now a part of a source code of deniable encryption program, is still protected by
obfuscation on top of that program.
We state our theorem with a parameter σ representing the size of the source code of the programs of the
deniable encryption scheme. As long as our construction uses only one layer of iO, σ = O(λ3 ) (λ3 comes
from the fact that all programs of deniable encryption use keys of a relaxed ACE, which have size O(λ3 )
due to the fact each key consists of O(λ) PRF keys, these keys are punctured in the security proof, and each
punctured PRF key has size O(λ2 )).
6.2.3 Main theorem
Theorem 2. Assume the existence of the following primitives with parameters spicified above:
• SG, RG are extracting puncturable PRFs with sparse image. Further, these PRFs should have a
property that, given a punctured key, we can further puncture them at one more point;
• prg is a pseudorandom generator with a sparse image;
• Programs (GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags) are the programs of a
level system;
• sender-fake ACE (with keys EKS , DKS ) is a relaxed ACE with suffix parameter equal to the size of a
single-tag level of the level system; in addition, its ciphertexts should be sparse.
• receiver-fake ACE (with keys EKR , DKR ) is a relaxed ACE with suffix parameter equal to the image
length of a prg; in addition, its ciphertexts should be sparse.
• main ACE (with keys EK, DK);
• iO is a secure indistinguishability obfuscation for circuits of size σ = c · λ3 for some constant c;
61
Then the protocol of fig. 17 instantiated with the programs in fig. 18 and fig. 19 is a bideniable and
off-the-record deniable interactive encryption in the CRS model for 1-bit plaintexts. More specifically,
assuming that each primitive except the level system is (t(λ), ε(λ))-secure, and assuming the level system
for an upper bound T and tag size τ is O(t(λ), ε1 (λ, T, τ ))-secure, the resulting deniable encryption is
(t(λ), O(ε(λ)) + O(2−τ ) + ε1 (λ, T, τ ))-secure.
ε/2 ε2 /2 )
Corollary 1. Let T = 2λ , τ = λε/2 , and assume that all primitives in theorem 2 are (poly(λ), 2−Ω(λ )-
2
secure. Then the resulting deniable encryption is (poly(λ), 2 −Ω(λε /2 ) )-secure.
Encrypting longer plaintexts. Note that the syntax of the scheme allows to encrypt longer plaintexts.
However, for simplicity we define and prove deniability and off-the-record-deniability for 1-bit plaintexts
only. In appendix D we list the changes required to adapt the proof to support longer plaintexts. However,
this incurs additional security loss proportional to the |M|3 , the cube of the size of the plaintext space.
62
Program P1(s, m)
Hardwired values: decryption key DKS of sender-fake ACE, key kS of an extracting PRF SG.
1. Trapdoor step:
(a) out ← ACE.DecDKS (s); if out = 0 fail0 goto main step, else parse out as (m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m = m0 then return µ1 0 ;
2. Main step:
(a) Return µ1 ← SGkS (s, m).
Hardwired values: obfuscated code of algorithms P1, GenZero, Transform, RetrieveTag; decryption key
DKS of sender-fake ACE, encryption key EK of main ACE.
2. Trapdoor step:
(b) If m, µ1 , µ2 = m0 , µ1 0 , µ2 0 then return µ3 0 ;
(c) If m, µ1 = m0 , µ1 0 then:
i. If µ1 6= RetrieveTag(`0 ) then abort;
ii. Set L ← Transform(`0 , µ2 );
iii. Return µ3 ← ACE.EncEK (m, µ1 , µ2 , L);
3. Main step:
(a) Set L0 ← Transform(GenZero(µ1 ), µ2 );
(b) Return µ3 ← ACE.EncEK (m, µ1 , µ2 , L0 ).
Inputs: sender randomness s, real message m, fake plaintext m̂, protocol transcript µ1 , µ2 , µ3 .
Hardwired values: obfuscated code of algorithms P1, GenZero, Increment; encryption and decryption keys
EKS , DKS of sender-fake ACE.
2. Trapdoor step:
(b) If m, µ1 = m0 , µ1 0 then
i. Set `+1 ← Increment(`0 ); if `+1 = 0 fail0 then abort;
ii. Return ACE.EncEKS (m̂, µ1 , µ2 , µ3 , `+1 ).
3. Main step:
(a) Set `1 ← Increment(GenZero(µ1 ));
(b) Return ACE.EncEKS (m̂, µ1 , µ2 , µ3 , `1 ).
63
Program P2(r, µ1 )
Hardwired values: decryption key DKR of receiver-fake ACE, key kR of an extracting PRF RG.
1. Trapdoor step:
(a) out ← ACE.DecDKR (r); if out = 0 fail0 then goto main step, else parse out as
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
(b) If µ1 = µ1 0 then return µ2 0 ;
2. Main step:
(a) Return µ2 ← RGkR (r, µ1 ).
Hardwired values: obfuscated code of algorithms P2, isLess, RetrieveTags; decryption key DKR of receiver-
fake ACE, decryption key DK of the main ACE.
2. Trapdoor step:
(a) out ← ACE.DecDKR (r); if out0 = 0 fail0 then goto main step; else parse out0 as
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
(b) if µ1 , µ2 , µ3 = µ1 0 , µ2 0 , µ3 0 then return m0 ;
(c) out ← ACE.DecDK (µ3 ); if out00 = 0 fail0 then abort, else parse out00 as (m00 , µ1 00 , µ2 00 , L00 );
(d) If µ1 , µ2 = µ1 0 , µ2 0 then
i. If (µ1 0 , µ2 0 ) = (µ1 00 , µ2 00 ) = RetrieveTags(L00 ) and isLess(L0 , L00 ) = true then return m00 ;
ii. Else abort.
3. Main step:
(a) out ← ACE.DecDK (µ3 ); if out = 0 fail0 then abort, else parse out as (m00 , µ1 00 , µ2 00 , L00 );
(b) If (µ1 , µ2 ) = (µ1 00 , µ2 00 ) = RetrieveTags(L00 ) then return m00 ;
(c) Else abort.
Hardwired values: encryption key EKR of receiver-fake ACE, decryption key DK of the main ACE.
1. out ← ACE.DecDK (µ3 ); if out = 0 fail0 then abort, else parse out as (m00 , µ1 00 , µ2 00 , L00 );
2. Return r0 ← ACE.EncEKR (m̂, µ1 , µ2 , µ3 , L00 , prg(ρ)).
64
6.3 Proof overview
Correctness. Correctness follows from correctness of all underlying primitives and from the fact that
sender-fake and receiver-fake ACE are both sparse. More concretely, assume s∗ and r∗ are randomly
chosen coins of the sender and the receiver. Due to sparseness of ACE, s∗ (resp, r∗ ) is outside of the
image of sender-fake (resp., receiver-fake) ACE. Therefore program P1 on input s∗ , m executes the main
step and outputs µ1 ∗ = SGkS (s∗ , m), program P2 on input r∗ , µ1 ∗ executes the main step and outputs
µ2 ∗ = RGkR (r∗ , µ1 ∗ ), and program P3 on input s∗ , m, µ1 ∗ , µ2 ∗ executes the main step and outputs µ3 ∗ =
EncK (m, µ1 ∗ , µ2 ∗ , Transform(GenZero(µ1 ∗ ), µ2 ∗ )). In particular, the validity check passes since indeed
P1(s∗ , m) = µ1 ∗ .
Next, program Dec on input r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ executes the main step by decrypting µ3 ∗ and returning its
plaintext m. In particular, validity check passes, since P2(r∗ , µ1 ∗ ) = µ2 ∗ . Further, note that µ1 , µ2 which are
the input to Dec, µ1 00 , µ2 00 which are decrypted from µ3 ∗ , and the output of RetrieveTags(L00 ) are all equal
to µ1 ∗ , µ2 ∗ (recall that L00 = Transform(GenZero(µ1 ∗ ), µ2 ∗ )). Thus all checks in the main step of Dec pass
and the program outputs m.
Notation. m∗0 , m∗1 denote messages chosen by the adversary. s∗ , r∗ denote true (chosen at random) random
coins of the sender and receiver, respectively. µ1 ∗ , µ2 ∗ , µ3 ∗ denote the challenge transcript of the protocol,
which is either tr(s∗ , r∗ , m∗0 ) or tr(s∗ , r∗ , m∗1 ) depending on the hybrid. s0 , r0 denote fake random coins of
the sender and receiver, respectively. We write tr(s, r, m) to denote the communication in the protocol with
input m and randomness s and r.
By `∗0 we denote a single-tag level 0 with tag µ1 ∗ . By `∗1 we denote a single-tag level 1 with tag µ1 ∗ . By L∗0
we denote double-tag level 0 with tags µ1 ∗ , µ2 ∗ .
In addition, we will be using notation [val, µ1 ] and [val, µ1 , µ2 ] to denote single-tag and double-tag levels
with value val and tag µ1 (or, tags µ1 , µ2 ).
Main steps. We start with a distribution corresponding to transmitted plaintext m∗0 ∈ {0, 1} and real
randomness s∗ and r∗ presented to the adversary. More formally, we consider the following distribution:
HybA = (PP, m∗0 , m∗1 , s∗ , r∗ , tr(s∗ , r∗ , m∗0 )), where s∗ , r∗ are randomly chosen, and PP =
Setup(1λ ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup .
To prove security of our deniable encryption scheme, we proceed in the following steps:
1. Indistinguishability of explanations of the sender: we switch real (randomly chosen) s∗ to fake s0 ,
which encodes plaintext m∗0 , transcript µ1 ∗ , µ2 ∗ , µ3 ∗ , and level `∗ = [0, µ1 ∗ ], moving to the following
distribution:
HybB = (PP, m∗0 , m∗1 , s0 , r∗ , tr(s∗ , r∗ , m∗0 )), where s∗ , r∗ are randomly chosen, s0 =
ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), and PP = Setup(1λ ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for
randomly chosen rSetup .
The proof of this step is similar in spirit to the proof of a sender-deniable encryption of Sahai and
Waters [SW14], and relies on the fact that all relevant programs, given s∗ or s0 as input, behave in the
same way for any choice of remaining inputs.
2. Indistinguishability of explanations of the receiver: we switch real (randomly chosen) r∗ to fake
r0 , which encodes plaintext m∗0 , transcript µ1 ∗ , µ2 ∗ , µ3 ∗ , and level L∗ = [0, µ1 ∗ , µ2 ∗ ], moving to the
65
following distribution:
HybC = (PP, m∗0 , m∗1 , s0 , r0 , tr(s∗ , r∗ , m∗0 )), where s∗ , r∗ are randomly chosen, s0 =
ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), r0 = ACE.EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ )) for randomly
chosen ρ∗ , and PP = Setup(1λ ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup .
Unlike the previous step, here there exist inputs such that program Dec, when run on these inputs and
r∗ or r0 , produces different outputs. However, such inputs are hard to find. Thus, in security proof of
this step we first use properties of ACE to “eliminate” bad inputs (i.e. to make the programs reject
them), then run Sahai-Waters-like proof similar to the previous step, and finally use ACE to bring bad
inputs back and restore the programs.
3. Semantic security: we switch the transcript from encrypting m∗0 to encrypting m∗1 , moving to the
HybD = (PP, m∗0 , m∗1 , s0 , r0 , tr(s∗ , r∗ , m∗1 )), where s∗ , r∗ are randomly chosen, s0 =
Proving security of this step involves the following. First, similar to the previous step, we “eliminate”
a ciphertext µ3 ∗ = ACE.EncEK (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), making all programs reject it (note that this
ciphertext is “complementary” to the challenge ciphertext µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ),
meaning it encrypts the opposite bit). This allows us to modify program Dec such that decryption key
DK is not used to decrypt µ3 ∗ , µ3 ∗ . Then we use security of ACE to switch µ3 ∗ from encrypting m∗0 to
m∗1 , and then revert all previous changes.
4. Indistinguishability of levels: we switch the level encoded in s0 from `∗0 = [0, µ1 ∗ ] to `∗1 = [1, µ1 ∗ ]
(while keeping L∗0 = [0, µ1 ∗ , µ2 ∗ ] the same), moving to the following distribution:
HybE = (PP, m∗0 , m∗1 , s0 , r0 , tr(s∗ , r∗ , m∗1 )), where s∗ , r∗ are randomly chosen, s0 =
To prove security of this step, we first use security of ACE to eliminate some bad inputs. After this,
we can modify programs of deniable encryption scheme in such a way that they only use punctured
version of the programs of the level system. Then we invoke security of the level system and finally
revert previous changes.
Finally, we argue that, except with negligible probability, s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ) is the
same as s0 = SFake(s∗ , m∗1 , m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ) (indeed, this is what SFake outputs except for a negli-
gibly small fraction of inputs). In addition, since r0 = ACE.EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ )) =
RFake(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ; ρ∗ ), we thus obtain the following distribution:
HybF = (PP, m∗0 , m∗1 , s0 , r0 , tr(s∗ , r∗ , m∗1 )), where s∗ , r∗ are randomly chosen, s0 =
SFake(s , m1 , m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), r0 = RFake(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ; ρ∗ ) for randomly chosen ρ∗ , and
∗ ∗
PP = Setup(1λ ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup .
Note that this distribution corresponds to the execution of the protocol with plaintext m∗1 and fake randomness
s0 , r0 which makes this transcript look consistent with plaintext m∗0 , and thus we proved security of our
deniable encryption.
In section 8.1 for each one of the four steps we present a list of hybrids with a brief explanation of why
66
indistinguishability between each hybrid holds. Formal security reductions can be found in section 8.2.
Off-the-record deniability. Proof of off-the-record deniability of our scheme follows the same major four
steps, but in a different order and with slightly different distributions. In section 9 we explain how to modify
the proof of deniability from section 8 to turn it into a proof of off-the-record deniability.
7 Level System
This section presents our level system construction and security proof. Level systems were already defined in
section 6.2.1, as a building block for our deniable encryption protocol. We repeat both the intuitive motivation
and formal definition here, in order to keep this section self-contained for any readers who may read it
separately. (We believe the level system may be a primitive of independent interest.) Readers wishing to skip
the definitional material and go straight to the construction should skip to section 7.2.
Motivation and overview. The idea of a level system is to have an encryption scheme which allows to
increment ciphertexts and compare them homomorphically. However, in order for this encryption to be useful
in our construction of deniable protocol, we require the following properties of this "encryption scheme":28
• There should be two types of ciphertexts, which we call single-tag levels and double-tag levels;
• A single-tag level is an encryption of number i between 0 and upper bound T , together with some
string m1 ∈ M1 , which we call a tag. (In our construction of deniable encryption, we use the first
message of the deniable protocol as a tag. This is done to “tie” the level to the instance of the protocol).
• A double-tag level is an encryption of number i between 0 and upper bound T , together with two tags
m1 ∈ M1 , m2 ∈ M2 . (In our construction of deniable encryption, we use the first and the second
messages of the deniable protocol as tags. This, again, is done to “tie” the level to the instance of the
protocol).
• It should be possible to perform the following operations:
1. Sample a single-tag level 0 for any tag m1 ;
2. Homomorphically increment the value inside any single-tag level (keeping its tag the same);
3. Transform any single-tag level into a double-tag level, for any second tag m2 (the value and the
first tag remain the same);
4. Compare two double-tag levels, as long as their both tags are the same;
5. Given any level, retrieve its tag(s).
Notation. We use notation [i, m1 ] to denote a single-tag level with value i and tag m1 . We also use `i to
denote a single-tag level with value i, when the tag is clear from the context.
We use notation [i, m1 , m2 ] to denote a double-tag level with value i and tags m1 , m2 . We also use Li to
denote a double-tag level with value i, when its tags are clear from the context.
Security property. The security requirement of a level system is that it should be hard to distinguish between
`∗0 = [0, m∗1 ], L∗0 = [0, m∗1 , m∗2 ] and `∗1 = [1, m∗1 ], L∗0 = [0, m∗1 , m∗2 ], even given (limited) ability to perform
homomorphic operations described above.
28
Note that even though we call it encryption, we don’t require this primitive to have decryption.
67
This will be used in the proof of security of deniable encryption scheme as follows. Recall that in that proof
we need to start with the real transcript and real randomness s, r (having levels L∗0 , `∗0 , L∗0 , respectively) and
eventually switch to the (same) real transcript but fake randomness s0 , r0 (with levels L∗0 , `∗1 , L∗0 ). We can use
security of the level system in the proof of deniable encryption as follows: given challenge `∗b , L∗0 (where
`∗b = [b, m∗1 ], b ∈ {0, 1}, L∗0 = [0, m∗1 , m∗2 ]), we use `∗b inside fake s and we use L∗0 inside the transcript and
fake r. Since security of levels only holds when programs are punctured, in the proof of deniable encryption
we first move to a hybrid with only punctured level programs, and then invoke security of the level system.
7.1 Definition
We start with describing the syntax of a level system for tag space M and upper bound T :
• Setup(1λ ; T ; GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags; rSetup ) → PP =
(PGenZero , PIncrement , PTransform , PisLess , PRetrieveTag , PRetrieveTags ) is a randomized algorithm which
takes as input security parameter, the largest allowed level T , description of programs, and randomness.
It uses random coins to sample all necessary keys for each program29 , and outputs those programs
obfuscated under iO.
• GenZero(m1 ) → ` is a deterministic algorithm which takes message m1 ∈ M as input and outputs a
string ` = [0, m1 ], which is a single-tag level with tag m1 and value 0. We also require that there exists
a punctured version of this algorithm denoted GenZero[m∗1 ](m1 ) which outputs 0 fail0 on input m∗1 .
• Increment(`) → `0 is a deterministic algorithm which takes a single-tag level ` = [i, m1 ] for some
0 ≤ i ≤ T − 1, m1 ∈ M , and outputs a single-tag level with the same tag and incremented value, i.e.
`0 = [i + 1, m1 ]. If i ≥ T , it instead outputs 0 fail0 .
• Transform(`, m2 ) → ` is a deterministic algorithm which takes a single-tag level ` = [i, m1 ] for some
0 ≤ i ≤ T, m1 ∈ M , and some message m2 ∈ M , and outputs L = [i, m1 , m2 ], which is a double-tag
level with tags m1 , m2 , and value i. We also require that there exists a punctured version of this
algorithm denoted Transform[(`∗ , m∗2 )](`, m2 ) which outputs 0 fail0 on input (`∗ , m∗2 ).
• isLess(L0 , L00 ) → out ∈ {true, false} is a deterministic algorithm which takes as input two double-tag
levels L0 = [i0 , m01 , m02 ] and L00 = [i00 , m001 , m002 ]. If (m01 , m02 ) 6= (m001 , m002 ), then it outputs 0 fail0 .
Otherwise it outputs true if i0 < i00 and false if i0 ≥ i00 .
• RetrieveTag(`) → m1 is a deterministic algorithm which takes a single-tag level ` and outputs its tag.
• RetrieveTags(L) → (m1 , m2 ) is a deterministic algorithm which takes a double-tag level L and
outputs both tags.
We emphasize that all programs except Setup are deterministic.
Definition 11. A tuple of parametrized, deterministic30 algorithms
(GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags, GenZero[m∗1 ], Transform[l∗ , m∗2 ])

29
We assume that Setup is implicitly given generation algorithms for all underlying primitives of the programs.
30
We prefer to use the notion of parametrized, deterministic algorithms to keep the definition simple. To formally define this
notion, consider a randomized Turing machine with the restriction that the number of random bits written on its random tape is fixed
and independent of the input (only dependent on security parameter λ). Such a Turing machine can first use these random coins to
generate all necessary parameters (e.g., keys) and then run the actual code of the algorithm using generated parameters. In particular,
we assume that this TM has the code of all necessary generation algorithms.
68
is a level system for tag space M , if algorithms have syntax described above, and the correctness and security
properties described below hold.
Notation: Let T be superpolynomial in λ, and PP = (PGenZero , PIncrement , PTransform , PisLess , PRetrieveTag ,
PRetrieveTags ) ← Setup(1λ ; T ; GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags; rSetup )
for randomly chosen rSetup .
Next, let m∗1 ∈ M , m∗2 ∈ M , and let `∗ be an arbitrary string (not necessarily a level). Let
PP0 = (P0GenZero , P0Increment , P0Transform , P0isLess , P0RetrieveTag , P0RetrieveTags ) ← Setup(1λ , T, GenZero[m∗1 ],
Increment, Transform[(`∗ , m∗2 )], isLess, RetrieveTag, RetrieveTags; rSetup ) with the same randomness
rSetup as above.
For any fixed rSetup consider the following notation:
• For every m1 ∈ M denote [0, m1 ] = PGenZero (m1 );
• For every m1 ∈ M , 1 ≤ i ≤ T denote [i, m] = PIncrement ([i − 1, m]);
• For every m2 ∈ M and every [i, m1 ], where 0 ≤ i ≤ T, m1 ∈ M , denote [i, m1 , m2 ] =
PTransform ([i, m1 ], m2 ).
Correctness: The following properties should hold, except with negligible probability over the choice of
rSetup :
• Uniqueness of levels:
– For all ` ∈
/ {[i, m1 ] : 0 ≤ i ≤ T, m1 ∈ M }:
∗ PIncrement (`) = 0 fail0 ;
∗ PTransform (`, m2 ) = 0 fail0 for any m2 ∈ M ;
∗ PRetrieveTag (`) = 0 fail0 .
– For all L ∈
/ {[i, m1 , m2 ] : 0 ≤ i ≤ T, m1 ∈ M, m2 ∈ M }:
∗ PisLess (L, L0 ) = 0 fail0 , PisLess (L0 , L) = 0 fail0 , for any string L0 ;
∗ PRetrieveTags (L) = 0 fail0 .
• Upper bound is respected: For every m1 ∈ M PIncrement ([T, m1 ]) = 0 fail0 .
• Correctness of comparison: For every m1 , m2 ∈ M and for every 0 ≤ i, j ≤ T :
– PisLess ([i, m1 , m2 ], [j, m1 , m2 ]) = true for i < j,
– PisLess ([i, m1 , m2 ], [j, m1 , m2 ]) = false for i ≥ j.
• Comparison is possible only on matching levels: If (m01 , m02 ) 6= (m001 , m002 ), then
PisLess ([i, m01 , m02 ], [j, m001 , m002 ]) = 0 fail0 for all i, j.
• Correctness of tags retrieval: For every m1 , m2 ∈ M and for every 0 ≤ i ≤ T :
– PRetrieveTag ([i, m1 ]) = m1 ,
– PRetrieveTags ([i, m1 , m2 ]) = (m1 , m2 ).
• Functionality is preserved under puncturing:
69
– PGenZero (m) = P0GenZero (m) for all m ∈ M , m 6= m∗1 ;
– PIncrement (`) = P0Increment (`) for all strings `;
– PTransform (`, m2 ) = P0Transform (`, m2 ) for all strings l and for all m2 ∈ M , except (`∗ , m∗2 );
– PisLess (L0 , L00 ) = P0isLess (L00 , L00 ) for all strings L0 , L00 ;
– PRetrieveTag (`) = P0RetrieveTag (`) for all strings `;
– PRetrieveTags (L) = P0RetrieveTags (L) for all strings L.
Note that it follows from the correctness properties that [i, m1 ] = [i0 , m01 ] if and only (i, m1 ) = (i0 , m01 ), and
[i, m1 , m2 ] = [i0 , m01 , m02 ] if and only (i, m1 , m2 ) = (i0 , m01 , m02 ).
Security: For any m∗1 ∈ M, m∗2 ∈ M , the following distributions are computationally indistinguishable:
(`∗0 , L∗0 , PP0 ) ≈ (`∗1 , L∗0 , PP1 ),
where rSetup is randomly chosen, PP = (PGenZero , PIncrement , PTransform , PisLess , PRetrieveTag , PRetrieveTags ) ←
Setup(GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags; rSetup ),
`∗0 ← PGenZero (m∗1 ), `∗1 ← PIncrement (`∗0 ), L∗0 ← PTransform (`∗0 , m∗2 ),
PPb ← Setup(GenZero[m∗1 ], Increment, Transform[(`∗b , m∗2 )], isLess, RetrieveTag, RetrieveTags; rSetup ).
7.2 Construction
We implement a level system in a natural way: we let levels to be ciphertexts (encrypting the value and the
tag in a single-tag level, and the value and both tags in a double-tag level) under special encryption scheme
called asymmetric constrained encryption, or ACE (8). For single-tag and double-tag levels we use two
different instances of ACE, with keys EK1 , DK1 for single-tag levels and EK2 , DK2 for double-tag levels.
We let programs of the level system (fig. 20) perform required “homomorphic” operations in a natural way,
by decrypting the ciphertext and learning its value and tag, checking validity of the operation, and then
outputting the result (reencrypted, when applicable).
Theorem 3. Let:
• λ be a security parameter;
• iO be (poly(λ), 2−Ω(νiO (λ)) )-secure indistinguishability obfuscation;
• ACE be an asymmetric constrained encryption scheme with (poly(λ), 2−Ω(νACE.Indist (λ)) )-secure indis-
tinguishability of ciphertexts and (poly(λ), 2−Ω(νACE.ConstrDec (λ)) ) security of decryption;
0 0
• g be a (2O(νOWF (λ )) , 2−Ω(νOWF (λ )) )-secure injective one-way function mapping λ0 = log T (λ)-bit
inputs to poly(λ0 )-bit outputs;
• γ(λ) be a function satisfying the following conditions:
– γ(λ) = O(νiO (λ));
– 2γ(λ) poly(λ) log T = O(2νOWF (log T ) );
Then the scheme described on fig. 20 is a level system for upper bound T (λ), tags of length τ (λ), which is
70
(poly(λ), 2−νlevels (λ) )-secure, where 2−νlevels (λ) is equal to the following:
2−Ω(γ(λ)) +T −1 (λ)+T (λ)2−Ω(νACE.ConstrDec (λ)) +2τ (λ) (T (λ)·2−Ω(νiO (λ)) +T (λ)·2−Ω(νACE.Indist (λ)) +2−Ω(νACE.ConstrDec (λ)) )).
Note: Here γ(λ) represents distinguishing advantage between two obfuscated programs differing on one
input (which is a preimage of the OWF g). The two conditions on γ are set to satisfy the requirements of
theorem 1, and say that the inverter’s size is small enough, and that distinguishing advantage is big enough
compared to the indistinguishability guarantee of iO.
By using subexponentially-secure primitives, we obtain the following corollary:
Corollary 2. Let:
• λ be a security parameter;
ε
• iO be (poly(λ), 2−Ω(λ ) )-secure indistinguishability obfuscation;
ε
• ACE be an asymmetric constrained encryption scheme with (poly(λ), 2−Ω(λ ) )-secure indistinguisha-
ε
bility of ciphertexts and (poly(λ), 2−Ω(λ ) ) security of decryption;
0ε 0ε
• g be a (2Ω(λ ) , 2−Ω(λ ) )-secure injective one-way function mapping λ0 = λε/2 -bit inputs to poly(λ0 )-
bit outputs;
2 /2
• γ(λ) = λε ;
ε/2
Then the scheme described on fig. 20 is a level system for upper bound T (λ) = 2λ , tags of length
2
τ (λ) = λε/2 , which is (poly(λ), 2 −Ω(λε /2 ) )-secure.
7.3 Overview of the proof

Correctness. Correctness properties of our level scheme immediately follow from statistical correctness of
iO and correctness and uniqueness properties of ACE.
Overview of security proof. For security, we first informally describe the structure of the proof, and then give
the sequence of hybrids in section 7.4 and security reductions in section 7.5. Recall that security definition
requires that (`∗0 , L∗0 , PP0 ) ≈ (`∗1 , L∗0 , PP1 ), where PPb are punctured, obfuscated programs. Starting from
the distribution (`∗0 , L∗0 , PP0 ), our proof proceeds in 3 major steps:
1. Switching from `∗0 = [0, m∗1 ] to `∗1 = [1, m∗1 ]. Programs GenZero and Increment define a chain
[0, m1 ] → [1, m1 ] → . . . → [T, m1 ] → ⊥ for each tag m1 . In a sequence of hybrids we switch from
[0, m∗1 ] to [1, m∗1 ] by switching the whole chain from [0, m∗1 ] → [1, m∗1 ] → . . . → [T, m∗1 ] → ⊥ to
[1, m∗1 ] → [2, m∗1 ] → . . . → [T + 1, m∗1 ] → ⊥.
As a result of this change, `∗0 is switched to `∗1 as desired (and in particular, the punctured point in
Transform is switched from `∗0 to `∗1 as well). However, this change also affects the programs in the
following two ways (resulting programs are in fig. 22) :
• Wrong upper bound: programs Increment, Transform, and RetrieveTag now have an upper
bound T + 1 (instead of T ) for the case m1 = m∗1 ,
• Incorrect reencryption: program Transform, given [i, m∗1 ] for 0 ≤ i ≤ T + 1, outputs [i −
1, m∗1 , m2 ] instead of [i, m∗1 , m2 ].
71
Program GenZero(m1 )
Inputs: tag m1 ∈ M .
Hardwired values: encryption key EK1 of ACE.
1. output l ← ACE.EncEK1 (0, m1 ).
Program Increment(l)
Inputs: single-tag level l
Hardwired values: encryption and decryption keys EK1 , DK1 of ACE, upper bound T .
1. out ← ACE.DecDK1 (l); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 ).
2. If i ≥ T or i < 0 then output 0 fail0 ;
3. output l+1 ← ACE.EncEK1 (i + 1, m1 ).
Program Transform(l, m2 )
Inputs: single-tag level l, tag m2 ∈ M
Hardwired values: decryption key DK1 of ACE, encryption key EK2 of ACE, upper bound T .
2. If i > T or i < 0 then output 0 fail0 ;
3. output L ← ACE.EncEK2 (i, m1 , m2 ).
Program isLess(L0 , L00 )
Inputs: double-tag levels L0 , L00
Hardwired values: decryption key DK2 of ACE, upper bound T .
1. out0 ← ACE.DecDK2 (L0 ); if out0 = 0 fail0 then output 0 fail0 ; else parse out0 as (i0 , m01 , m02 ).
3. If i0 > T or i00 > T or or i0 < 0 or i00 < 0 (m01 , m02 ) 6= (m001 , m002 ) then output 0 fail0 ;
4. If i0 < i00 then output true, else output false.
Program RetrieveTag(l)
3. Output m1 .
Program RetrieveTags(L)
Inputs: double-tag level L
1. out ← ACE.DecDK2 (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
3. Output m1 , m2 .
Figure 20: Programs in our level system
72
2. Restoring correct upper bound in Increment, Transform, and RetrieveTag. In a sequence of
hybrids we change the wrong upper bound T + 1 to the correct upper bound T in relevant programs.
Resulting programs are in fig. 23. This part of the proof uses ideas from [BPR15] to argue that
the adversary can never reach the upper bound and thus the upper bound can be decreased by 1
indistinguishably.
3. Restoring correct reencryption in Transform. In a sequence of hybrids we make program Transform
output the correct value [i, m∗1 , m2 ], instead of [i − 1, m∗1 , m2 ], for all 0 ≤ i ≤ T and for all m2 .
The proof of this step follows a by-now-standard puncturing technique (which allows to change the
ciphertext in a PRF-based encryption from one plaintext to another), except that we also have to deal
with program isLess which has decryption keys inside it. Intuitively, the proof still goes through even
despite those decryption keys, because isLess only reveals the result of the comparison, which is not
affected by our change.
At the end of this step, we obtain original punctured programs, thus proving security of our level
system.
Security loss. Steps 1 and 2 require number of hybrids proportional to the upper bound T , and step 3 requires
number of hybrids proportional to 2|m2 | T . In addition, in the proof of step 2 we also lose 1/T , thus requiring
T and 2|m2 | to be superpolynomial.
Now we describe the proof in each step in more detail. While the reader can safely skip this part and directly
go to the list of hybrids (section 7.4), we suggest that the readers familiar with iO techniques take a look at
this informal presentation first, since it outlines, in a succinct way, the logic behind the somewhat lengthy
sequence of hybrids.
Step 1: Switching `∗ from [0, m∗1 ] to [1, m∗1 ].
1. We first change the chain to [0, m∗1 ] → [1, m∗1 ] → . . . → [T − 1, m∗1 ] → [T + 1, m∗1 ] → ⊥, creating
a gap between T − 1 and T + 1. This is done by first hardwiring the ciphertext lT∗ = [T, m∗1 ] into
relevant programs, then puncturing keys corresponding to both [T, m∗1 ] and [T + 1, m∗1 ] (the latter
can be punctured since they are never used due to upper bound T ), and finally switching hardwired
ciphertext to lT∗ +1 = [T + 1, m∗1 ] and unpuncturing keys at [T + 1, m∗1 ]31 .
Note that the keys remain punctured at the point [T, m∗1 ], which essentially means that from the point
of view of programs there doesn’t exist a valid encryption of (T, m∗1 ).
Finally, note that switching the hardwired ciphertext from [T, m∗1 ] to [T + 1, m∗1 ] changes the upper
bound from T to T + 1 in programs Transform and RetrieveTag.
2. Then in a sequence of hybrids we move the gap from T down to 0 a follows. Let j-th hybrid be a
hybrid where the gap is at j + 1, i.e. Increment defines a chain [0, m∗1 ] → [1, m∗1 ] → . . . → [j, m∗1 ] →
[j + 2, m∗1 ] → . . . → [T, m∗1 ] → [T + 1, m∗1 ], and keys are punctured at [j + 1, m∗1 ], meaning that there
doesn’t exist a valid encryption of (j + 1, m∗1 ). We move the gap to j by first hardwiring the ciphertext
lj∗ = [j, m∗1 ] into relevant programs, then puncturing keys corresponding to [j, m∗1 ] (recall that keys are
already punctured at [j + 1, m∗1 ]), and finally switching hardwired ciphertext to lj+1
∗ = [j + 1, m∗1 ] and
unpuncturing keys at [j + 1, m1 ]. ∗
31
Note that it is crucial for switching the ciphertext that keys are punctured at both points, and only one of the two ciphertexts is
present in the distribution.
73
Note that the keys remain punctured at the point [j, m∗1 ], enabling the next step.
In addition, note that in the first step the upper bound in Increment is switched from T to T + 1. This
is due to the fact that this step switches the hardwired ciphertext from [T − 1, m∗1 ] to [T, m∗1 ], and due
to the fact that there is a hardwired instruction to output [T + 1, m∗1 ], given hardwired ciphertext as
input (indeed, while in the original Increment input [T, m∗1 ] results in ⊥, after the change input [T, m∗1 ]
results in [T + 1, m∗1 ]).
Finally, note that the last step switches challenge level `∗0 = [0, m∗1 ] to `∗1 = [1, m∗1 ].
3. As a result, we obtain Increment which defines a chain 1 → 2 → . . . → T → T + 1 → ⊥ for the tag
m∗1 , and keys are punctured at [0, m∗1 ]. We remove the puncturing using the fact that keys for [0, m∗1 ]
are never used, since GenZero doesn’t have to work on input m∗1 .
Resulting programs are in fig. 22.
Step 2: Restoring the correct upper bound of Increment, Transform, and RetrieveTag on m∗1 . Intu-
itively, nobody can tell whether these programs have an upper bound T or T + 1, since the only way to test
this is to check if, starting with level [1, m∗1 ], Increment fails after T − 1 or T executions, which requires
superpolynomial time to compute. To turn this intuition into a formal argument, we follow the proof of
[BPR15]:
1. We cut the chain 1 → 2 → . . . → T → T + 1 → ⊥ (here we omit the tag m∗1 for simplicity and
compactness) at a random point as follows. We add a check “if prg(i) = S then abort” to Increment,
where S is randomly chosen. If the prg is expanding enough, then with overwhelming probability S
is outside of the prg image, and adding this line doesn’t change the functionality. However, next we
change S to be prg(s) for some random s, which cuts the line at point s: that is, Increment now defines
the chain 1 → . . . s → ⊥, s + 1 → . . . → T + 1 → ⊥.
2. In a sequence of hybrids we cut the line in all points after s, obtaining the following chain: 1 → . . . →
s → ⊥, s + 1 → ⊥, s + 2 → ⊥, . . ., T → ⊥, T + 1 → ⊥. Intuitively, once Increment outputs ⊥
given [s, m∗1 ], it becomes impossible for an adversary to obtain [s + 1, m∗1 ], and therefore behavior of
Increment at [s + 1, m∗1 ] can be changed to ⊥ as well. The process can be continued. This intuition is
captured by the security of constrained decryption of ACE.
As the result, we move to a hybrid where valid encryptions of (s + 1, m∗1 ), . . . , (T + 1, m∗1 ) do not
exist.
3. Then we can move the upper bound from T + 1 back to T for the case m1 = m∗1 , since programs
output ⊥ on input [T + 1, m∗1 ] anyway. Thus, changing T + 1 to T doesn’t affect the functionality of
the programs.
4. Then we can reverse all previous steps, restore the chain and eventually get original programs with
correct upper bound T (except Transform, which now has the correct upper bound T , but still has
incorrect behavior on inputs of the form ([i, m∗1 ], m2 )).
Resulting programs are in fig. 23.
Step 3: Restoring the correct reencryption behaviour in Transform. Note that TransformB
(fig. 23) defines the set of outputs [0, m1 , m2 ], . . . , [T, m1 , m2 ] (corresponding to inputs
([0, m1 ], m2 ), . . . , ([T, m1 ], m2 )) for the case m1 6= m∗1 , and the set of outputs [−1, m∗1 , m2 ], . . . , [T −
1, m∗1 , m2 ] (corresponding to inputs ([0, m∗1 ], m2 ), . . . , ([T, m∗1 ], m2 )) for the case m1 6= m∗1 . We change
74
the set of outputs from [−1, m∗1 , m2 ], . . . , [T − 1, m∗1 , m2 ] to [0, m∗1 , m2 ], . . . , [T, m∗1 , m2 ] by running the
following sequence of steps for each possible second tag m2 :
1. We first change the set of outputs from [−1, m∗1 , m2 ], . . . , [T − 1, m∗1 , m2 ] to [−1, m∗1 , m2 ], . . . , [T −
2, m∗1 , m2 ], [T, m∗1 , m2 ], creating a gap between T − 2 and T . This is done by first hardwiring the
ciphertext L∗T −1 = [T −1, m∗1 , m2 ] into relevant programs (Transform, isLess, and RetrieveTags), then
puncturing keys corresponding to both [T − 1, m∗1 , m2 ] and [T, m∗1 , m2 ] (the latter can be punctured
since they are never used due to the upper bound T ), and finally switching hardwired ciphertext to
L∗T = [T, m∗1 , m2 ] and unpuncturing keys at [T, m∗1 , m2 ]32 .
Note that the keys remain punctured at the point [T − 1, m∗1 , m2 ], which essentially means that from
the point of view of programs there doesn’t exist a valid encryption of (T − 1, m∗1 , m2 ).
2. Then in a sequence of hybrids we move the gap from T − 1 down to −1 a follows. Let j-th hybrid
be a hybrid where the gap is at j + 1, i.e. Transform outputs [−1, m∗1 , m2 ], . . . , [j, m∗1 , m2 ], [j +
2, m∗1 , m2 ], . . . , [T, m∗1 , m2 ], and keys are punctured at [j + 1, m∗1 , m2 ], meaning that there doesn’t
exist a valid encryption of (j + 1, m∗1 , m2 ). We move the gap to j by first hardwiring the ciphertext
L∗j = [j, m∗1 , m2 ] into relevant programs, then puncturing keys corresponding to [j, m∗1 , m2 ] (recall
that keys are already punctured at [j + 1, m∗1 , m2 ]), and finally switching hardwired ciphertext to
L∗j+1 = [j + 1, m∗1 , m2 ] and unpuncturing keys at [j + 1, m∗1 , m2 ].
Note that the keys remain punctured at the point [j, m∗1 , m2 ], enabling the next step.
An important property of program isLess which enables switching [j, m∗1 , m2 ] to [j + 1, m∗1 , m2 ] at
each step is that isLess treats both [j, m∗1 , m2 ] and [j + 1, m∗1 , m2 ] in the same way. That is, both
[j, m∗1 , m2 ] and [j + 1, m∗1 , m2 ] are larger than [0, m∗1 , m2 ], . . . , [j − 1, m∗1 , m2 ], and both are smaller
than [j + 2, m∗1 , m2 ], . . . , [T, m∗1 , m2 ]. Finally, both are equal when compared to themselves. The only
difference in the output could have occured on inputs ([j, m∗1 , m2 ], [j + 1, m∗1 , m2 ]) (resulting in isLess
returning true) and ([j + 1, m∗1 , m2 ], [j, m∗1 , m2 ]) (resulting in isLess returning false); however, in each
of the two hybrids only one of the two values “exists” and the other is punctured out, thus forcing
isLess to output ⊥ on these inputs. This allows us to “swap" [j, m∗1 , m2 ] and [j + 1, m∗1 , m2 ] without
changing the functionality of the programs.
Finally, note that we don’t perform two last steps, i.e. switching from 0 to 1 and from −1 to 0,
for the case m2 = m∗2 (indeed, that would switch the challenge value from L∗0 = [0, m∗1 , m∗2 ] to
L∗1 = [1, m∗1 , m∗2 ], but it has to remain L∗0 = [0, m∗1 , m∗2 ] in both experiments of the security game). In
fact, we don’t have to switch from 0 to 1 since Transform is punctured at [l1∗ , m∗2 ] and outputs 0 fail0 on
this input anyway. Further, since [0, m∗1 ] is hard to obtain for the adversary, we argue that Transform
may be indistinguishably changed from outputting [−1, m∗1 , m∗2 ] to [0, m∗1 , m∗2 ] on input [0, m∗1 ], m∗2
(again, this intuition is formalized using security of the constrained key of the ACE).
32
Note that it is crucial for switching the ciphertext that keys are punctured at both points, and only one of the two ciphertexts is
present in the distribution.
75
Programs in HybA
Program GenZero[m∗1 ](m1 )
Hardwired values: encryption key EK1 of ACE, tag m∗1 .
1. If m1 = m∗1 then output 0 fail0 ;
Program Transform[(l0∗ , m∗2 )](l, m2 )
Hardwired values: decryption key DK1 of ACE, encryption key EK2 of ACE, single-tag level l0∗ =
ACE.EncEK1 (0, m∗1 ), tag m∗2 , upper bound T .
1. If (l, m2 ) = (l0∗ , m∗2 ) then return 0 fail0 ;
2. out ← ACE.DecDK1 (l); if out = 0 fail0 then return 0 fail0 ; else parse out as (i, m1 ).
3. If i > T or i < 0 then return 0 fail0 ;
4. return L ← ACE.EncEK2 (i, m1 , m2 ).
3. If i0 > T or i00 > T or i0 < 0 or i00 < 0 or (m01 , m02 ) 6= (m001 , m002 ) then output 0 fail0 ;
3. Output m1 .
3. Output m1 , m2 .
Figure 21: Programs in HybA . In addition, in this hybrid the adversary gets l0∗ = ACE.EncEK1 (0, m∗1 ),
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
76
Programs in HybB
Program GenZeroB [m∗1 ](m1 )
Program IncrementB (l)
Hardwired values: encryption and decryption keys EK1 , DK1 of ACE, tag m∗1 , upper bound T .
2. If m1 = m∗1 and (i ≥ T + 1 or i < 0) then output 0 fail0 ;
3. If m1 6= m∗1 and (i ≥ T or i < 0) then output 0 fail0 ;
Program TransformB [(l1∗ , m∗2 )](l, m2 )
ACE.EncEK1 (1, m∗1 ), tag m∗1 , tag m∗2 , upper bound T .
3. If m1 = m∗1 :
(a) If i > T + 1 or i < 0 then return 0 fail0 ;
(b) return L ← ACE.EncEK2 (i − 1, m1 , m2 );
4. If m1 6= m∗1 :
(a) If i > T or i < 0 then return 0 fail0 ;
(b) return L ← ACE.EncEK2 (i, m1 , m2 ).
Program isLessB (L0 , L00 )
Program RetrieveTagB (l)
Hardwired values: decryption key DK1 of ACE, tag m∗1 , upper bound T .
2. If m1 = m∗1 and (i > T + 1 or i < 0) then output 0 fail0 ;
3. If m1 6= m∗1 and (i > T or i < 0) then output 0 fail0 ;
4. Output m1 .
Program RetrieveTagsB (L)
3. Output m1 , m2 .
Figure 22: Programs in HybB . In addition, in this hybrid the adversary gets l1∗ = ACE.EncEK1 (1, m∗1 ),
L∗ = ACE.EncEK (0, m∗ , m∗ ). 77
0 2 1 2
Programs in HybC .
Program GenZeroC [m∗1 ](m1 )
Program IncrementC (l)
Program TransformC [(l1∗ , m∗2 )](l, m2 )
4. If m1 = m∗1 return L ← ACE.EncEK2 (i − 1, m1 , m2 );
5. Return L ← ACE.EncEK2 (i, m1 , m2 ).
Program isLessC (L0 , L00 )
Program RetrieveTagC (l)
3. Output m1 .
Program RetrieveTagsC (L)
3. Output m1 , m2 .
Figure 23: Programs in HybC . In addition, in this hybrid the adversary gets l1∗ = ACE.EncEK1 (1, m∗1 ),
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
78
Programs in HybD
Program GenZero[m∗1 ](m1 )
Program Transform[(l1∗ , m∗2 )](l, m2 )
4. return L ← ACE.EncEK2 (i, m1 , m2 ).
3. Output m1 .
3. Output m1 , m2 .
Figure 24: Programs in HybD . In addition, in this hybrid the adversary gets l1∗ = ACE.EncEK1 (1, m∗1 ),
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
79
7.4 List of hybrids
For any messages m∗1 , m∗2 , consider the following distributions for randomly chosen rSetup :
• HybA = (PP, `∗0 , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZero[m∗1 ], Increment, Transform[`∗0 , m∗2 ],
isLess, RetrieveTag, RetrieveTags; rSetup ) (fig. 21), `∗0 = GenZero(m∗1 ), L∗0 = Transform(`∗0 , m∗2 ).
• HybB = (PP, `∗1 , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZeroB [m∗1 ], IncrementB , TransformB [`∗1 , m∗2 ],
isLessB , RetrieveTagB , RetrieveTagsB ; rSetup ) (fig. 22), `∗0 = GenZero(m∗1 ), `∗1 = Increment(`∗0 ),
L∗0 = Transform(`∗0 , m∗2 ).
• HybC = (PP, `∗1 , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZeroC [m∗1 ], IncrementC , TransformB [`∗1 , m∗2 ],
isLessC , RetrieveTagC , RetrieveTagsC ; rSetup ) (fig. 23), `∗0 = GenZero(m∗1 ), `∗1 = Increment(`∗0 ),
L∗0 = Transform(`∗0 , m∗2 ).
• HybD = (PP, `∗1 , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZero[m∗1 ], Increment, Transform[`∗1 , m∗2 ],
isLess, RetrieveTag, RetrieveTags; rSetup ) (fig. 24), `∗0 = GenZero(m∗1 ), `∗1 = Increment(`∗0 ), L∗0 =
Transform(`∗0 , m∗2 ).
Note that HybA is the distribution from security game for b = 0 and HybD is the distribution from security
game for b = 1. To prove security of the level system, we need to show that HybA ≈ HybD , which we do in
the following lemmas:
Lemma 2. (Switching from `∗0 to `∗1 ) For any PPT adversary A,
advHybA ,HybB (λ) ≤ T · 2−Ω(νiO (λ)) + T · 2−Ω(νACE.Indist (λ)) + 2−Ω(νACE.ConstrDec (λ)) .
Lemma 3. (Changing the upper bound from T + 1 to T ) For any PPT adversary A,
1
advHybB ,HybC (λ) ≤ 2−Ω(γ(λ)) + + T · 2−Ω(νiO (λ)) + T · 2−Ω(νACE.ConstrDec (λ)) .
T
Lemma 4. (Restoring behavior of Transform) For any PPT adversary A,
advHybC ,HybD (λ) ≤ 2τ (λ) (T · 2−Ω(νiO (λ)) + T · 2−Ω(νACE.Indist (λ)) + 2−Ω(νACE.ConstrDec (λ)) ).
7.4.1 Proof of lemma 2 (Switching from `∗0 to `∗1 ).

As described earlier, we are going to shift levels [i, m∗1 ] to [i + 1, m∗1 ] one by one, starting from i = T . We
start from HybA .
• HybA,1,1 . We give the adversary (PP, l0∗ , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZeroA,1,1 [m∗1 ],
IncrementA,1,1 , TransformA,1,1 [(l0∗ , m∗2 )], isLess, RetrieveTagA,1,1 , RetrieveTags; rSetup ) for ran-
domly chosen rSetup , l0∗ = ACE.EncEK1 (0, m∗1 ), L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ). Description of
the programs can be found on fig. 25.
That is, we puncture ACE key EK1 at point pT +1 = (T + 1, m∗1 ) in programs Increment and GenZero,
since these programs never run encryption on pT +1 . Indistinguishability holds by iO.
80
That is, we puncture ACE key DK1 at the same point pT +1 = (T + 1, m∗1 ) in programs Increment,
Transform, and RetrieveTag. Indistinguishability holds by security of constrained decryption of ACE,
since corresponding encryption key is already punctured at pT +1 .
Next we consider the following sequence of hybrids for j = T, . . . , 1. Programs for the case j = T and
j = T − 1 are written separately in order to track how the upper bound in programs is changed from T to
T + 1.
• HybA,2,j,1 . We give the adversary (PP, l0∗ , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZeroA,2,j,1 [m∗1 ],
IncrementA,2,j,1 , TransformA,2,j,1 [(l0∗ , m∗2 )], isLess, RetrieveTagA,2,j,1 , RetrieveTags; rSetup ) for ran-
domly chosen rSetup , l0∗ = ACE.EncEK1 (0, m∗1 ), L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ). Description of the
programs can be found on fig. 26 (for the case j = T ), fig. 29 (for j = T − 1), fig. 33 (for
j = T − 2, . . . , 1).
That is, in this hybrid EK1 and DK1 are punctured at pj+1 = (j + 1, m∗1 ). In addition, program
Increment, given [j, m∗1 ], outputs [j + 2, m∗1 ]. Program Transform, given ([i, m∗1 ], m2 ) for i > j,
outputs [i − 1, m∗1 , m2 ].
Note that HybA,2,j,1 = HybA,1,2 for j = T .
j = T − 2, . . . , 1).
That is, we additionally puncture ACE keys EK1 , DK1 at the point pj = (j, m∗1 ) and hardwire lj∗ =
ACE.EncEK1 (j, m∗1 ) to eliminate the need to encrypt or decrypt pj in programs GenZero, Increment,
Transform, and RetrieveTag. Indistinguishability holds by iO.
j = T − 2, . . . , 1).
That is, we replace lj∗ = ACE.EncEK1 (j, m∗1 ) with lj+1
∗ = ACE.EncEK1 (j + 1, m∗1 ) in programs
Increment, Transform, and RetrieveTag. Indistinguishability holds by security of ACE for punctured
points pj , pj+1 .
j = T − 2, . . . , 1).
That is, we unpuncture ACE keys EK1 , DK1 at the point pj+1 = (j + 1, m∗1 ) and remove hardwired
∗
lj+1 = ACE.EncEK1 (j + 1, m∗1 ) in programs GenZero, Increment, Transform, and RetrieveTag.
Indistinguishability holds by iO.
Note that HybA,2,j,4 = HybA,2,j−1,1 for 2 ≤ j ≤ T .
81
Next we change l0∗ to l1∗ as follows:
• HybA,2,0,1 . We give the adversary (PP, l0∗ , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZeroA,2,0,1 [m∗1 ],
IncrementA,2,0,1 , TransformA,2,0,1 [(l0∗ , m∗2 )], isLess, RetrieveTagA,2,0,1 , RetrieveTags; rSetup ) for ran-
programs can be found on fig. 37.
That is, in this hybrid EK1 and DK1 are punctured at p1 = (1, m∗1 ). In addition, program Increment,
given [0, m∗1 ], outputs [2, m∗1 ]. Program Transform, given ([i, m∗1 ], m2 ) for i > 0, outputs [i −
1, m∗1 , m2 ].
Note that HybA,2,0,1 = HybA,2,j,4 for j = 1.
That is, we additionally puncture ACE keys EK1 , DK1 at the point p0 = (0, m∗1 ) and hardwire l0∗ =
ACE.EncEK1 (0, m∗1 ) to eliminate the need to encrypt or decrypt p0 in programs GenZero, Increment,
Transform, and RetrieveTag. Indistinguishability holds by iO.
That is, we replace l0∗ = ACE.EncEK1 (0, m∗1 ) with l1∗ = ACE.EncEK1 (1, m∗1 ) in programs Increment,
Transform, and RetrieveTag, and give l1∗ instead of l0∗ to the adversary. Indistinguishability holds by
security of ACE for punctured points p0 , p1 .
That is, we unpuncture ACE keys EK1 , DK1 at the point p1 = (1, m∗1 ) and remove hardwired
l1∗ = ACE.EncEK1 (1, m∗1 ) in programs GenZero, Increment, Transform, and RetrieveTag. Indis-
tinguishability holds by iO.
That is, we unpuncture ACE decryption key DK1 at the point p0 = (0, m∗1 ) in programs Increment,
since corresponding encryption key is punctured at p0 .
82
That is, we unpuncture ACE encryption key EK1 at the point p0 = (0, m∗1 ) in programs GenZero,
Increment. Indistinguishability holds by iO, since these programs never encrypt p0 .
Note that HybA,3,3 is the same as HybB .
Thus, the the advantage of the PPT adversary in distinguishing between HybA and HybB is at most
(2T + 4) · 2−Ω(νiO (λ)) + (T + 1) · 2−Ω(νACE.Indist (λ)) + 2 · 2−Ω(νACE.ConstrDec (λ)) =
T · 2−Ω(νiO (λ)) + T · 2−Ω(νACE.Indist (λ)) + 2−Ω(νACE.ConstrDec (λ)) .
83
Programs in HybA,1,1
Program GenZeroA,1,1 [m∗1 ](m1 )
Hardwired values: encryption key EK1 {pT +1 } of ACE punctured at the point pT +1 = (T + 1, m∗1 ), tag
m∗1 .
2. Return l ← ACE.EncEK1 {pT +1 } (0, m1 ).
Program IncrementA,1,1 (l)
Hardwired values: encryption and decryption keys EK1 {pT +1 }, DK1 of ACE punctured at pT +1 = (T +
1, m∗1 ), upper bound T .
3. Return l+1 ← ACE.EncEK1 {pT +1 } (i + 1, m1 ).
Program TransformA,1,1 [(l0∗ , m∗2 )](l, m2 )
Program RetrieveTagA,1,1 (l)
3. Return m1 .
Figure 25: Programs in HybA,1,1 . In addition, in this hybrid the adversary gets unmodified obfuscated
programs isLess and RetrieveTags, together with l0∗ = ACE.EncEK1 (0, m∗1 ), L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
84
Programs in HybA,1,2 (same as HybA,2,T,1 )
Program GenZeroA,2,T,1 [m∗1 ](m1 )
Hardwired values: encryption key EK1 {pT +1 } of ACE punctured at the point pT +1 = (T + 1, m∗1 ), tag
m∗1 .
2. Return l ← ACE.EncEK1 {pT +1 } (0, m1 ).
Program IncrementA,2,T,1 (l)
Hardwired values: encryption and decryption keys EK1 {pT +1 }, DK1 {pT +1 } of ACE punctured at pT +1 =
(T + 1, m∗1 ), upper bound T .
1. out ← ACE.DecDK1 {pT +1 } (l); if out = 0 fail0 then return 0 fail0 ; else parse out as (i, m1 ).
2. If i ≥ T or i < 0 then return 0 fail0 ;
3. Return l+1 ← ACE.EncEK1 {pT +1 } (i + 1, m1 ).
Program TransformA,2,T,1 [(l0∗ , m∗2 )](l, m2 )
Hardwired values: decryption key DK1 {pT +1 } of ACE punctured at the point pT +1 = (T + 1, m∗1 ),
encryption key EK2 of ACE, single-tag level l0∗ = ACE.EncEK1 (0, m∗1 ), tag m∗2 , upper bound T .
2. out ← ACE.DecDK1 {pT +1 } (l); if out = 0 fail0 then return 0 fail0 ; else parse out as (i, m1 ).
Program RetrieveTagA,2,T,1 (l)
Hardwired values: decryption key DK1 {pT +1 } of ACE punctured at the point pT +1 = (T + 1, m∗1 ), upper
bound T .
1. out ← ACE.DecDK1 {pT +1 } (l); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 ).
3. Return m1 .
Figure 26: Programs in HybA,1,2 (same as HybA,2,T,1 ). In addition, in this hybrid the adversary gets
unmodified obfuscated programs isLess and RetrieveTags, together with l0∗ = ACE.EncEK1 (0, m∗1 ), L∗0 =
ACE.EncEK2 (0, m∗1 , m∗2 ).
85
Programs in HybA,2,T,2
Hardwired values: encryption key EK1 {pT , pT +1 } of ACE punctured at points pT = (T, m∗1 ), pT +1 =
(T + 1, m∗1 ), tag m∗1 .
2. Output l ← ACE.EncEK1 {pT ,pT +1 } (0, m1 ).
Hardwired values: encryption and decryption keys EK1 {pT , pT +1 }, DK1 {pT , pT +1 } of ACE punctured at
pT = (T, m∗1 ), pT +1 = (T + 1, m∗1 ), single-tag level lT∗ = ACE.EncEK1 (T, m∗1 ), upper bound T .
1. If l = lT∗ then output 0 fail0 ;
2. out ← ACE.DecDK1 {pT ,pT +1 } (l); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 ).
4. If i = T − 1 and m1 = m∗1 then output lT∗ ;
5. output l+1 ← ACE.EncEK1 {pT ,pT +1 } (i + 1, m1 ).
Hardwired values: decryption key DK1 {pT , pT +1 } of ACE punctured at points pT = (T, m∗1 ), pT +1 =
(T + 1, m∗1 ), encryption key EK2 of ACE, single-tag level l0∗ = ACE.EncEK1 (0, m∗1 ), tag m∗2 , single-tag level
lT∗ = ACE.EncEK1 (T, m∗1 ), upper bound T .
1. If (l, m2 ) = (l0∗ , m∗2 ) then output 0 fail0 ;
2. If l = lT∗ then output L ← ACE.EncEK2 (T, m∗1 , m2 );
(T + 1, m∗1 ), single-tag level lT∗ = ACE.EncEK1 (T, m∗1 ), upper bound T .
1. If l = lT∗ then output m∗1 ;
4. Output m1 .
Figure 27: Programs in HybA,2,T,2 . In addition, in this hybrid the adversary gets unmodified obfuscated
86
Programs in HybA,2,T,3
Hardwired values: encryption key EK1 {pT , pT +1 } of ACE punctured at points pT = (T, m∗1 ), pT +1 =
(T + 1, m∗1 ), tag m∗1 .
2. Output l ← ACE.EncEK1 {pT ,pT +1 } (0, m1 ).
Hardwired values: encryption and decryption keys EK1 {pT , pT +1 }, DK1 {pT , pT +1 } of ACE punctured at
pT = (T, m∗1 ), pT +1 = (T + 1, m∗1 ), single-tag level lT∗ +1 = ACE.EncEK1 (T + 1, m∗1 ), upper bound T .
1. If l = lT∗ +1 then output 0 fail0 ;
4. If i = T − 1 and m1 = m∗1 then output lT∗ +1 ;
5. output l+1 ← ACE.EncEK1 {pT ,pT +1 } (i + 1, m1 ).
(T + 1, m∗1 ), encryption key EK2 of ACE, single-tag level l0∗ = ACE.EncEK1 (0, m∗1 ), tag m∗2 , single-tag level
lT∗ +1 = ACE.EncEK1 (T + 1, m∗1 ), upper bound T .
2. If l = lT∗ +1 then output L ← ACE.EncEK2 (T, m∗1 , m2 );
(T + 1, m∗1 ), single-tag level lT∗ +1 = ACE.EncEK1 (T + 1, m∗1 ), upper bound T .
1. If l = lT∗ +1 then output m∗1 ;
4. Output m1 .
Figure 28: Programs in HybA,2,T,3 . In addition, in this hybrid the adversary gets unmodified obfuscated
87
Programs in HybA,2,T,4 (same as HybA,2,T −1,1 ).
Program GenZeroA,2,T −1,1 [m∗1 ](m1 )
Hardwired values: encryption key EK1 {pT } of ACE punctured at the point pT = (T, m∗1 ), tag m∗1 .
2. Output l ← ACE.EncEK1 {pT } (0, m1 ).
Program IncrementA,2,T −1,1 (l)
Hardwired values: encryption and decryption keys EK1 {pT }, DK1 {pT } of ACE punctured at pT = (T, m∗1 ),
upper bound T .
1. out ← ACE.DecDK1 {pT } (l); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 ).
3. If i = T − 1 and m1 = m∗1 then output ACE.EncEK1 {pT } (i + 2, m1 );
4. output l+1 ← ACE.EncEK1 {pT } (i + 1, m1 ).
Program TransformA,2,T −1,1 [(l0∗ , m∗2 )](l, m2 )
Hardwired values: decryption key DK1 {pT } of ACE punctured at the point pT = (T, m∗1 ), encryption key
EK2 of ACE, single-tag level l0∗ = ACE.EncEK1 (0, m∗1 ), tag m∗2 , upper bound T .
3. If m1 = m∗1 and i = T + 1 then output L ← ACE.EncEK2 (T, m∗1 , m2 );
Program RetrieveTagA,2,T −1,1 (l)
Hardwired values: decryption key DK1 {pT } of ACE punctured at the point pT = (T, m∗1 ), upper bound T .
2. If m = m∗1 :
(a) If i > T + 1 or i < 0 then output 0 fail0 ;
(b) Output m∗1 .
3. If m 6= m∗1 :
(a) If i > T or i < 0 then output 0 fail0 ;
(b) Output m1 .
Figure 29: Programs in HybA,2,T,4 (same as HybA,2,T −1,1 ). In addition, in this hybrid the adversary
gets unmodified obfuscated programs isLess and RetrieveTags, together with l0∗ = ACE.EncEK1 (0, m∗1 ),
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
88
Programs in HybA,2,T −1,2
Hardwired values: encryption key EK1 {pT −1 , pT } of ACE punctured at points pT −1 = (T − 1, m∗1 ), pT =
(T, m∗1 ), tag m∗1 .
2. Output l ← ACE.EncEK1 {pT −1 ,pT } (0, m1 ).
Hardwired values: encryption and decryption keys EK1 {pT −1 , pT }, DK1 {pT −1 , pT } of ACE punctured at
points pT −1 = (T − 1, m∗1 ), pT = (T, m∗1 ), single-tag level lT∗ −1 = ACE.EncEK1 (T − 1, m∗1 ), upper bound
T,
1. If l = lT∗ −1 then output ACE.EncEK1 {pT −1 ,pT } (T + 1, m∗1 );
2. out ← ACE.DecDK1 {pT −1 ,pT } (l); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 ).
4. If i = T − 2 and m1 = m∗1 then output lT∗ −1 ;
5. output l+1 ← ACE.EncEK1 {pT −1 ,pT } (i + 1, m1 ).
Hardwired values: decryption key DK1 {pT −1 , pT } of ACE punctured at points pT −1 = (T − 1, m∗1 ), pT =
(T, m∗1 ), encryption key EK2 of ACE, single-tag level l0∗ = ACE.EncEK1 (0, m∗1 ), tag m∗2 , single-tag level
lT∗ −1 = ACE.EncEK1 (T − 1, m∗1 ), upper bound T .
2. If l = lT∗ −1 then output L ← ACE.EncEK2 (T − 1, m∗1 , m2 );
(T, m∗1 ), single-tag level lT∗ −1 = ACE.EncEK1 (T − 1, m∗1 ), upper bound T .
1. If l = lT∗ −1 then output m∗1 ;
3. If m = m∗1 :
(b) Output m∗1 .
4. If m 6= m∗1 :
(b) Output m1 .
Figure 30: Programs in HybA,2,T −1,2 . In addition, in this hybrid the adversary gets unmodified obfuscated
89
Hardwired values: encryption key EK1 {pT −1 , pT } of ACE punctured at points pT −1 = (T − 1, m∗1 ), pT =
(T, m∗1 ), tag m∗1 .
2. Output l ← ACE.EncEK1 {pT −1 ,pT } (0, m1 ).
Hardwired values: encryption and decryption keys EK1 {pT −1 , pT }, DK1 {pT −1 , pT } of ACE punctured at
points pT −1 = (T − 1, m∗1 ), pT = (T, m∗1 ), single-tag level lT∗ = ACE.EncEK1 (T, m∗1 ) , upper bound T .
1. If l = lT∗ then output ACE.EncEK1 {pT −1 ,pT } (T + 1, m∗1 );
4. If i = T − 2 and m1 = m∗1 then output lT∗ ;
5. output l+1 ← ACE.EncEK1 {pT −1 ,pT } (i + 1, m1 ).
(T, m∗1 ), encryption key EK2 of ACE, single-tag level l0∗ = ACE.EncEK1 (0, m∗1 ), tag m∗2 , single-tag level
lT∗ = ACE.EncEK1 (T, m∗1 ), upper bound T .
2. If l = lT∗ then output L ← ACE.EncEK2 (T − 1, m∗1 , m2 );
(T, m∗1 ), single-tag level lT∗ = ACE.EncEK1 (T, m∗1 ), upper bound T .
1. If l = lT∗ then output m∗1 ;
3. If m = m∗1 :
(b) Output m∗1 .
4. If m 6= m∗1 :
(b) Output m1 .
90
Hardwired values: encryption key EK1 {pT −1 } of ACE punctured at the point pT −1 = (T − 1, m∗1 ), tag
m∗1 .
2. Output l ← ACE.EncEK1 {pT −1 } (0, m1 ).
Hardwired values: encryption and decryption keys EK1 {pT −1 }, DK1 {pT −1 } of ACE punctured at the point
pT −1 = (T − 1, m∗1 ), upper bound T .
1. out ← ACE.DecDK1 {pT −1 } (l); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 ).
4. If i = T − 2 and m1 = m∗1 then output ACE.EncEK1 {pT −1 } (i + 2, m1 );
5. output l+1 ← ACE.EncEK1 {pT −1 } (i + 1, m1 ).
Hardwired values: decryption key DK1 {pT −1 } of ACE punctured at the point pT −1 = (T − 1, m∗1 ),
4. If m1 = m∗1 and i = T then output L ← ACE.EncEK2 (T − 1, m∗1 , m2 );
Hardwired values: decryption key DK1 {pT −1 } of ACE punctured at the point pT −1 = (T − 1, m∗1 ), upper
bound T .
2. If m = m∗1 :
(b) Output m∗1 .
3. If m 6= m∗1 :
(b) Output m1 .
91
Programs in HybA,2,j,1
Program GenZeroA,2,j,1 [m∗1 ](m1 )
Hardwired values: encryption key EK1 {pj+1 } of ACE punctured at the point pj+1 = (j + 1, m∗1 ), tag m∗1 .
2. Output l ← ACE.EncEK1 {pj+1 } (0, m1 ).
Program IncrementA,2,j,1 (l)
Hardwired values: encryption and decryption keys EK1 {pj+1 }, DK1 {pj+1 } of ACE punctured at pj+1 =
(j + 1, m∗1 ), index j, upper bound T .
1. out ← ACE.DecDK1 {pj+1 } (l); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 ).
4. If i = j and m1 = m∗1 then output ACE.EncEK1 {pj+1 } (i + 2, m∗1 );
5. output l+1 ← ACE.EncEK1 {pj+1 } (i + 1, m1 ).
Program TransformA,2,j,1 [(l0∗ , m∗2 )](l, m2 )
Hardwired values: decryption key DK1 {pj+1 } of ACE punctured at the point pj+1 = (j + 1, m∗1 ), encryp-
tion key EK2 of ACE, single-tag level l0∗ = ACE.EncEK1 (0, m∗1 ), tag m∗2 , index j, upper bound T .
3. If m1 = m∗1 :
(b) If i > j + 1 then output L ← ACE.EncEK2 (i − 1, m1 , m2 );
(c) If i = j + 1 then output 0 fail0 ;
(d) If i < j + 1 then output L ← ACE.EncEK2 (i, m1 , m2 ).
4. If m1 6= m∗1 :
(b) Output L ← ACE.EncEK2 (i, m1 , m2 ).
Program RetrieveTagA,2,j,1 (l)
Hardwired values: decryption key DK1 {pj+1 } of ACE punctured at the point pj+1 = (j + 1, m∗1 ), upper
bound T .
2. If m = m∗1 :
(b) Output m∗1 .
3. If m 6= m∗1 :
(b) Output m1 .
Figure 33: Programs in HybA,2,j,1 . In addition, in this hybrid the adversary gets unmodified obfuscated
92
Hardwired values: encryption key EK1 {pj , pj+1 } of ACE punctured at points pj = (j, m∗1 ), pj+1 =
(j + 1, m∗1 ), tag m∗1 .
2. Output l ← ACE.EncEK1 {pj ,pj+1 } (0, m1 ).
Hardwired values: encryption and decryption keys EK1 {pj , pj+1 }, DK1 {pj , pj+1 } of ACE punctured at
points pj = (j, m∗1 ), pj+1 = (j + 1, m∗1 ), single-tag level lj∗ = ACE.EncEK1 (j, m∗1 ), index j, upper bound T ,
1. If l = lj∗ then output ACE.EncEK1 {pj ,pj+1 } (j + 2, m∗1 );
2. out ← ACE.DecDK1 {pj ,pj+1 } (l); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 ).
5. If i = j − 1 and m1 = m∗1 then output lj∗ ;
6. output l+1 ← ACE.EncEK1 {pj ,pj+1 } (i + 1, m1 ).
Hardwired values: decryption key DK1 {pj , pj+1 } of ACE punctured at points pj = (j, m∗1 ), pj+1 =
(j + 1, m∗1 ), encryption key EK2 of ACE, single-tag level l0∗ = ACE.EncEK1 (0, m∗1 ), tag m∗2 , single-tag level
lj∗ = ACE.EncEK1 (j, m∗1 ), index j, upper bound T .
2. If l = lj∗ then output L ← ACE.EncEK2 (j, m∗1 , m2 );
4. If m1 = m∗1 :
(d) If i = j then output 0 fail0 ;
(e) If i < j then output L ← ACE.EncEK2 (i, m1 , m2 ).
5. If m1 6= m∗1 :
(j + 1, m∗1 ), single-tag level lj∗ = ACE.EncEK1 (j, m∗1 ), upper bound T .
1. If l = lj∗ then output m∗1 ;
3. If m = m∗1 :
(b) Output m1 .
4. If m 6= m∗1 :
(b) Output m1 .
Figure 34: Programs in HybA,2,j,2 . In addition, in 93 this hybrid the adversary gets unmodified obfuscated
Hardwired values: encryption key EK1 {pj , pj+1 } of ACE punctured at points pj = (j, m∗1 ), pj+1 =
(j + 1, m∗1 ), tag m∗1 .
2. Output l ← ACE.EncEK1 {pj ,pj+1 } (0, m1 ).
Hardwired values: encryption and decryption keys EK1 {pj , pj+1 }, DK1 {pj , pj+1 } of ACE punctured at
points pj = (j, m∗1 ), pj+1 = (j + 1, m∗1 ), single-tag level lj+1
∗ = ACE.EncEK1 (j + 1, m∗1 ) , index j, upper
bound T .
∗
1. If l = lj+1 then output ACE.EncEK1 {pj ,pj+1 } (j + 2, m∗1 );
5. If i = j − 1 and m1 = m∗1 then output lj+1 ∗ ;
6. output l+1 ← ACE.EncEK1 {pj ,pj+1 } (i + 1, m1 ).

(j + 1, m∗1 ), encryption key EK2 of ACE, single-tag level l0∗ = ACE.EncEK1 (0, m∗1 ), tag m∗2 , single-tag level
∗
lj+1 = ACE.EncEK1 (j + 1, m∗1 ), index j, upper bound T .
∗
2. If l = lj+1 then output L ← ACE.EncEK2 (j, m∗1 , m2 );
4. If m1 = m∗1 :
(d) If i = j then output 0 fail0 ;
(e) If i < j then output L ← ACE.EncEK2 (i, m1 , m2 ).
5. If m1 6= m∗1 :
(j + 1, m∗1 ), single-tag level lj+1
∗ = ACE.EncEK1 (j + 1, m∗1 ), upper bound T .
∗
1. If l = lj+1 then output m∗1 ;
3. If m = m∗1 :
(b) Output m1 .
4. If m 6= m∗1 :
(b) Output m1 . 94
Programs in HybA,2,j,4 .
Hardwired values: encryption key EK1 {pj } of ACE punctured at the point pj = (j, m∗1 ), tag m∗1 .
2. Output l ← ACE.EncEK1 {pj } (0, m1 ).
Hardwired values: encryption and decryption keys EK1 {pj }, DK1 {pj } of ACE punctured at pj = (j, m∗1 ),
index j, upper bound T .
1. out ← ACE.DecDK1 {pj } (l); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 ).
4. If i = j − 1 and m1 = m∗1 then output ACE.EncEK1 {pj } (i + 2, m∗1 );
5. output l+1 ← ACE.EncEK1 {pj } (i + 1, m1 ).
Hardwired values: decryption key DK1 {pj } of ACE punctured at the point pj = (j, m∗1 ), encryption key
EK2 of ACE, single-tag level l0∗ = ACE.EncEK1 (0, m∗1 ), tag m∗2 , index j, upper bound T .
3. If m1 = m∗1 :
(b) If i > j then output L ← ACE.EncEK2 (i − 1, m1 , m2 );
(c) If i = j then output 0 fail0 ;
(d) If i < j then output L ← ACE.EncEK2 (i, m1 , m2 ).
4. If m1 6= m∗1 :
Hardwired values: decryption key DK1 {pj } of ACE punctured at the point pj = (j, m∗1 ), upper bound T .
2. If m = m∗1 :
(b) Output m∗1 .
3. If m 6= m∗1 :
(b) Output m1 .
95
Programs in HybA,2,0,1
Program GenZeroA,2,0,1 [m∗1 ](m1 )
Hardwired values: encryption key EK1 {p1 } of ACE punctured at the point p1 = (1, m∗1 ), tag m∗1 .
2. Output l ← ACE.EncEK1 {p1 } (0, m1 ).
Program IncrementA,2,0,1 (l)
Hardwired values: encryption and decryption keys EK1 {p1 }, DK1 {p1 } of ACE punctured at p1 = (1, m∗1 ),
upper bound T .
1. out ← ACE.DecDK1 {p1 } (l); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 ).
4. If i = 0 and m1 = m∗1 then output ACE.EncEK1 {p1 } (i + 2, m∗1 );
5. output l+1 ← ACE.EncEK1 {p1 } (i + 1, m1 ).
Program TransformA,2,0,1 [(l0∗ , m∗2 )](l, m2 )
Hardwired values: decryption key DK1 {p1 } of ACE punctured at the point p1 = (1, m∗1 ), encryption key
3. If m1 = m∗1 :
(b) If i > 1 then output L ← ACE.EncEK2 (i − 1, m1 , m2 );
(c) If i = 1 then output 0 fail0 ;
(d) If i < 1 then output L ← ACE.EncEK2 (i, m1 , m2 ).
4. If m1 6= m∗1 :
Program RetrieveTagA,2,0,1 (l)
Hardwired values: decryption key DK1 {p1 } of ACE punctured at the point p1 = (1, m∗1 ), upper bound T .
2. If m = m∗1 :
(b) Output m∗1 .
3. If m 6= m∗1 :
(b) Output m1 .
Figure 37: Programs in HybA,2,0,1 . In addition, in this hybrid the adversary gets unmodified obfuscated
96
Hardwired values: encryption key EK1 {p0 , p1 } of ACE punctured at points p0 = (0, m∗1 ), p1 = (1, m∗1 ),
tag m∗1 .
2. Output l ← ACE.EncEK1 {p0 ,p1 } (0, m1 ).
Hardwired values: encryption and decryption keys EK1 {p0 , p1 }, DK1 {p0 , p1 } of ACE punctured at points
p0 = (0, m∗1 ), p1 = (1, m∗1 ), single-tag level l0∗ = ACE.EncEK1 (0, m∗1 ), upper bound T ,
1. If l = l0∗ then output ACE.EncEK1 {p0 ,p1 } (2, m∗1 );
2. out ← ACE.DecDK1 {p0 ,p1 } (l); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 ).
5. output l+1 ← ACE.EncEK1 {p0 ,p1 } (i + 1, m1 ).
Hardwired values: decryption key DK1 {p0 , p1 } of ACE punctured at points p0 = (0, m∗1 ), p1 = (1, m∗1 ),
2. If l = l0∗ then output L ← ACE.EncEK2 (0, m∗1 , m2 );
4. If m1 = m∗1 :
(d) If i = 0 then output 0 fail0 ;
5. If m1 6= m∗1 :
single-tag level l0∗ = ACE.EncEK1 (0, m∗1 ), upper bound T .
1. If l = l0∗ then output m∗1 ;
3. If m = m∗1 :
(b) Output m1 .
4. If m 6= m∗1 :
(b) Output m1 .
97
Hardwired values: encryption key EK1 {p0 , p1 } of ACE punctured at points p0 = (0, m∗1 ), p1 = (1, m∗1 ),
tag m∗1 .
2. Output l ← ACE.EncEK1 {p0 ,p1 } (0, m1 ).
Hardwired values: encryption and decryption keys EK1 {p0 , p1 }, DK1 {p0 , p1 } of ACE punctured at points
p0 = (0, m∗1 ), p1 = (1, m∗1 ), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), upper bound T ,
1. If l = l1∗ then output ACE.EncEK1 {p0 ,p1 } (2, m∗1 );
5. output l+1 ← ACE.EncEK1 {p0 ,p1 } (i + 1, m1 ).
2. If l = l1∗ then output L ← ACE.EncEK2 (0, m∗1 , m2 );
4. If m1 = m∗1 :
(d) If i = 0 then output 0 fail0 ;
5. If m1 6= m∗1 :
single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), upper bound T .
1. If l = l1∗ then output m∗1 ;
3. If m = m∗1 :
(b) Output m1 .
4. If m 6= m∗1 :
(b) Output m1 .
98
Programs in HybA,3,1 .
upper bound T .
Hardwired values: decryption key DK1 {p0 } of ACE punctured at the point p0 = (0, m∗1 ), encryption key
3. If m1 = m∗1 :
(b) output L ← ACE.EncEK2 (i − 1, m1 , m2 );
4. If m1 6= m∗1 :
Hardwired values: decryption key DK1 {p0 } of ACE punctured at the point p0 = (0, m∗1 ), upper bound T .
2. If m = m∗1 :
(b) Output m∗1 .
3. If m 6= m∗1 :
(b) Output m1 .
99
Hardwired values: encryption and decryption keys EK1 {p0 }, DK1 of ACE punctured at p0 = (0, m∗1 ),
upper bound T .
3. If m1 = m∗1 :
4. If m1 6= m∗1 :
2. If m = m∗1 :
(b) Output m∗1 .
3. If m 6= m∗1 :
(b) Output m1 .
100
2. Output l ← ACE.EncEK1 (0, m1 ).
3. If m1 = m∗1 :
4. If m1 6= m∗1 :
2. If m = m∗1 :
(b) Output m∗1 .
3. If m 6= m∗1 :
(b) Output m1 .
101
7.4.2 Proof of lemma 3 (Changing the upper bound from T + 1 to T ).
As described earlier, we will fix upper bounds in programs by cutting the sequence of encryptions [1, m∗1 ] →
. . . → [T + 1, m∗1 ] at a random place and then cutting the sequence in all subsequent positions, then changing
the upper bound, and finally restoring the line. We cut the line at a random place in the following sequence of
hybrids, starting from HybB :
• HybB,1,1 . We give the adversary (PP, l1∗ , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZeroB,1,1 [m∗1 ],
IncrementB,1,1 , TransformB,1,1 [(l1∗ , m∗2 )], isLess, RetrieveTagB,1,1 , RetrieveTags; rSetup ) for ran-
That is, in program Increment we add an instruction to abort if m1 = m∗1 and g(i) = I ∗ , where g
is an injective OWF and I ∗ is a random image of g. Indistinguishability holds by security of iO and
OWF: since OWF is injective, the two programs differ only at a single point; as shown in [BCP14],
any adversary which can distinguish between the two programs, can be also used to find the differing
point, which can be used to break one-wayness of g (see lemma 1).
That is, in programs Increment and GenZero we puncture ACE encryption key EK1 at the point
(i∗ + 1, m∗1 ). Indistinguishability holds by iO, since Increment never needs to encrypt this point,
because it aborts earlier on input [i∗ , m∗1 ]. GenZero never needs to encrypt (i∗ , m∗1 ) as well, since it
only encrypts value 0, and i∗ = 0 only with negligible probability.
Next we run the following sequence of hybrids for j = i∗ , . . . , T in order to cut the chain at all points after
i∗ :
• HybB,2,j,1 . We give the adversary (PP, l1∗ , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZeroB,2,j,1 [m∗1 ],
IncrementB,2,j,1 , TransformB,2,j,1 [(l1∗ , m∗2 )], isLess, RetrieveTagB,2,j,1 , RetrieveTags; rSetup ) for ran-
That is, in programs GenZero, Increment, Transform, and RetrieveTag ACE encryption key EK1 is
punctured at the set {(i∗ + 1, m∗1 ), . . . , (j + 1, m∗1 )}, and its decryption key DK1 is punctured at the
set {(i∗ + 1, m∗1 ), . . . , (j, m∗1 )}.
Note that HybB,2,j,1 = HybB,1,2 for j = i∗ .
That is, in programs Increment, Transform, and RetrieveTag we additionally puncture ACE decryption
key DK1 at the point (j + 1, m∗1 ). Indistinguishability holds by security of constrained decryption of
ACE, since EK1 is already punctured at the set which includes (j + 1, m∗1 ).
102
That is, we additionally puncture ACE encryption key EK1 at the point (j + 2, m∗1 ) in programs
GenZero and Increment. Indistinguishability holds by iO, since DK1 is punctured at the set which
includes (j + 1, m∗1 ), and thus program Increment never tries to encrypt (j + 2, m∗1 ), aborting earlier;
GenZero never needs to encrypt (j + 2, m∗1 ) either since j + 2 6= 0.
Note that HybB,2,j,3 = HybB,2,j+1,1 for j = i∗ , . . . , T .
Next we change the upper bound as follows:
That is, in programs GenZero, Increment, Transform, and RetrieveTag EK1 , DK1 are punctured at the
set {[i∗ + 1, m∗1 ], . . . , [T + 1, m∗1 ]}.
Note that HybB,3,1 = HybB,2,T,2 .
That is, in program Increment and Transform we change the upper bound from T + 1 to T . Indistin-
guishability holds by iO, since DK1 is punctured at the set which includes (T, m∗1 ), (T + 1, m∗1 ), and
thus Increment anyways outputs 0 fail0 on input [T, m∗1 ], and Transform anyway outputs 0 fail0 on input
[T + 1, m∗1 ].
Next we run the following sequence of hybrids for j = T, . . . , i∗ in order to restore the chain:
That is, in programs GenZero, Increment, Transform, and RetrieveTag ACE key EK1 , DK1 are punc-
tured at the set {(i∗ + 1, m∗1 ), . . . , (j + 1, m∗1 )}.
Note that HybB,4,j,1 = HybB,3,2 for j = T .
That is, we unpuncture DK1 in Increment, Transform, and RetrieveTag at the point (j + 1, m∗1 ).
Indistinguishability holds by security of constrained decryption of ACE, since EK1 is punctured at the
set which includes (j + 1, m∗1 ).
103
That is, we unpuncture EK1 in GenZero and Increment at the point (j + 1, m∗1 ). Indistinguishability
holds by iO, since GenZero never encrypts (j + 1, m∗1 ) where j + 1 6= 0, and since Increment never
encrypts (j + 1, m∗1 ), since it aborts on input [j, m∗1 ] due to punctured DK1 .
Note that HybB,4,j,3 = HybB,4,j−1,1 for j = T, . . . , i∗ + 1.
Finally we remove the last remaining cut in the chain as follows:
That is, in programs Increment and GenZero ACE encryption key EK1 is punctured at the point
(i∗ + 1, m∗1 ).
Note that HybB,5,1 = HybB,4,j,2 for j = i∗ .
That is, in program Increment we add an instruction to abort if m1 = m∗1 and g(i) = I ∗ , where
I ∗ = g(i∗ ) for randomly chosen i∗ . In addition, we remove the puncturing from EK1 in all programs.
Indistinguishability holds by iO, since Increment outputs 0 fail0 on [i∗ , m∗1 ] in both cases, and since
GenZero never needs to encrypt (i∗ + 1, m∗1 ).
That is, in program Increment we remove an instruction to abort if m1 = m∗1 and g(i) = I ∗ .
Indistinguishability holds by security of iO and OWF: since OWF is injective, the two programs differ
only at a single point; as shown in [BCP14], any adversary which can distinguish between the two
programs, can be also used to find the differing point, which can be used to break one-wayness of g
(see lemma 1).
Note that HybB,5,3 = HybC .
Note that this reduction works only as long as i∗ 6= 0, which happens with probability 1
T. Thus, the the
advantage of the PPT adversary in distinguishing between HybB and HybC is at most
1
+ 2 · 2−Ω(γ(λ)) + (2(T − i∗ + 1) + 3) · 2−Ω(νiO (λ)) + 2(T − i∗ + 1) · 2−Ω(νACE.ConstrDec (λ)) ≤
T
1
+ 2−Ω(γ(λ)) + T · 2−Ω(νiO (λ)) + T · 2−Ω(νACE.ConstrDec (λ)) .
T
104
Programs in HybB
Program GenZeroB [m∗1 ](m1 )
Program IncrementB (l)
Hardwired values: encryption and decryption keys EK1 , DK1 of ACE, tag m∗1 , upper bound T .
Program TransformB [(l1∗ , m∗2 )](l, m2 )
3. If m1 = m∗1 :
4. If m1 6= m∗1 :
Program isLessB (L0 , L00 )
Program RetrieveTagB (l)
4. Output m1 .
Program RetrieveTagsB (L)
3. Output m1 , m2 .
Figure 43: Programs in HybB . In addition, in this hybrid the adversary gets l1∗ = ACE.EncEK1 (1, m∗1 ),
L∗ = ACE.EncEK (0, m∗ , m∗ ). 105
0 2 1 2
Programs in HybB,1,1 .
Program GenZeroB,1,1 [m∗1 ](m1 )
Program IncrementB,1,1 (l)
Hardwired values: encryption and decryption keys EK1 , DK1 of ACE, tag m∗1 , OWF g, I ∗ = g(i∗ ) for
random i∗ , upper bound T .
3. If m1 = m∗1 and g(i) = I ∗ ) then output 0 fail0 ;
Program TransformB,1,1 [(l1∗ , m∗2 )](l, m2 )
3. If m1 = m∗1 :
4. If m1 6= m∗1 :
Program RetrieveTagB,1,1 (l)
4. Output m1 .
Figure 44: Programs in HybB,1,1 . In addition, in this hybrid the adversary gets unmodified obfuscated
106
Hardwired values:punctured encryption key EK1 {pi∗ +1 } of ACE, punctured at the point pi∗ +1 = (i∗ +
1, m∗1 ), tag m∗1 .
2. Output l ← ACE.EncEK1 {pi∗ +1 } (0, m1 ).
Hardwired values: encryption and decryption keys EK1 {pi∗ +1 }, DK1 of ACE, punctured at pi∗ +1 =
(i∗ + 1, m∗1 ), tag m∗1 , upper bound T .
4. output l+1 ← ACE.EncEK1 {pi∗ +1 } (i + 1, m1 ).
3. If m1 = m∗1 :
4. If m1 6= m∗1 :
4. Output m1 .
107
Programs in HybB,2,j,1 .
Program GenZeroB,2,j,1 [m∗1 ](m1 )
Hardwired values: punctured encryption key EK1 {Si∗ +1,j+1 } of ACE, tag m∗1 . Here Sa,b =
{(a, m∗1 ), (a + 1, m∗1 ), . . . , (b, m∗1 )} if b ≥ a and {∅} otherwise.
2. Output l ← ACE.EncEK1 {Si∗ +1,j+1 } (0, m1 ).
Program IncrementB,2,j,1 (l)
Hardwired values: punctured encryption and decryption keys EK1 {Si∗ +1,j+1 }, DK1 {Si∗ +1,j } of ACE, tag
m∗1 , set Si∗ ,j , upper bound T . Here Sa,b = {(a, m∗1 ), (a + 1, m∗1 ), . . . , (b, m∗1 )} if b ≥ a and {∅} otherwise.
1. out ← ACE.DecDK1 {Si∗ +1,j } (l); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 ).
4. output l+1 ← ACE.EncEK1 {Si∗ +1,j+1 } (i + 1, m1 ).
Program TransformB,2,j,1 [(l1∗ , m∗2 )](l, m2 )
Hardwired values: decryption key DK1 {Si∗ +1,j } of ACE, encryption key EK2 of ACE, single-tag level
l1∗ = ACE.EncEK1 (1, m∗1 ), tag m∗1 , tag m∗2 , upper bound T . Here Sa,b = {(a, m∗1 ), (a + 1, m∗1 ), . . . , (b, m∗1 )}
if b ≥ a and {∅} otherwise.
2. out ← ACE.DecDK1 {Si∗ +1,j } (l); if out = 0 fail0 then return 0 fail0 ; else parse out as (i, m1 ).
3. If m1 = m∗1 :
4. If m1 6= m∗1 :
Program RetrieveTagB,2,j,1 (l)
Hardwired values: decryption key DK1 {Si∗ +1,j } of ACE, punctured at the set Si∗ +1,j , tag m∗1 , upper bound
T . Here Sa,b = {(a, m∗1 ), (a + 1, m∗1 ), . . . , (b, m∗1 )} if b ≥ a and {∅} otherwise.
4. Output m1 .
Figure 46: Programs in HybB,2,j,1 . In addition, in this hybrid the adversary gets unmodified obfuscated
108
Hardwired values: punctured encryption and decryption keys EK1 {Si∗ +1,j+1 }, DK1 {Si∗ +1,j+1 } of ACE,
tag m∗1 , set Si∗ ,j , upper bound T . Here Sa,b = {(a, m∗1 ), (a + 1, m∗1 ), . . . , (b, m∗1 )} if b ≥ a and {∅}
otherwise.
1. out ← ACE.DecDK1 {Si∗ +1,j+1 } (l); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 ).
Hardwired values: decryption key DK1 {Si∗ +1,j+1 } of ACE, encryption key EK2 of ACE, single-tag level
2. out ← ACE.DecDK1 {Si∗ +1,j+1 } (l); if out = 0 fail0 then return 0 fail0 ; else parse out as (i, m1 ).
3. If m1 = m∗1 :
4. If m1 6= m∗1 :
Hardwired values: decryption key DK1 {Si∗ +1,j+1 } of ACE, punctured at the set Si∗ +1,j+1 , tag m∗1 , upper
bound T . Here Sa,b = {(a, m∗1 ), (a + 1, m∗1 ), . . . , (b, m∗1 )} if b ≥ a and {∅} otherwise.
4. Output m1 .
109
otherwise.
3. If m1 = m∗1 :
4. If m1 6= m∗1 :
Hardwired values: decryption key DK1 {Si∗ +1,j+1 } of ACE, punctured at the set Si∗ +1,j+1 , tag m∗1 , upper
4. Output m1 .
110
Hardwired values: punctured encryption key EK1 {Si∗ +1,T +1 } of ACE, tag m∗1 . Here Sa,b =
2. Output l ← ACE.EncEK1 {Si∗ +1,T +1 } (0, m1 ).
Hardwired values: punctured encryption and decryption keys EK1 {Si∗ +1,T +1 }, DK1 {Si∗ +1,T +1 } of ACE,
tag m∗1 , set Si∗ ,T , upper bound T . Here Sa,b = {(a, m∗1 ), (a + 1, m∗1 ), . . . , (b, m∗1 )} if b ≥ a and {∅}
otherwise.
1. out ← ACE.DecDK1 {Si∗ +1,T +1 } (l); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 ).
4. output l+1 ← ACE.EncEK1 {Si∗ +1,T +1 } (i + 1, m1 ).
Hardwired values: decryption key DK1 {Si∗ +1,T +1 } of ACE, encryption key EK2 of ACE, single-tag level
2. out ← ACE.DecDK1 {Si∗ +1,T +1 } (l); if out = 0 fail0 then return 0 fail0 ; else parse out as (i, m1 ).
3. If m1 = m∗1 :
4. If m1 6= m∗1 :
Hardwired values: decryption key DK1 {Si∗ +1,T +1 } of ACE, punctured at the set Si∗ +1,T +1 , tag m∗1 , upper
4. Output m1 .
111
Hardwired values: punctured encryption key EK1 {Si∗ +1,T +1 } of ACE, tag m∗1 . Here Sa,b =
2. Output l ← ACE.EncEK1 {Si∗ +1,T +1 } (0, m1 ).
Hardwired values: punctured encryption and decryption keys EK1 {Si∗ +1,T +1 }, DK1 {Si∗ +1,T +1 } of ACE,
tag m∗1 , set Si∗ ,T , upper bound T . Here Sa,b = {(a, m∗1 ), (a + 1, m∗1 ), . . . , (b, m∗1 )} if b ≥ a and {∅}
otherwise.
3. output l+1 ← ACE.EncEK1 {Si∗ +1,T +1 } (i + 1, m1 ).
Hardwired values: decryption key DK1 {Si∗ +1,T +1 } of ACE, encryption key EK2 of ACE, single-tag level
2. out ← ACE.DecDK1 {Si∗ +1,T +1 } (l); if out = 0 fail0 then return 0 fail0 ; else parse out as (i, m1 ).
5. If m1 6= m∗1 return L ← ACE.EncEK2 (i, m1 , m2 ).
Hardwired values: decryption key DK1 {Si∗ +1,T +1 } of ACE, punctured at the set Si∗ +1,T +1 , upper bound
T . Here Sa,b = {(a, m∗1 ), (a + 1, m∗1 ), . . . , (b, m∗1 )} if b ≥ a and {∅} otherwise.
3. Output m1 .
112
otherwise.
Hardwired values: decryption key DK1 {Si∗ +1,j+1 } of ACE, punctured at the set Si∗ +1,j+1 , upper bound T .
Here Sa,b = {(a, m∗1 ), (a + 1, m∗1 ), . . . , (b, m∗1 )} if b ≥ a and {∅} otherwise.
3. Output m1 .
113
Hardwired values: punctured encryption and decryption keys EK1 {Si∗ +1,j+1 }, DK1 {Si∗ +1,j } of ACE, tag
Hardwired values: decryption key DK1 {Si∗ +1,j } of ACE, punctured at the set Si∗ +1,j , upper bound T .
3. Output m1 .
114
Hardwired values: punctured encryption key EK1 {Si∗ +1,j } of ACE, tag m∗1 . Here Sa,b =
2. Output l ← ACE.EncEK1 {Si∗ +1,j } (0, m1 ).
Hardwired values: punctured encryption and decryption keys EK1 {Si∗ +1,j }, DK1 {Si∗ +1,j } of ACE, tag
3. output l+1 ← ACE.EncEK1 {Si∗ +1,j } (i + 1, m1 ).
Hardwired values: decryption key DK1 {Si∗ +1,j } of ACE, punctured at the set Si∗ +1,j , upper bound T .
3. Output m1 .
115
Hardwired values: punctured encryption key EK1 {pi∗ +1 } of ACE, punctured at the point pi∗ +1 = (i∗ +
1, m∗1 ), tag m∗1 .
2. Output l ← ACE.EncEK1 {pi∗ +1 } (0, m1 ).
Hardwired values: encryption and decryption keys EK1 {pi∗ +1 }, DK1 of ACE, punctured at the point
pi∗ +1 = (i∗ + 1, m∗1 ), tag m∗1 , , upper bound T .
3. output l+1 ← ACE.EncEK1 {pi∗ +1 } (i + 1, m1 ).
3. Output m1 .
116
Hardwired values: encryption and decryption keys EK1 , DK1 of ACE, tag m∗1 , OWF g, I ∗ = g(i∗ ) for
random i∗ , upper bound T .
3. If m1 = m∗1 and g(i) = I ∗ then output 0 fail0 ;
3. Output m1 .
117
3. Output m1 .
118
7.4.3 Proof of lemma 4 (Restoring behavior of Transform).
Starting from HybC , we first change outputs of Transform from [i − 1, m∗1 , m2 ] to [i, m∗1 , m2 ] for different
m2 6= m∗2 one by one, by considering the following sequence of hybrids for q = 0, . . . , ν2 , q 6= m∗2 , where
ν2 = 2|m2 | :
• HybC,1,q . We give the adversary (PP, l1∗ , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZero[m∗1 ],
Increment, TransformC,1,q [(l1∗ , m∗2 )], isLessC,1,q , RetrieveTag, RetrieveTagsC,1,q , l1∗ =
ACE.EncEK1 (1, m∗1 ), L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ). Description of the programs can be
found on fig. 58.
That is, program Transform on input ([i, m∗1 ], m2 ) outputs [i − 1, m∗1 , m2 ] for m2 ≥ q or m2 = m∗2
and [i, m∗1 , m2 ] otherwise.
Note that HybC = HybC,1,q for q = 0.
In the following sequence of hybrids we change the output at m2 = q from [i − 1, m∗1 , q] to [i, m∗1 , q]:
• HybC,1,q,1,1 . We give the adversary (PP, l1∗ , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZero[m∗1 ],
Increment, TransformC,1,q,1,1 [(l1∗ , m∗2 )], isLessC,1,q,1,1 , RetrieveTag, RetrieveTagsC,1,q,1,1 , l1∗ =
ACE.EncEK1 (1, m∗1 ), L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ). Description of the programs can be found
on fig. 59.
That is, in program Transform we puncture ACE encryption key EK2 at the point pT,q = (T, m∗1 , q).
Indistinguishability holds by iO, since Transform never encrypts this plaintext.
Increment, TransformC,1,q,1,2 [(l1∗ , m∗2 )], isLessC,1,q,1,2 , RetrieveTag, RetrieveTagsC,1,q,1,2 ; rSetup ) for
randomly chosen rSetup , l1∗ = ACE.EncEK1 (1, m∗1 ), L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ). Description of
That is, in programs isLess and RetrieveTags we puncture ACE decryption key DK2 at the point
pT,q = (T, m∗1 , q). Indistinguishability holds by security of constrained ACE key, since EK2 is already
punctured at the same point.
We consider the following hybrids for j = T − 1, . . . , 0, switching the output from [j, m∗1 , q] to [j + 1, m∗1 , q]:
• HybC,1,q,2,j,1 . We give the adversary (PP, l1∗ , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZero[m∗1 ],
Increment, TransformC,1,q,2,j,1 [(l1∗ , m∗2 )], isLessC,1,q,2,j,1 , RetrieveTag, RetrieveTagsC,1,q,2,j,1 ; rSetup )
for randomly chosen rSetup , l1∗ = ACE.EncEK1 (1, m∗1 ), L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ). Description
of the programs can be found on fig. 61.
That is, in this hybrid EK2 , DK2 are punctured at the point pj+1,q = (j + 1, m∗1 , q).
Note that HybC,1,q,1,2 = HybC,1,q,2,j,1 for j = T − 1.
That is, we additionally puncture ACE keys EK2 , DK2 at the point pj,q = (j, m∗1 , q) and hardwire
L∗j,q = ACE.EncEK2 (j, m∗1 , q) to eliminate the need to encrypt or decrypt pj,q in programs Transform,
isLess, and RetrieveTags. Indistinguishability holds by iO.
119
Note that in program isLess we instruct the program to use the value pj+1,q = (j + 1, m∗1 , q) on input
L∗j,q (instead of correct value pj,q = (j, m∗1 , q)). However, this doesn’t change the overall functionality
of the program: using pj+1,q instead of pj,q could change the result of comparison only if the other
input was an encryption of pj+1,q (since comparison will result in true when pj,q is used and false
when pj+1,q is used). However, DK2 is punctured at a set which includes pj+1,q , and thus no ciphertext
is decrypted to pj+1,q . Thus programs isLess12,q,2,j,1 and isLess12,q,2,j,0 have the same functionality.
That is, we replace L∗j,q = ACE.EncEK2 (j, m∗1 , q) with L∗j+1,q = ACE.EncEK2 (j + 1, m∗1 , q) in
programs Transform, isLess and RetrieveTags. Indistinguishability holds by security of ACE for
punctured points pj,q , pj+1,q .
That is, we unpuncture ACE keys EK2 , DK2 at the point pj+1,q = (j + 1, m∗1 , q) and remove hardwired
L∗j+1,q = ACE.EncEK2 (j +1, m∗1 , q) in programs Transform, isLess, and RetrieveTags. Indistinguisha-
bility holds by iO.
Note that HybC,1,q,2,j,4 = HybC,1,q,2,j−1,1 for j = T − 1, . . . , 1.
Next we separately consider the case j = −1, switching the output from [−1, m∗1 , q] to [0, m∗1 , q]:
• HybC,1,q,2,−1,1 . We give the adversary (PP, l1∗ , L∗0 , m∗1 , m∗2 ), where PP =
λ ∗ ∗ ∗
Setup(1 ; GenZero[m1 ], Increment, TransformC,1,q,2,−1,1 [(l1 , m2 )], isLessC,1,q,2,−1,1 , RetrieveTag,
RetrieveTagsC,1,q,2,−1,1 ; rSetup ) for randomly chosen rSetup , l1∗ = ACE.EncEK1 (1, m∗1 ),
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ). Description of the programs can be found on fig. 65.
That is, in this hybrid EK2 , DK2 are punctured at the point p0,q = (0, m∗1 , q).
Note that HybC,1,q,2,−1,1 = HybC,1,q,2,j,4 for j = 0.
λ ∗ ∗ ∗
Setup(1 ; GenZero[m1 ], Increment, TransformC,1,q,2,−1,2 [(l1 , m2 )], isLessC,1,q,2,−1,2 , RetrieveTag,
That is, we additionally puncture ACE keys EK2 , DK2 at the point p−1,q = (−1, m∗1 , q) and hardwire
L∗−1,q = ACE.EncEK2 (−1, m∗1 , q) to eliminate the need to encrypt or decrypt p−1,q in programs
Transform, isLess, and RetrieveTags. Indistinguishability holds by iO.
Note that in programs isLess and RetrieveTags we instruct the program to output fail, given L∗−1,q =
ACE.EncEK2 (−1, m∗1 , q) as input, since both programs treat levels with i < 0 as invalid.
Setup(1 ; GenZero[m1 ], Increment, TransformC,1,q,2,−1,3 [(l1∗ , m∗2 )], isLessC,1,q,2,−1,3 , RetrieveTag,
λ ∗
120
That is, we replace L∗−1,q = ACE.EncEK2 (−1, m∗1 , q) with L∗0,q = ACE.EncEK2 (0, m∗1 , q) in programs
Transform, isLess and RetrieveTags. Indistinguishability holds by security of ACE for punctured
points p−1,q , p0,q .
Next we clean up punctured keys:
That is, we unpuncture ACE keys EK2 , DK2 at the point p0,q = (0, m∗1 , q) and remove hardwired
L∗0,q = ACE.EncEK2 (0, m∗1 , q) in programs Transform, isLess, and RetrieveTags. Indistinguishability
holds by iO.
That is, we unpuncture ACE key DK2 at the point p−1,q = (−1, m∗1 , q) in programs Transform, isLess,
and RetrieveTags. Indistinguishability holds by security of a constrained ACE key, since EK2 is
punctured at p−1,q .
That is, we unpuncture ACE key EK2 at the point p−1,q = (−1, m∗1 , q) in program Transform. Indis-
tinguishability holds by iO, since Transform never encrypts this value.
Note that programs isLess and RetrieveTags now output 0 fail0 on input [0, m∗1 , q]. We fix this in the following
hybrids:
• HybC,1,q,4,1 . We give the adversary (PP, l1∗ , L∗0 , m∗1 , m∗2 ), where PP =
λ ∗ ∗ ∗
Setup(1 ; GenZeroC,1,q,4,1 [m1 ], IncrementC,1,q,4,1 , TransformC,1,q,4,1 [(l1 , m2 )], isLessC,1,q,4,1 ,
RetrieveTagC,1,q,4,1 , RetrieveTagsC,1,q,4,1 ; rSetup ) for randomly chosen rSetup , l1∗ =
found on fig. 71.
That is, in this hybrid we puncture ACE encryption key EK1 at p0 = (0, m∗1 ) in programs GenZero
and Increment. Indistinguishability holds by iO, since these programs never encrypt p0 .
λ ∗ ∗ ∗
found on fig. 72.
121
That is, in this hybrid we puncture ACE decryption key DK1 at the same point p0 = (0, m∗1 ) in
programs Increment, Transform, and RetrieveTag. Indistinguishability holds by security of constrained
decryption of ACE, since corresponding encryption key EK1 is already punctured at p0 .
λ ∗ ∗ ∗
found on fig. 73.
That is, in this hybrid we puncture ACE encryption key EK2 at p0,q = (0, m∗1 , q) in program Transform.
Indistinguishability holds by security of iO, since, due to punctured DK1 {p0 }, this program always
outputs 0 fail0 on input ([0, m∗1 ], q) and thus never needs to encrypt p0,q .
λ ∗ ∗ ∗
∗ ∗ ∗ ∗
ACE.EncEK1 (1, m1 ), L0 = ACE.EncEK2 (0, m1 , m2 ). Description of the programs can be
found on fig. 74.
That is, in this hybrid we puncture ACE decryption key DK2 at the same point p0,q = (0, m∗1 , q) in
programs isLess and RetrieveTags. Indistinguishability holds by security of constrained decryption of
ACE, since corresponding encryption key EK2 is already punctured at p0,q .
Setup(1 ; GenZeroC,1,q,4,5 [m∗1 ], IncrementC,1,q,4,5 , TransformC,1,q,4,5 [(l1∗ , m∗2 )], isLessC,1,q,4,5 ,
λ

found on fig. 75.
That is, we remove instructions to output 0 fail0 in programs isLess and RetrieveTags on input [0, m∗1 , q].
Indistinguishability holds by iO, since these instructions are never executed due to the fact that DK2 is
punctured at p0,q = (0, m∗1 , q) and thus the programs output 0 fail0 during decryption.
λ ∗ ∗ ∗
found on fig. 76.
That is, in this hybrid we unpuncture ACE decryption key DK2 at p0,q = (0, m∗1 , q) in programs isLess
and RetrieveTags. Indistinguishability holds by security of constrained decryption of ACE, since
corresponding encryption key EK2 is punctured at p0,q .
λ ∗ ∗ ∗
∗ ∗ ∗ ∗
found on fig. 77.
122
That is, in this hybrid we unpuncture ACE encryption key EK2 at p0,q = (0, m∗1 , q) in program
Transform. Indistinguishability holds by security of iO, since, due to punctured DK1 {p0 }, this program
always outputs 0 fail0 on input ([0, m∗1 ], q) and thus never needs to encrypt p0,q .
λ ∗ ∗ ∗
found on fig. 78.
That is, in this hybrid we unpuncture ACE decryption key DK1 at p0 = (0, m∗1 ) in programs Increment,
since corresponding encryption key EK1 is punctured at p0 .
λ ∗ ∗ ∗
∗ ∗ ∗ ∗
found on fig. 79.
That is, in this hybrid we unpuncture ACE encryption key EK1 at p0 = (0, m∗1 ) in programs GenZero
and Increment. Indistinguishability holds by iO, since these programs never encrypt p0 .
This concludes fixing behavior of Transform for the case m2 6= m∗2 . Next we fix the case m2 = m∗2 in a
similar manner, except that we need different hybrids for the case j = −1, 0 (to prevent switching L∗0 to L∗1 ):
• HybC,2,1,1 . We give the adversary (PP, l1∗ , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZero[m∗1 ],
Increment, TransformC,2,1,1 [(l1∗ , m∗2 )], isLessC,2,1,1 , RetrieveTag, RetrieveTagsC,2,1,1 , l1∗ =
on fig. 80.
Note that HybC,1,q,4,9 = HybC,2,1,1 for q = 2|m2 | .
Increment, TransformC,2,1,2 [(l1∗ , m∗2 )], isLessC,2,1,2 , RetrieveTag, RetrieveTagsC,2,1,2 , l1∗ =
on fig. 81.
That is, in program Transform we puncture ACE encryption key EK2 at the point pT,m∗2 = (T, m∗1 , m∗2 ).
Indistinguishability holds by iO, since Transform never encrypts this plaintext.
Increment, TransformC,2,1,3 [(l1∗ , m∗2 )], isLessC,2,1,3 , RetrieveTag, RetrieveTagsC,2,1,3 ; rSetup ) for ran-
That is, in programs isLess and RetrieveTags we puncture ACE decryption key DK2 at the point
pT,m∗2 = (T, m∗1 , m∗2 ). Indistinguishability holds by security of constrained ACE key, since EK2 is
already punctured at the same point.
We consider the following hybrids for j = T − 1, . . . , 1, switching the output from [j, m∗1 , m∗2 ] to [j +
1, m∗1 , m∗2 ]:
123
• HybC,2,2,j,1 . We give the adversary (PP, l1∗ , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZero[m∗1 ],
Increment, TransformC,2,2,j,1 [(l1∗ , m∗2 )], isLessC,2,2,j,1 , RetrieveTag, RetrieveTagsC,2,2,j,1 ; rSetup ) for
That is, in this hybrid EK2 , DK2 are punctured at the point pj+1,m∗2 = (j + 1, m∗1 , m∗2 ).
Note that HybC,2,1,3 = HybC,2,2,j,1 for j = T − 1.
That is, we additionally puncture ACE keys EK2 , DK2 at the point pj,m∗2 = (j, m∗1 , m∗2 ) and hardwire
L∗j,m∗ = ACE.EncEK2 (j, m∗1 , m∗2 ) to eliminate the need to encrypt or decrypt pj,m∗2 in programs
2
Transform, isLess, and RetrieveTags. Indistinguishability holds by iO.
Note that in program isLess we instruct the program to use the value pj+1,m∗2 = (j + 1, m∗1 , m∗2 ) on
input L∗j,m∗ (instead of correct value pj,m∗2 = (j, m∗1 , m∗2 )). However, this doesn’t change the overall
2
functionality of the program: using pj+1,m∗2 instead of pj,m∗2 could change the result of comparison
only if the other input was an encryption of pj+1,m∗2 (since comparison will result in true when pj,m∗2
is used and false when pj+1,m∗2 is used). However, DK2 is punctured at a set which includes pj+1,m∗2 ,
and thus no ciphertext is decrypted to pj+1,m∗2 . Thus programs isLessC,2,2,j,1 and isLessC,2,2,j,2 have
the same functionality.
That is, we replace L∗j,m∗ = ACE.EncEK2 (j, m∗1 , m∗2 ) with L∗j+1,m∗ = ACE.EncEK2 (j + 1, m∗1 , m∗2 )
2 2
in programs Transform, isLess and RetrieveTags. Indistinguishability holds by security of ACE for
punctured points pj,m∗2 , pj+1,m∗2 .
That is, we unpuncture ACE keys EK2 , DK2 at the point pj+1,m∗2 = (j + 1, m∗1 , m∗2 ) and remove
hardwired L∗j+1,m∗ = ACE.EncEK2 (j + 1, m∗1 , m∗2 ) in programs Transform, isLess, and RetrieveTags.
2
Indistinguishability holds by iO.
Note that HybC,2,2,j,4 = HybC,2,2,j−1,1 for j = T − 1, . . . , 2.
Finally we consider the case j = −1, switching the output from [−1, m∗1 , m∗2 ] to [0, m∗1 , m∗2 ] and cleaning up
any left puncturing:
124
In this hybrid EK2 , DK2 are punctured at the point p1,m∗2 = (1, m∗1 , m∗2 ).
Note that HybC,2,3,1 = HybC,2,2,j,4 for j = 1.
That is, we unpuncture ACE key DK2 at the point p1,m∗2 = (1, m∗1 , m∗2 ). in programs isLess and
RetrieveTags. Indistinguishability holds by security of a constrained ACE key, since EK2 is punctured
at p1,m∗2 .
• HybC,2,3,3 . We give the adversary (PP, l1∗ , L∗0 , m∗1 , m∗2 ), where PP = Setup(1λ ; GenZeroC,2,3,3 [m∗1 ],
IncrementC,2,3,3 , TransformC,2,3,3 [(l1∗ , m∗2 )], isLess, RetrieveTagC,2,3,3 , RetrieveTags; rSetup ) for ran-
That is, we change the following: first, we puncture ACE key EK1 at the point p0 = (0, m∗1 ) in
programs GenZero and Increment: this is without changing the functionality of those programs, since
then never need to encrypt p0 . Second, we unpuncture ACE key EK2 at point p1,m∗2 = (1, m∗1 , m∗2 ) in
program Transform, since this program never needs to encrypt p1,m∗2 due to the first instruction (which
tells the program to output 0 fail0 if it gets ([1, m∗1 ], m∗2 ) as input)). Indistinguishability holds by iO.
That is, in programs Increment and RetrieveTag we puncture ACE decryption key DK1 at the point
p0 = (0, m∗1 ). Indistinguishability holds by security of constrained ACE key, since EK1 is already
That is, we let program Transform output [0, m∗1 , m∗2 ] (instead of [−1, m∗1 , m∗2 ]) on input ([0, m∗1 ], m∗2 ).
This doesn’t change the functionality of the program, since DK1 is punctured the point p0 = (0, m∗1 ),
thus no valid encryption of (0, m∗1 ) exists, and Transform aborts on input [0, m∗1 ], m∗2 . Indistinguisha-
bility holds by iO.
That is, in programs Increment and RetrieveTag we unpuncture ACE decryption key DK1 at the point
p0 = (0, m∗1 ). Indistinguishability holds by security of constrained ACE key, since EK1 is already
125
That is, we unpuncture ACE key EK1 at the point p0 = (0, m∗1 ) in programs GenZero and Increment.
Indistinguishability holds by iO, since neither program encrypts this value.
Note that HybC,2,3,7 = HybD .
Thus, the the advantage of the PPT adversary in distinguishing between HybC and HybD is at most
(2τ (λ) − 1)((2T + 9) · 2−Ω(νiO (λ)) + (T + 1) · 2−Ω(νACE.Indist (λ)) + 6 · 2−Ω(νACE.ConstrDec (λ)) )+
(2(T − 1) + 4) · 2−Ω(νiO (λ)) + (T − 1) · 2−Ω(νACE.Indist (λ)) + 4 · 2−Ω(νACE.ConstrDec (λ)) =
2τ (λ) (T · 2−Ω(νiO (λ)) + T · 2−Ω(νACE.Indist (λ)) + 2−Ω(νACE.ConstrDec (λ)) ).
126
Programs in HybC .
Program GenZeroC [m∗1 ](m1 )
Program IncrementC (l)
Program TransformC [(l1∗ , m∗2 )](l, m2 )
Program isLessC (L0 , L00 )
Program RetrieveTagC (l)
3. Output m1 .
Program RetrieveTagsC (L)
3. Output m1 , m2 .
Figure 57: Programs in HybC . In addition, in this hybrid the adversary gets l1∗ = ACE.EncEK1 (1, m∗1 ),
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
127
Programs in HybC,1,q .
Program TransformC,1,q [(l1∗ , m∗2 )](l, m2 )
ACE.EncEK1 (1, m∗1 ), message q, tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 and m2 = m∗2 return L ← ACE.EncEK2 (i − 1, m1 , m2 );
5. If m1 = m∗1 and m2 ≥ q return L ← ACE.EncEK2 (i − 1, m1 , m2 );
6. Return L ← ACE.EncEK2 (i, m1 , m2 );
Program isLessC,1,q (L0 , L00 )
Program RetrieveTagsC,1,q (L)
3. Output m1 , m2 .
Figure 58: Programs in HybC,1,q . In addition, in this hybrid the adversary gets unmodified obfus-
cated programs GenZero[m∗1 ], Increment and RetrieveTag, together with l1∗ = ACE.EncEK1 (1, m∗1 ),
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
128
Programs in HybC,1,q,1,1 .
Program TransformC,1,q,1,1 [(l1∗ , m∗2 )](l, m2 )
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {pT,q } of ACE punctured at pT,q =
(T, m∗1 , q), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), message q, tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 and m2 = m∗2 return L ← ACE.EncEK2 {pT,q } (i − 1, m1 , m2 );
5. If m1 = m∗1 and m2 ≥ q return L ← ACE.EncEK2 {pT,q } (i − 1, m1 , m2 );
6. Return L ← ACE.EncEK2 {pT,q } (i, m1 , m2 );
Program isLessC,1,q,1,1 (L0 , L00 )
Program RetrieveTagsC,1,q,1,1 (L)
3. Output m1 , m2 .
Figure 59: Programs in HybC,1,q,1,1 . In addition, in this hybrid the adversary gets unmodified ob-
fuscated programs GenZero[m∗1 ], Increment and RetrieveTag, together with l1∗ = ACE.EncEK1 (1, m∗1 ),
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
129
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {pT,q } of ACE punctured at pT,q =
(T, m∗1 , q), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), message q, tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 and m2 = m∗2 return L ← ACE.EncEK2 {pT,q } (i − 1, m1 , m2 );
5. If m1 = m∗1 and m2 ≥ q return L ← ACE.EncEK2 {pT,q } (i − 1, m1 , m2 );
6. Return L ← ACE.EncEK2 {pT,q } (i, m1 , m2 );
Hardwired values: decryption key DK2 {pT,q } of ACE punctured at pT,q = (T, m∗1 , q), upper bound T .
1. out0 ← ACE.DecDK2 {pT,q } (L0 ); if out0 = 0 fail0 then output 0 fail0 ; else parse out0 as (i0 , m01 , m02 ).
2. out00 ← ACE.DecDK2 {pT,q } (L00 ); if out00 = 0 fail0 then output 0 fail0 ; else parse out00 as (i00 , m001 , m002 ).
Hardwired values: decryption key DK2 {pT,q } of ACE punctured at pT,q = (T, m∗1 , q), upper bound T .
1. out ← ACE.DecDK2 {pT,q } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
3. Output m1 , m2 .
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
130
Programs in HybC,1,q,2,j,1 .
Program TransformC,1,q,2,j,1 [(l1∗ , m∗2 )](l, m2 )
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {pj+1,q } of ACE punctured at pj+1,q =
(j + 1, m∗1 , q), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), message q, tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 and m2 = m∗2 return L ← ACE.EncEK2 {pj+1,q } (i − 1, m1 , m2 );
5. If m1 = m∗1 and m2 > q return L ← ACE.EncEK2 {pj+1,q } (i − 1, m1 , m2 );
6. If m1 = m∗1 , m2 = q, and i ≤ j + 1 return L ← ACE.EncEK2 {pj+1,q } (i − 1, m1 , m2 );
7. Return L ← ACE.EncEK2 {pj+1,q } (i, m1 , m2 ).
Program isLessC,1,q,2,j,1 (L0 , L00 )
Hardwired values: decryption key DK2 {pj+1,q } of ACE punctured at pj+1,q = (j + 1, m∗1 , q), upper bound
T.
1. out0 ← ACE.DecDK2 {pj+1,q } (L0 ); if out0 = 0 fail0 then output 0 fail0 ; else parse out0 as (i0 , m01 , m02 ).
2. out00 ← ACE.DecDK2 {pj+1,q } (L00 ); if out00 = 0 fail0 then output 0 fail0 ; else parse out00 as (i00 , m001 , m002 ).
Program RetrieveTagsC,1,q,2,j,1 (L)
Hardwired values: decryption key DK2 {pj+1,q } of ACE punctured at pj+1,q = (j + 1, m∗1 , q), upper bound
T.
1. out ← ACE.DecDK2 {pj+1,q } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
3. Output m1 , m2 .
Figure 61: Programs in HybC,1,q,2,j,1 . In addition, in this hybrid the adversary gets unmodified ob-
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
131
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {pj,q , pj+1,q } of ACE punctured at
pj,q = (j, m∗1 , q), pj+1,q = (j + 1, m∗1 , q), double-tag level L∗j,q = ACE.EncEK2 (j, m∗1 , q), single-tag level
l1∗ = ACE.EncEK1 (1, m∗1 ), message q, tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 and m2 = m∗2 return L ← ACE.EncEK2 {pj,q ,pj+1,q } (i − 1, m1 , m2 );
5. If m1 = m∗1 and m2 > q return L ← ACE.EncEK2 {pj,q ,pj+1,q } (i − 1, m1 , m2 );
6. If m1 = m∗1 , m2 = q, and i = j + 1 return L∗j,q ;
7. If m1 = m∗1 , m2 = q, and i < j + 1 return L ← ACE.EncEK2 {pj,q ,pj+1,q } (i − 1, m1 , m2 );
8. Return L ← ACE.EncEK2 {pj,q ,pj+1,q } (i, m1 , m2 ).
Hardwired values: decryption key DK2 {pj,q , pj+1,q } of ACE punctured at pj,q = (j, m∗1 , q), pj+1,q =
(j + 1, m∗1 , q), double-tag level L∗j,q = ACE.EncEK2 (j, m∗1 , q), upper bound T .
1. If L0 = L∗j,q then set (i0 , m01 , m02 ) = (j + 1, m∗1 , q),
else out0 ← ACE.DecDK2 {pj,q ,pj+1,q } (L0 ); if out0 = 0 fail0 then output 0 fail0 ; else parse out0 as
(i0 , m01 , m02 ).
2. If L00 = L∗j,q then set (i00 , m001 , m002 ) = (j + 1, m∗1 , q),
(i00 , m001 , m002 ).
(j + 1, m∗1 , q), double-tag level L∗j,q = ACE.EncEK2 (j, m∗1 , q), upper bound T .
1. If L = L∗j,q then return (m∗1 , q);
2. out ← ACE.DecDK2 {pj,q ,pj+1,q } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
4. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
132
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {pj,q , pj+1,q } of ACE punctured at
pj,q = (j, m∗1 , q), pj+1,q = (j + 1, m∗1 , q), double-tag level L∗j+1,q = ACE.EncEK2 (j + 1, m∗1 , q), single-tag
level l1∗ = ACE.EncEK1 (1, m∗1 ), message q, tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 and m2 = m∗2 return L ← ACE.EncEK2 {pj,q ,pj+1,q } (i − 1, m1 , m2 );
5. If m1 = m∗1 and m2 > q return L ← ACE.EncEK2 {pj,q ,pj+1,q } (i − 1, m1 , m2 );
6. If m1 = m∗1 , m2 = q, and i = j + 1 return L∗j+1,q ;
7. If m1 = m∗1 , m2 = q, and i < j + 1 return L ← ACE.EncEK2 {pj,q ,pj+1,q } (i − 1, m1 , m2 );
8. Return L ← ACE.EncEK2 {pj,q ,pj+1,q } (i, m1 , m2 ).
(j + 1, m∗1 , q), double-tag level L∗j+1,q = ACE.EncEK2 (j + 1, m∗1 , q), upper bound T .
1. If L0 = L∗j+1,q then set (i0 , m01 , m02 ) = (j + 1, m∗1 , q),
(i0 , m01 , m02 ).
2. If L00 = L∗j+1,q then set (i00 , m001 , m002 ) = (j + 1, m∗1 , q),
(i00 , m001 , m002 ).
(j + 1, m∗1 , q), double-tag level L∗j+1,q = ACE.EncEK2 (j + 1, m∗1 , q), upper bound T .
1. If L = L∗j+1,q then return (m∗1 , q);
2. out ← ACE.DecDK2 {pj,q ,pj+1,q } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
4. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
133
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {pj,q } of ACE punctured at pj,q =
(j, m∗1 , q), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), message q, tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 and m2 = m∗2 return L ← ACE.EncEK2 {pj,q } (i − 1, m1 , m2 );
5. If m1 = m∗1 and m2 > q return L ← ACE.EncEK2 {pj,q } (i − 1, m1 , m2 );
6. If m1 = m∗1 , m2 = q, and i ≤ j return L ← ACE.EncEK2 {pj,q } (i − 1, m1 , m2 );
7. Return L ← ACE.EncEK2 {pj,q } (i, m1 , m2 ).
Hardwired values: decryption key DK2 {pj,q } of ACE punctured at pj,q = (j, m∗1 , q), upper bound T .
1. out0 ← ACE.DecDK2 {pj,q } (L0 ); if out0 = 0 fail0 then output 0 fail0 ; else parse out0 as (i0 , m01 , m02 ).
2. out00 ← ACE.DecDK2 {pj,q } (L00 ); if out00 = 0 fail0 then output 0 fail0 ; else parse out00 as (i00 , m001 , m002 ).
Hardwired values: decryption key DK2 {pj,q } of ACE punctured at pj,q = (j, m∗1 , q), upper bound T .
1. out ← ACE.DecDK2 {pj,q } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
3. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
134
Programs in HybC,1,q,2,−1,1 .
Program TransformC,1,q,2,−1,1 [(l1∗ , m∗2 )](l, m2 )
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {p0,q } of ACE punctured at p0,q =
(0, m∗1 , q), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), message q, tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 and m2 = m∗2 return L ← ACE.EncEK2 {p0,q } (i − 1, m1 , m2 );
5. If m1 = m∗1 and m2 > q return L ← ACE.EncEK2 {p0,q } (i − 1, m1 , m2 );
6. If m1 = m∗1 , m2 = q, and i ≤ 0 return L ← ACE.EncEK2 {p0,q } (i − 1, m1 , m2 );
7. Return L ← ACE.EncEK2 {p0,q } (i, m1 , m2 ).
Program isLessC,1,q,2,−1,1 (L0 , L00 )
Hardwired values: decryption key DK2 {p0,q } of ACE punctured at p0,q = (0, m∗1 , q), upper bound T .
1. out0 ← ACE.DecDK2 {p0,q } (L0 ); if out0 = 0 fail0 then output 0 fail0 ; else parse out0 as (i0 , m01 , m02 ).
Program RetrieveTagsC,1,q,2,−1,1 (L)
1. out ← ACE.DecDK2 {p0,q } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
3. Output m1 , m2 .
Figure 65: Programs in HybC,1,q,2,−1,1 . In addition, in this hybrid the adversary gets unmodified ob-
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
135
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {p−1,q , p0,q } of ACE punctured at
p−1,q = (−1, m∗1 , q), p0,q = (0, m∗1 , q), double-tag level L∗−1,q = ACE.EncEK2 (−1, m∗1 , q), single-tag level
4. If m1 = m∗1 and m2 = m∗2 return L ← ACE.EncEK2 {p−1,q ,p0,q } (i − 1, m1 , m2 );
5. If m1 = m∗1 and m2 > q return L ← ACE.EncEK2 {p−1,q ,p0,q } (i − 1, m1 , m2 );
6. If m1 = m∗1 , m2 = q, and i = 0 return L∗−1,q ;
7. If m1 = m∗1 , m2 = q, and i < 0 return L ← ACE.EncEK2 {p−1,q ,p0,q } (i − 1, m1 , m2 );
8. Return L ← ACE.EncEK2 {p−1,q ,p0,q } (i, m1 , m2 ).
Hardwired values: decryption key DK2 {p−1,q , p0,q } of ACE punctured at p−1,q = (−1, m∗1 , q), p0,q =
(0, m∗1 , q), double-tag level L∗−1,q = ACE.EncEK2 (−1, m∗1 , q), upper bound T .
1. If L0 = L∗−1,q then output 0 fail0 ;
else out0 ← ACE.DecDK2 {p−1,q ,p0,q } (L0 ); if out0 = 0 fail0 then output 0 fail0 ; else parse out0 as
(i0 , m01 , m02 ).
2. If L00 = L∗−1,q then output 0 fail0 ;
(i00 , m001 , m002 ).
(0, m∗1 , q), double-tag level L∗−1,q = ACE.EncEK2 (−1, m∗1 , q), upper bound T .
1. If L = L∗−1,q then output 0 fail0 ;
2. out ← ACE.DecDK2 {p−1,q ,p0,q } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
4. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
136
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {p−1,q , p0,q } of ACE punctured at
p−1,q = (−1, m∗1 , q), p0,q = (0, m∗1 , q), double-tag level L∗0,q = ACE.EncEK2 (0, m∗1 , q), single-tag level
4. If m1 = m∗1 and m2 = m∗2 return L ← ACE.EncEK2 {p−1,q ,p0,q } (i − 1, m1 , m2 );
5. If m1 = m∗1 and m2 > q return L ← ACE.EncEK2 {p−1,q ,p0,q } (i − 1, m1 , m2 );
6. If m1 = m∗1 , m2 = q, and i = 0 return L∗0,q ;
7. If m1 = m∗1 , m2 = q, and i < 0 return L ← ACE.EncEK2 {p−1,q ,p0,q } (i − 1, m1 , m2 );
8. Return L ← ACE.EncEK2 {p−1,q ,p0,q } (i, m1 , m2 ).
(0, m∗1 , q), double-tag level L∗0,q = ACE.EncEK2 (0, m∗1 , q), upper bound T .
1. If L0 = L∗0,q then output 0 fail0 ;
(i0 , m01 , m02 ).
2. If L00 = L∗0,q then output 0 fail0 ;
(i00 , m001 , m002 ).
(0, m∗1 , q), double-tag level L∗0,q = ACE.EncEK2 (0, m∗1 , q), upper bound T .
1. If L = L∗0,q then output 0 fail0 ;
2. out ← ACE.DecDK2 {p−1,q ,p0,q } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
4. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
137
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {p−1,q } of ACE punctured at p−1,q =
(−1, m∗1 , q), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), message q, tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 and m2 = m∗2 return L ← ACE.EncEK2 {p−1,q } (i − 1, m1 , m2 );
5. If m1 = m∗1 and m2 ≥ q + 1 return L ← ACE.EncEK2 {p−1,q } (i − 1, m1 , m2 );
6. Return L ← ACE.EncEK2 {p−1,q } (i, m1 , m2 ).
Hardwired values: decryption key DK2 {p−1,q } of ACE punctured at p−1,q = (−1, m∗1 , q), message q, tag
m∗1 , upper bound T .
1. out0 ← ACE.DecDK2 {p−1,q } (L0 ); if out0 = 0 fail0 then output 0 fail0 ; else parse out0 as (i0 , m01 , m02 ).
2. out00 ← ACE.DecDK2 {p−1,q } (L00 ); if out00 = 0 fail0 then output 0 fail0 ; else parse out00 as (i00 , m001 , m002 ).
4. If (i0 , m01 , m02 ) = (0, m∗1 , q) then output 0 fail0 ;
Hardwired values: decryption key DK2 {p−1,q } of ACE punctured at p−1,q = (−1, m∗1 , q), message q, tag
1. out ← ACE.DecDK2 {p−1,q } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
3. If (i, m1 , m2 ) = (0, m∗1 , q) then output 0 fail0 ;
4. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
138
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {p−1,q } of ACE punctured at p−1,q =
(−1, m∗1 , q), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), message q, tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 and m2 = m∗2 return L ← ACE.EncEK2 {p−1,q } (i − 1, m1 , m2 );
5. If m1 = m∗1 and m2 ≥ q + 1 return L ← ACE.EncEK2 {p−1,q } (i − 1, m1 , m2 );
6. Return L ← ACE.EncEK2 {p−1,q } (i, m1 , m2 ).
Hardwired values: decryption key DK2 of ACE, message q, tag m∗1 , upper bound T .
4. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
139
5. If m1 = m∗1 and m2 ≥ q + 1 return L ← ACE.EncEK2 (i − 1, m1 , m2 );
4. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
140
Program GenZeroC,1,q,4,1 [m∗1 ](m1 )
Hardwired values: encryption key EK1 {p0 } of ACE punctured at p0 = (0, m∗1 ), tag m∗1 .
2. output l ← ACE.EncEK1 {p0 } (0, m1 ).
Program IncrementC,1,q,4,1 (l)
upper bound T .
Program RetrieveTagC,1,q,4,1 (l)
3. Output m1 .
4. Return (m1 , m2 ).
Figure 71: Programs in HybC,1,q,4,1 . In addition, in this hybrid the adversary gets l1∗ = ACE.EncEK1 (1, m∗1 ),
L∗ = ACE.Enc (0, m∗ , m∗ ). 141
0 EK2 1 2
upper bound T .
Hardwired values: decryption key DK1 {p0 } of ACE punctured at p0 = (0, m∗1 ), encryption key EK2 of
ACE, single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), message q, tag m∗1 , tag m∗2 , upper bound T .
2. out ← ACE.DecDK1 {p0 } (l); if out = 0 fail0 then return 0 fail0 ; else parse out as (i, m1 ).
Hardwired values: decryption key DK1 {p0 } of ACE punctured at p0 = (0, m∗1 ), upper bound T .
3. Output m1 .
4. Return (m1 , m2 ).
L∗ = ACE.Enc (0, m∗ , m∗ ). 142
0 EK2 1 2
upper bound T .
Hardwired values: decryption key DK1 {p0 } of ACE punctured at p0 = (0, m∗1 ), encryption key EK2 {p0,q }
of ACE punctured at p0,q = (0, m∗1 , q), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), message q, tag m∗1 , tag
5. If m1 = m∗1 and m2 ≥ q + 1 return L ← ACE.EncEK2 {p0,q } (i − 1, m1 , m2 );
3. Output m1 .
4. Return (m1 , m2 ).
Figure 73: Programs in HybC,1,q,4,3 . In addition, in 143 this hybrid the adversary gets l1∗ = ACE.EncEK1 (1, m∗1 ),
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
upper bound T .
Hardwired values: decryption key DK2 {p0,q } of ACE punctured at p0,q = (0, m∗1 , q), message q, tag m∗1 ,
upper bound T .
3. Output m1 .
Hardwired values: decryption key DK2 {p0,q } of ACE punctured at p0,q = (0, m∗1 , q), message q, tag m∗1 ,
upper bound T .
3. If (i, m1 , m2 ) = (0, m∗1 , q) then output 0 fail0 ; 144
4. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
upper bound T .
3. Output m1 .
3. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
145
upper bound T .
3. Output m1 .
3. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
146
upper bound T .
ACE, single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), message q, tag m∗1 , tag m∗2 , upper bound T .
3. Output m1 .
3. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
147
upper bound T .
3. Output m1 .
3. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
148
3. Output m1 .
3. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
149
Programs in HybC,2,1,1 .
Program TransformC,2,1,1 [(l1∗ , m∗2 )](l, m2 )
5. Return L ← ACE.EncEK2 (i, m1 , m2 );
Program isLessC,2,1,1 (L0 , L00 )
Program RetrieveTagsC,2,1,1 (L)
3. Output m1 , m2 .
Figure 80: Programs in HybC,2,1,1 . In addition, in this hybrid the adversary gets unmodified obfus-
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
150
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {pT,m∗2 } of ACE punctured at pT,m∗2 =
(T, m∗1 , m∗2 ), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 and m2 = m∗2 return L ← ACE.EncEK2 {pT,m∗ } (i − 1, m1 , m2 );
2
5. Return L ← ACE.EncEK2 {pT,m∗ } (i, m1 , m2 );
2

3. Output m1 , m2 .
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
151
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {pT,m∗2 } of ACE punctured at pT,m∗2 =
(T, m∗1 , m∗2 ), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 and m2 = m∗2 return L ← ACE.EncEK2 {pT,m∗ } (i − 1, m1 , m2 );
2
5. Return L ← ACE.EncEK2 {pT,m∗ } (i, m1 , m2 );
2

Hardwired values: decryption key DK2 {pT,m∗2 } of ACE punctured at pT,m∗2 = (T, m∗1 , m∗2 ), upper bound
T.
1. out0 ← ACE.DecDK2 {pT,m∗ } (L0 ); if out0 = 0 fail0 then output 0 fail0 ; else parse out0 as (i0 , m01 , m02 ).
2
2. out00 ← ACE.DecDK2 {pT,m∗ } (L00 ); if out00 = 0 fail0 then output 0 fail0 ; else parse out00 as (i00 , m001 , m002 ).
2
Hardwired values: decryption key DK2 {pT,m∗2 } of ACE punctured at pT,m∗2 = (T, m∗1 , m∗2 ), upper bound
T.
1. out ← ACE.DecDK2 {pT,m∗ } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
2
3. Output m1 , m2 .
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
152
Programs in HybC,2,2,j,1 .
Program TransformC,2,2,j,1 [(l1∗ , m∗2 )](l, m2 )
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {pj+1,m∗2 } of ACE punctured at
pj+1,m∗2 = (j + 1, m∗1 , m∗2 ), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), tag m∗1 , tag m∗2 , index j, upper bound
T.
4. If m1 = m∗1 , m2 = m∗2 and i ≤ j + 1 return L ← ACE.EncEK2 {pj+1,m∗ } (i − 1, m1 , m2 );
2
5. Return L ← ACE.EncEK2 {pj+1,m∗ } (i, m1 , m2 ).
2
Program isLessC,2,2,j,1 (L0 , L00 )

Hardwired values: decryption key DK2 {pj+1,m∗2 } of ACE punctured at pj+1,m∗2 = (j + 1, m∗1 , m∗2 ), upper
bound T .
1. out0 ← ACE.DecDK2 {pj+1,m∗ } (L0 ); if out0 = 0 fail0 then output 0 fail0 ; else parse out0 as (i0 , m01 , m02 ).
2
2. out00 ← ACE.DecDK2 {pj+1,m∗ } (L00 ); if out00 = 0 fail0 then output 0 fail0 ; else parse out00 as (i00 , m001 , m002 ).
2
Program RetrieveTagsC,2,2,j,1 (L)
Hardwired values: decryption key DK2 {pj+1,m∗2 } of ACE punctured at pj+1,m∗2 = (j + 1, m∗1 , m∗2 ), upper
bound T .
1. out ← ACE.DecDK2 {pj+1,m∗ } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
2
3. Output m1 , m2 .
Figure 83: Programs in HybC,2,2,j,1 . In addition, in this hybrid the adversary gets unmodified ob-
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
153
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {pj,m∗2 , pj+1,m∗2 } of ACE punctured
at pj,m∗2 = (j, m∗1 , m∗2 ), pj+1,m∗2 = (j + 1, m∗1 , m∗2 ), double-tag level L∗j,m∗ = ACE.EncEK2 (j, m∗1 , m∗2 ),
2
single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), tag m∗1 , tag m∗2 , index j, upper bound T .
4. If m1 = m∗1 , m2 = m∗2 and i < j + 1 return L ← ACE.EncEK2 {pj,m∗ ,pj+1,m∗ } (i − 1, m1 , m2 );
2 2
5. If m1 = m∗1 , m2 = m∗2 and i = j + 1 return L∗j,m∗ ;
2
6. Return L ← ACE.EncEK2 {pj,m∗ ,pj+1,m∗ } (i, m1 , m2 ).
2 2

Hardwired values: decryption key DK2 {pj,m∗2 , pj+1,m∗2 } of ACE punctured at pj,m∗2 = (j, m∗1 , m∗2 ),
pj+1,m∗2 = (j + 1, m∗1 , m∗2 ), double-tag level L∗j,m∗ = ACE.EncEK2 (j, m∗1 , m∗2 ), upper bound T .
2
1. If L0 = L∗j,m∗ then set (i0 , m01 , m02 ) = (j + 1, m∗1 , m∗2 ),
2
else out0 ← ACE.DecDK2 {pj,m∗ ,pj+1,m∗ } (L0 ); if out0 = 0 fail0 then output 0 fail0 ; else parse out0 as
2 2
(i0 , m01 , m02 ).
2. If L00 = L∗j,m∗ then set (i00 , m001 , m002 ) = (j + 1, m∗1 , m∗2 ),
2
2 2
(i00 , m001 , m002 ).
pj+1,m∗2 = (j + 1, m∗1 , m∗2 ), double-tag level L∗j,m∗ = ACE.EncEK2 (j, m∗1 , m∗2 ), upper bound T .
2
1. If L = L∗j,m∗ then return (m∗1 , m∗2 );
2
2. out ← ACE.DecDK2 {pj,m∗ ,pj+1,m∗ } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
2 2
4. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
154
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {pj,m∗2 , pj+1,m∗2 } of ACE punctured at
pj,m∗2 = (j, m∗1 , m∗2 ), pj+1,m∗2 = (j + 1, m∗1 , m∗2 ), double-tag level L∗j+1,m∗ = ACE.EncEK2 (j + 1, m∗1 , m∗2 ),
2
single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), tag m∗1 , tag m∗2 , index j, upper bound T .
4. If m1 = m∗1 , m2 = m∗2 and i < j + 1 return L ← ACE.EncEK2 {pj+1,m∗ } (i − 1, m1 , m2 );
2
5. If m1 = m∗1 , m2 = m∗2 and i = j + 1 return L∗j+1,m∗ ;
2
6. Return L ← ACE.EncEK2 {pj,m∗ ,pj+1,m∗ } (i, m1 , m2 ).
2 2

pj+1,m∗2 = (j + 1, m∗1 , m∗2 ), double-tag level L∗j+1,m∗ = ACE.EncEK2 (j + 1, m∗1 , m∗2 ), upper bound T .
2
1. If L0 = L∗j+1,m∗ then set (i0 , m01 , m02 ) = (j + 1, m∗1 , m∗2 ),
2
2 2
(i0 , m01 , m02 ).
2. If L00 = L∗j+1,m∗ then set (i00 , m001 , m002 ) = (j + 1, m∗1 , m∗2 ),
2
2 2
(i00 , m001 , m002 ).
pj+1,m∗2 = (j + 1, m∗1 , m∗2 ), double-tag level L∗j+1,m∗ = ACE.EncEK2 (j + 1, m∗1 , m∗2 ), upper bound T .
2
1. If L = L∗j+1,m∗ then return (m∗1 , m∗2 );
2
2. out ← ACE.DecDK2 {pj,m∗ ,pj+1,m∗ } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
2 2
4. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
155
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {pj,m∗2 } of ACE punctured at pj,m∗2 =
(j, m∗1 , m∗2 ), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), tag m∗1 , tag m∗2 , index j, upper bound T .
4. If m1 = m∗1 , m2 = m∗2 and i ≤ j return L ← ACE.EncEK2 {pj,m∗ } (i − 1, m1 , m2 );
2
5. Return L ← ACE.EncEK2 {pj,m∗ } (i, m1 , m2 ).
2

Hardwired values: decryption key DK2 {pj,m∗2 } of ACE punctured at pj,m∗2 = (j, m∗1 , m∗2 ), upper bound T .
1. out0 ← ACE.DecDK2 {pj,m∗ } (L0 ); if out0 = 0 fail0 then output 0 fail0 ; else parse out0 as (i0 , m01 , m02 ).
2
2. out00 ← ACE.DecDK2 {pj,m∗ } (L00 ); if out00 = 0 fail0 then output 0 fail0 ; else parse out00 as (i00 , m001 , m002 ).
2
Hardwired values: decryption key DK2 {pj,m∗2 } of ACE punctured at pj,m∗2 = (j, m∗1 , m∗2 ), upper bound T .
1. out ← ACE.DecDK2 {pj,m∗ } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
2
3. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
156
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {p1,m∗2 } of ACE punctured at p1,m∗2 =
(1, m∗1 , m∗2 ), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 , m2 = m∗2 and i ≤ 1 return L ← ACE.EncEK2 {p1,m∗ } (i − 1, m1 , m2 );
2
5. Return L ← ACE.EncEK2 {p1,m∗ } (i, m1 , m2 ).
2

Hardwired values: decryption key DK2 {p1,m∗2 } of ACE punctured at p1,m∗2 = (1, m∗1 , m∗2 ), upper bound T .
1. out0 ← ACE.DecDK2 {p1,m∗ } (L0 ); if out0 = 0 fail0 then output 0 fail0 ; else parse out0 as (i0 , m01 , m02 ).
2
2. out00 ← ACE.DecDK2 {p1,m∗ } (L00 ); if out00 = 0 fail0 then output 0 fail0 ; else parse out00 as (i00 , m001 , m002 ).
2
Hardwired values: decryption key DK2 {p1,m∗2 } of ACE punctured at p1,m∗2 = (1, m∗1 , m∗2 ), upper bound T .
1. out ← ACE.DecDK2 {p1,m∗ } (L); if out = 0 fail0 then output 0 fail0 ; else parse out as (i, m1 , m2 ).
2
3. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
157
Hardwired values: decryption key DK1 of ACE, encryption key EK2 {p1,m∗2 } of ACE punctured at p1,m∗2 =
(1, m∗1 , m∗2 ), single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 , m2 = m∗2 and i ≤ 1 return L ← ACE.EncEK2 {p1,m∗ } (i − 1, m1 , m2 );
2
5. Return L ← ACE.EncEK2 {p1,m∗ } (i, m1 , m2 ).
2

3. Return (m1 , m2 ).
L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
158
4. If m1 = m∗1 , m2 = m∗2 , and i ≤ 0, return L ← ACE.EncEK2 (i − 1, m1 , m2 );
Program GenZeroC,2,3,3 [m∗1 ](m1 )
Program IncrementC,2,3,3 (l)
upper bound T .
Program RetrieveTagC,2,3,3 (l)
3. Output m1 .
Figure 89: Programs in HybC,2,3,3 . In addition, in this hybrid the adversary gets unmodified obfuscated
159
ACE, single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), tag m∗1 , tag m∗2 , upper bound T .
4. If m1 = m∗1 , m2 = m∗2 , and i ≤ 0, return L ← ACE.EncEK2 (i − 1, m1 , m2 );
upper bound T .
3. Output m1 .
160
ACE, single-tag level l1∗ = ACE.EncEK1 (1, m∗1 ), tag m∗2 , upper bound T .
upper bound T .
3. Output m1 .
161
upper bound T .
3. Output m1 .
162
2. Output l ← ACE.EncEK1 (0, m1 ).
3. Output m1 .
163
7.5 Security reductions
7.5.1 Reductions in the proof of lemma 2 (Switching from `∗0 to `∗1 )
We show that for any PPT adversary,
advHybA ,HybB (λ) ≤ T · 2−Ω(νiO (λ)) + T · 2−Ω(νACE.Indist (λ)) + 2−Ω(νACE.ConstrDec (λ)) .
Lemma 5. advHybA ,HybA,1,1 (λ) ≤ 2−Ω(νiO (λ)) .
Proof. In programs GenZeroA,1,1 and IncrementA,1,1 encryption key EK1 is punctured at pT +1 = (T +

1, m∗1 ). This is without changing the functionality, since GenZero only encrypts plaintexts of the form
(0, m1 ), and Increment outputs 0 fail0 when i = T and thus never encrypts (T + 1, m∗1 ).
Lemma 6. advHybA,1,1 ,HybA,1,2 (λ) ≤ 2−Ω(νACE.ConstrDec (λ)) .
Proof. Indistinguishability immediately follows from security of constrained decryption of ACE for the
challenge set {pT +1 } = {(T + 1, m∗1 )} to puncture encryption key EK1 and challenge sets {pT +1 } , ∅ to
puncture decryption key DK1 . Indeed, given EK1 {pT +1 } and key which is either DK1 or DK1 {pT +1 }, it is
easy to reconstruct the rest of the distribution.
Lemma 7. advHybA,2,j,1 ,HybA,2,j,2 (λ) ≤ 2−Ω(νiO (λ)) for 1 ≤ j ≤ T .
Proof. In programs GenZero, Increment, Transform, RetrieveTag we puncture EK1 , DK1 at pj = (j, m∗1 )
and hardwire `∗j = ACE.EncEK1 (j, m∗1 ) when required, in order to preserve functionality.
In program GenZeroA,2,j,2 we can puncture EK1 at pj without changing the functionality, since GenZeroA,2,j,2
only encrypts plaintexts of the form (0, m1 ) (note that j ≥ 1).
In program IncrementA,2,j,2 we puncture DK1 at pj and, in order to preserve the functionality, instruct the
program to output ACE.EncEK1 (j + 2, m∗1 ) on input `∗j (note that this is what IncrementA,2,j,1 outputs on
input `∗j )33 . Further, we puncture EK1 at pj and, in order to preserve the functionality, instruct the program to
output `∗j on input ACE.EncEK1 (j − 1, m∗1 ) (note that this is what IncrementA,2,j,1 does).
In program TransformA,2,j,2 we puncture DK1 at pj and, in order to preserve the functionality, instruct
the program to output ACE.EncEK2 (j, m∗1 , m2 ) on input (`∗j , m2 ) for any m2 (note that this is what
TransformA,2,j,1 does). Because of this instruction, we can also instruct TransformA,2,j,2 to output 0 fail0 when
(i, m1 ) = (j, m∗1 ), since this line will never be reached.
In program RetrieveTagA,2,j,2 we puncture DK1 at pj and, in order to preserve the functionality, instruct the
program to output m∗1 on input `∗j (note that this is what RetrieveTagA,2,j,1 does).
Lemma 8. advHybA,2,j,2 ,HybA,2,j,3 (λ) ≤ 2−Ω(νACE.Indist (λ)) for 1 ≤ j ≤ T .
Proof. Indistinguishability immediately follows from indistinguishability of ACE ciphertexts for the chal-
lenge plaintexts pj = (j, m∗1 ) and pj+1 = (j + 1, m∗1 ). Indeed, given EK1 {pj , pj+1 }, DK1 {pj , pj+1 }, and
33
Except for the case j = T , when we instead instruct the program to output 0 fail0 .
164
either `∗j = ACE.EncEK1 (j, m∗1 ) or `∗j+1 = ACE.EncEK1 (j + 1, m∗1 ), it is easy to reconstruct the rest of
the distribution. Note that indeed only one of the two ciphertexts is used in both hybrids (in particular,
since j ≥ 1, the key is never punctured at p0 = (0, m∗1 ) and therefore we can always compute `∗0 for the
distribution).
Lemma 9. advHybA,2,j,3 ,HybA,2,j,4 (λ) ≤ 2−Ω(νiO (λ)) for 1 ≤ j ≤ T .
Proof. In programs GenZero, Increment, Transform, RetrieveTag we unpuncture EK1 , DK1 at pj+1 =
(j + 1, m∗1 ) and remove hardwired `∗j+1 = ACE.EncEK1 (j + 1, m∗1 ):
In program GenZeroA,2,j,4 we can unpuncture EK1 at pj+1 without changing the functionality, since
GenZeroA,2,j,3 only encrypts plaintexts of the form (0, m1 ) (note that j ≥ 1).
In program IncrementA,2,j,4 we unpuncture DK1 at pj+1 , remove the instruction to output ACE.EncEK1 (j +
2, m∗1 ) on input `∗j+1 and, in order to preserve the functionality, instruct the program to output ACE.EncEK1 (j+
2, m∗1 ) when (i, m1 ) = (j + 1, m∗1 ) (we don’t put any separate instruction since this is normal behavior
of Increment); 34 . Further, we unpuncture EK1 at pj+1 , remove the instruction to output `∗j+1 on in-
put ACE.EncEK1 (j − 1, m∗1 ) and, in order to preserve the functionality, instruct the program to output
ACE.EncEK1 (j + 1, m∗1 ) when (i, m1 ) = (j − 1, m∗1 ).
In program TransformA,2,j,4 we unpuncture DK1 at pj , remove the instruction to output
ACE.EncEK2 (j, m∗1 , m2 ) on input (`∗j+1 , m2 ) for any m2 and, in order to preserve the functionality, instruct
the program to output ACE.EncEK2 (i − 1, m1 , m2 ) when (i, m1 ) = (j + 1, m∗1 ).
In program RetrieveTagA,2,j,4 we unpuncture DK1 at pj+1 and remove the instruction to output m∗1 on input
`∗j+1 . No additional change is required since this is what RetrieveTag would normally output35 .
Lemma 10. advHybA,2,0,1 ,HybA,2,0,2 (λ) ≤ 2−Ω(νiO (λ)) .
Proof. In programs GenZero, Increment, Transform, RetrieveTag we puncture EK1 , DK1 at p0 = (0, m∗1 )
and hardwire `∗0 = ACE.EncEK1 (0, m∗1 ) when required, in order to preserve functionality:
In program GenZeroA,2,0,2 we can puncture EK1 at p0 without changing the functionality, since
GenZeroA,2,0,2 outputs 0 fail0 when m1 = m∗1 .
In program IncrementA,2,0,2 we puncture DK1 at p0 and, in order to preserve the functionality, instruct the
program to output ACE.EncEK1 (2, m∗1 ) on input `∗0 (note that this is what IncrementA,2,0,1 outputs on input
`∗0 ). Further, we puncture EK1 at p0 : this is without changing the functionality, since this program never
needs to encrypt plaintexts with value 0.
In program TransformA,2,0,2 we puncture DK1 at p0 and, in order to preserve the functionality, instruct
the program to output ACE.EncEK2 (0, m∗1 , m2 ) on input (`∗0 , m2 ) for any m2 (note that this is what
TransformA,2,0,1 does). Because of this instruction, we can also instruct TransformA,2,0,2 to output 0 fail0
when (i, m1 ) = (0, m∗1 ), since this line will never be reached.
34
Except for the case j = T , when we instead remove the instruction to output 0 fail0 . Note that Increment outputs 0 fail0 when
i = T + 1 so no additional modification is required. The other exception is the case j = T − 1, where IncrementA,2,j,3 contains
the instruction to output ACE.EncEK1 (T + 1, m∗1 ) on input `∗T , and thus in IncrementA,2,j,4 we change the upper bound from T to
T + 1 for the case m1 = m∗1 in order to preserve the functionality.
35
Except for the case j = T , which instruct the program to output m∗1 on input `∗T +1 . In this case we additionally change the
upper bound to T + 1, instead of T , for the case m1 = m∗1 in program RetrieveTagA,2,j,4
165
In program RetrieveTagA,2,0,2 we puncture DK1 at p0 and, in order to preserve the functionality, instruct the
program to output m∗1 on input `∗0 (note that this is what RetrieveTagA,2,0,1 does).
Lemma 11. advHybA,2,0,2 ,HybA,2,0,3 (λ) ≤ 2−Ω(νACE.Indist (λ)) .
lenge plaintexts p0 = (0, m∗1 ) and p1 = (1, m∗1 ). Indeed, given EK1 {p0 , p1 }, DK1 {p0 , p1 }, and either
`∗0 = ACE.EncEK1 (0, m∗1 ) or `∗1 = ACE.EncEK1 (1, m∗1 ), it is easy to reconstruct the rest of the distribution.
Note that indeed only one of the two ciphertexts is used in both hybrids (in particular, a single-tag level we
give to the adversary is either `∗0 or `∗1 ).
Lemma 12. advHybA,2,0,3 ,HybA,3,1 (λ) ≤ 2−Ω(νiO (λ)) .
Proof. In programs GenZero, Increment, Transform, RetrieveTag we unpuncture EK1 , DK1 at p1 = (1, m∗1 )
and remove hardwired `∗1 = ACE.EncEK1 (j + 1, m∗1 ):
In program GenZeroA,3,2 we can unpuncture EK1 at p1 without changing the functionality, since
GenZeroA,2,0,3 only encrypts plaintexts of the form (0, m1 ).
In program IncrementA,3,1 we unpuncture DK1 at p1 and remove the additional instruction to output
ACE.EncEK1 (2, m∗1 ) on input `∗1 (this is without changing the functionality, since this is what the pro-
gram normally does). Further, we unpuncture EK1 at p1 without changing the functionality: indeed, the
program could possibly encrypt p1 only given an encryption of p0 as input. However, DK1 is punctured at p0
and thus the program would instead output 0 fail0 on such input.
In program TransformA,3,1 we instruct the program to output ACE.EncEK2 (i − 1, m1 , m2 ), given an encryp-
tion of (i, m∗1 ) and m2 as input, in the whole range of i from 0 to T . In contrast, program TransformA,2,0,3
does this only for 2 ≤ i ≤ T . However, this is without changing the functionality: first, TransformA,2,0,3
outputs ACE.EncEK2 (0, m∗1 , m2 ), given `∗1 and m2 as input, thus we didn’t change the case i = 1. Second,
DK1 is punctured at p0 , and thus we can arbitrary change behaviour for the case i = 0 since the program
never reaches that line when i = 0, outputting 0 fail0 during decryption.
With this modification, we can remove the instruction to output ACE.EncEK2 (0, m∗1 , m2 ) on input (`∗1 , m2 )
and then unpuncture DK1 at point p1 .
In program RetrieveTagA,3,1 we unpuncture DK1 at p1 and remove the instruction to output m∗1 on input `∗1 .
No additional change is required since this is what RetrieveTag would normally output.
Lemma 13. advHybA,3,1 ,HybA,3,2 (λ) ≤ 2−Ω(νACE.ConstrDec (λ)) .
challenge set {p0 } = {(0, m∗1 )} to puncture encryption key EK1 and challenge sets {p0 } , ∅ to puncture
decryption key DK1 . Indeed, given EK1 {p0 } and key which is either DK1 or DK1 {p0 }, it is easy to
reconstruct the rest of the distribution.
Lemma 14. advHybA,3,2 ,HybA,3,3 (λ) ≤ 2−Ω(νiO (λ)) .
166
Proof. In programs GenZero and Increment we unpuncture EK1 at p0 = (0, m∗1 ). This doesn’t change the
functionality, since GenZero outputs 0 fail0 when m1 = m∗1 , and Increment never encrypts a plaintext with
value 0.
7.5.2 Reductions in the proof of lemma 3 (Changing the upper bound from T + 1 to T )
We show that
1
advHybB ,HybC (λ) ≤ 2−Ω(γ(λ)) + + T · 2−Ω(νiO (λ)) + T · 2−Ω(νACE.ConstrDec (λ)) .
T
(1/T term comes from the fact that the reduction works only when i∗ 6= 0, where i∗ is chosen randomly
between 0 and T ).
Lemma 15. advHybB ,HybB,1,1 (λ) ≤ 2−Ω(γ(λ)) .
Proof. Assume there is a poly-time distinguisher D which distinguishes between these two hybrids with
probability η ≥ 2−o(γ(λ)) (for infinitely many λi ). Then, since:
• programs IncrementB and IncrementB,1,1 differ only at one point (due to the fact that g is injective);
• η ≥ 2−o(γ(λ)) ≥ 2−o(νiO (λ)) (from the condition γ(λ) ≤ O(νiO (λ))) in the theorem statement),
it follows from lemma 1 that there exists an inverter which runs in time at most O(1/η) log T =
2o(γ(λ)) log T , which by the condition in the theorem statement is at most O(2νOWF (log T ) ). This inverter
inverts the one way function with probability at least (1 − 2−Ω(λ) )η, which contradicts the fact that g is
2O(νOWF (λ log T )) , 2−Ω(νOWF (λ log T )) -secure OWF.
Lemma 16. advHybB,1,1 ,HybB,1,2 (λ) ≤ 2−Ω(νiO (λ)) .
Proof. First, note that both programs GenZeroB,1,1 and GenZeroB,1,2 are functionally equivalent: since
i∗ + 1 6= 0, and GenZero only needs to encrypt value 0, we can safely puncture EK1 at (i∗ + 1, m∗1 ).
Second, programs IncrementB,1,1 and IncrementB,1,2 are functionally equivalent as well: the only difference
in the code is that the first outputs 0 fail0 when (m1 , i) = (m∗1 , i∗ ) (on input ACE.EncEK1 (i∗ , m∗1 )), and the
second instead outputs 0 fail0 when it tries to encrypt a punctured point (i∗ + 1, m∗1 ), which happens on the
same input ACE.EncEK1 (i∗ , m∗1 ).
Lemma 17. If i∗ 6= 0, advHybB,2,j,1 ,HybB,2,j,2 (λ) ≤ 2−Ω(νACE.ConstrDec (λ)) for i∗ ≤ j ≤ T .
challenge set Si∗ +1,j+1 to puncture encryption key EK1 and challenge sets Si∗ +1,j , Si∗ +1,j+1 to puncture
decryption key DK1 (here Sa,b = {(m∗1 , a), (m∗1 , a + 1), . . . , (m∗1 , b)} if b ≥ a and ∅ otherwise). Indeed,
given EK1 {Si∗ +1,j+1 } and key which is either DK1 {Si∗ +1,j } or DK1 {Si∗ +1,j+1 }, it is easy to reconstruct
the rest of the distribution, as long as i∗ 6= 0. That is, we can sample remaining keys, obfuscate all programs,
and compute `∗1 = ACE.EncEK1 (1, m∗1 ) (using the challenge encryption key EK1 {Si∗ +1,j+1 } which is not
punctured at (1, m∗1 ) since i∗ 6= 0) and L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
Lemma 18. advHybB,2,j,2 ,HybB,2,j,3 (λ) ≤ 2−Ω(νiO (λ)) for i∗ ≤ j ≤ T .
167
Proof. In programs GenZero, Increment we additionally puncture EK1 at pj+2 = (j + 2, m∗1 ).
In program GenZero we can puncture EK1 at pj+2 without changing the functionality, since GenZero only
encrypts plaintexts of the form (0, m1 ), but j + 2 6= 0.
In program Increment we can puncture EK1 at pj+2 without changing the functionality, since DK1 is
punctured at the point pj+1 , thus Increment never needs to encrypt pj+2 since on input [j + 1, m∗1 ] it instead
outputs 0 fail0 during decryption.
Proof. In programs Increment, Transform, and RetrieveTag we change the upper bound from T + 1 back to
T.
In particular, in program IncrementB,3,2 we now additionally output 0 fail0 when i = T and m1 = m∗1 . This
is without changing the functionality, since this line is never reached: both programs IncrementB,3,1 and
IncrementB,3,2 anyway output 0 fail0 on input [T, m∗1 ], since DK1 is punctured at (T, m∗1 ).
In program Transform we now additionally output 0 fail0 when i = T + 1 and m1 = m∗1 . This is without
changing the functionality, since this line is never reached: both programs TransformB,3,1 and TransformB,3,2
anyway output 0 fail0 on input [T + 1, m∗1 ] and any m2 , since DK1 is punctured at (T + 1, m∗1 ).
In program RetrieveTag we now additionally output 0 fail0 when i = T + 1 and m1 = m∗1 . This is
without changing the functionality, since this line is never reached: both programs RetrieveTagB,3,1 and
RetrieveTagB,3,2 anyway output 0 fail0 on input [T + 1, m∗1 ], since DK1 is punctured at (T + 1, m∗1 ).
Lemma 20. If i∗ 6= 0, advHybB,4,j,1 ,HybB,4,j,2 (λ) ≤ 2−Ω(νACE.ConstrDec (λ)) for i∗ ≤ j ≤ T .
challenge set Si∗ +1,j+1 to puncture encryption key EK1 and challenge sets Si∗ +1,j , Si∗ +1,j+1 to puncture
decryption key DK1 (here Sa,b = {(m∗1 , a), (m∗1 , a + 1), . . . , (m∗1 , b)} if b ≥ a and ∅ otherwise). Indeed,
given EK1 {Si∗ +1,j+1 } and key which is either DK1 {Si∗ +1,j } or DK1 {Si∗ +1,j+1 }, it is easy to reconstruct
the rest of the distribution, as long as i∗ 6= 0. That is, we can sample remaining keys, obfuscate all programs,
and compute `∗1 = ACE.EncEK1 (1, m∗1 ) (using the challenge encryption key EK1 {Si∗ +1,j+1 } which is not
punctured at (1, m∗1 ) since i∗ 6= 0) and L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
Lemma 21. advHybB,4,j,2 ,HybB,4,j,3 (λ) ≤ 2−Ω(νiO (λ)) for i∗ ≤ j ≤ T .
Proof. In programs GenZero, Increment we unpuncture EK1 at pj+1 = (j + 1, m∗1 ).

In program GenZero we can unpuncture EK1 at pj+1 without changing the functionality, since GenZero only
encrypts plaintexts of the form (0, m1 ), but j + 1 6= 0.
In program Increment we can unpuncture EK1 at pj+1 without changing the functionality, since DK1 is
punctured at the point pj , thus Increment never needs to encrypt pj+1 since on input [j, m∗1 ] it instead outputs
0 fail0 during decryption.
168
Proof. First, note that both programs GenZeroB,5,1 and GenZeroB,5,2 are functionally equivalent: since
i∗ + 1 6= 0, and GenZero only needs to encrypt value 0, we can safely unpuncture EK1 at (i∗ + 1, m∗1 ).
Second, programs IncrementB,5,1 and IncrementB,5,2 are functionally equivalent as well: the only difference
in the code is that the first outputs 0 fail0 when it tries to encrypt a punctured point (i∗ + 1, m∗1 ) (which happens
on input ACE.EncEK1 (i∗ , m∗1 )), and the second outputs 0 fail0 when (m1 , i) = (m∗1 , i∗ ), which happens on the
same input ACE.EncEK1 (i∗ , m∗1 ).
Lemma 23. advHybB,5,2 ,HybB,5,3 (λ) ≤ 2−Ω(γ(λ)) .
Proof. Assume there is a poly-time distinguisher D which distinguishes between these two hybrids with
probability η ≥ 2−o(γ(λ)) (for infinitely many λi ). Then, since:
• programs IncrementB and IncrementB,1,1 differ only at one point (due to the fact that g is injective);
• η ≥ 2−o(γ(λ)) ≥ 2−o(νiO (λ)) (from the condition γ(λ) ≤ O(νiO (λ))) in the theorem statement),
it follows from lemma 1 that there exists an inverter which runs in time at most O(1/η) log T =
2o(γ(λ)) log T , which by the condition in the theorem statement is at most O(2νOWF (log T ) ). This inverter
inverts the one way function with probability at least (1 − 2−Ω(λ) )η, which contradicts the fact that g is
2O(νOWF (λ log T )) , 2−Ω(νOWF (λ log T )) -secure OWF.
7.5.3 Reductions in the proof of lemma 4 (Restoring behavior of Transform)

We show that
advHybC ,HybD (λ) ≤ 2τ (λ) (T · 2−Ω(νiO (λ)) + T · 2−Ω(νACE.Indist (λ)) + 2−Ω(νACE.ConstrDec (λ)) ).
Lemma 24. advHybC,1,q ,HybC,1,q,1,1 (λ) ≤ 2−Ω(νiO (λ)) .
Proof. In program Transform we puncture encryption key EK2 at pT,q = (T, m∗1 , q). This is without
changing the functionality, since Transform never encrypts this point: indeed, it encrypts (i − 1, m1 , m2 )
when m2 = q, but will abort instead if i = T + 1.
Lemma 25. advHybC,1,q,1,1 ,HybC,1,q,1,2 (λ) ≤ 2−Ω(νACE.ConstrDec (λ)) for q 6= m∗2 .
challenge set {pT,q } = {(T, m∗1 , q)} to puncture encryption key EK2 and challenge sets {pT,q }, ∅ to puncture
decryption key DK2 . Indeed, given EK2 {pT,q } and key which is either DK2 {pT,q } or DK2 , it is easy to
reconstruct the rest of the distribution. That is, we can sample remaining keys, obfuscate all programs, and
compute `∗1 = ACE.EncEK1 (1, m∗1 ) and L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ) (using the challenge encryption key
EK2 {pT,q } which is not punctured at (0, m∗1 , m∗2 ).
Lemma 26. advHybC,1,q,2,j,1 ,HybC,1,q,2,j,2 (λ) ≤ 2−Ω(νiO (λ)) , for q 6= m∗2 , 0 ≤ j ≤ T − 1.
Proof. We puncture ACE keys EK2 , DK2 at the point pj,q = (j, m∗1 , q) and hardwire L∗j,q =
ACE.EncEK2 (j, m∗1 , q) to eliminate the need to encrypt or decrypt pj,q in programs Transform, isLess, and
RetrieveTags, without changing their functionality.
169
More specifically, in program Transform we puncture EK2 at pj,q = (j, m∗1 , q) and, in order to preserve the
functionality, add an instruction to output L∗j,q = ACE.EncEK2 (j, m∗1 , q) when (i, m1 , m2 ) = (j + 1, m∗1 , q).
In program isLess we puncture decryption key DK2 at pj,q = (j, m∗1 , q) and, in order to preserve the
functionality, instruct the program not to decrypt L∗j,q , but to use (j + 1, m∗1 , q) as the result of decryption
instead. Note that this is different from what L∗j,q would normally decrypt to, which is (j, m∗1 , q). However,
we argue that this doesn’t change the functionality of the program. Indeed:
• The set of inputs on which isLess outputs 0 fail0 isn’t changed; in particular, since 0 ≤ j ≤ T − 1, both
(j, m∗1 , q) and (j + 1, m∗1 , q) are within 0 to T limits and thus are both valid.
• The result of the comparison on inputs [i0 , m1 , m2 ] and [i00 , m1 , m2 ], where (m1 , m2 ) 6= (m∗1 , q),
remains the same;
• The result of the comparison on inputs [i0 , m∗1 , q] and [i00 , m∗1 , q], where i0 , i00 6= j and i0 , i00 6= j + 1,
remains the same;
• The output of the program on inputs ([i0 , m∗1 , q], [i00 , m∗1 , q]), where i0 = j + 1 or i00 = j + 1, is 0 fail0
for both the original and modified programs, since DK2 is punctured at pj+1,q = (j + 1, m∗1 , q) and
thus decryption returns 0 fail0 ;
• The result of the comparison on inputs ([i0 , m∗1 , q], [j, m∗1 , q] = L∗j,q ), remains the same, since for both
programs the output is:
– true for 0 ≤ i0 < j;
– false for i0 = j (indeed, in the original program in this case i0 = i00 = j, and in the modified
program i0 = i00 = j + 1, since [i0 , m∗1 , q] = L∗j,q when i0 = j and the program uses j + 1 as the
decryption result);
– 0 fail0 for i0 = j + 1, since DK2 is punctured at pj+1,q = (j + 1, m∗1 , q) and thus decryption returns
0 fail0 ;
– false for j + 2 ≤ i0 ≤ T .
• Similarly, the result of the comparison on inputs ([j, m∗1 , q] = L∗j,q , [i0 , m∗1 , q]) remains the same for
the original program and modified program (with the difference that the result is false for 0 ≤ i0 < j
and true for j + 2 ≤ i0 ≤ T ).
In program RetrieveTags we puncture decryption key DK2 at pj,q = (j, m∗1 , q) and, in order to preserve the
functionality, instruct the program to output (m∗1 , q) on input L∗j,q .
Lemma 27. advHybC,1,q,2,j,2 ,HybC,1,q,2,j,3 (λ) ≤ 2−Ω(νACE.Indist (λ)) , for q 6= m∗2 , 0 ≤ j ≤ T − 1.
Proof. Indistinguishability immediately follows from indistinguishability of ACE ciphertexts for the
challenge plaintexts pj,q = (j, m∗1 , q) and pj+1,q = (j + 1, m∗1 , q). Indeed, given EK2 {pj,q , pj+1,q },
DK2 {pj,q , pj+1,q }, and either L∗j,q = ACE.EncEK2 (j, m∗1 , q) or L∗j+1,q = ACE.EncEK2 (j + 1, m∗1 , q), it
is easy to reconstruct the rest of the distribution. That is, we can sample remaining keys, obfuscate all
program (note that indeed at most one of two ciphertexts L∗j,q , L∗j+1,q is used in programs of HybC,1,q,2,j,2
and HybC,1,q,2,j,3 ), and compute `∗1 = ACE.EncEK1 (1, m∗1 ) and L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ) (using the
challenge encryption key EK2 {pj,q , pj+1,q } which is not punctured at (0, m∗1 , m∗2 ) since q 6= m∗2 ).
170
Lemma 28. advHybC,1,q,2,j,3 ,HybC,1,q,2,j,4 (λ) ≤ 2−Ω(νiO (λ)) , for q 6= m∗2 , 0 ≤ j ≤ T − 1.
Proof. We unpuncture ACE keys EK2 , DK2 at the point pj+1,q = (j + 1, m∗1 , q) and remove hardwired
L∗j+1,q = ACE.EncEK2 (j + 1, m∗1 , q) in programs Transform, isLess, and RetrieveTags, without changing
their functionality.
More specifically, in program Transform we unpuncture EK2 at pj+1,q = (j + 1, m∗1 , q) and remove an
instruction to output L∗j+1,q = ACE.EncEK2 (j +1, m∗1 , q) when (i, m1 , m2 ) = (j +1, m∗1 , q). This is without
changing the functionality, since now the program will run an encryption ACE.EncEK2 (j + 1, m∗1 , q) when
(i, m1 , m2 ) = (j + 1, m∗1 , q), instead of directly outputting hardwired L∗j+1,q .
In program isLess we unpuncture decryption key DK2 at pj+1,q = (j + 1, m∗1 , q) and remove an instruction
to use (j + 1, m∗1 , q) as a result of decrypting L∗j+1,q , thus making the program decrypt L∗j+1,q instead. This
is without changing the functionality, since (j + 1, m∗1 , q) is what L∗j+1,q decrypts to.
In program RetrieveTags we unpuncture decryption key DK2 at pj+1,q = (j + 1, m∗1 , q) and remove an
instruction to output (m∗1 , q) on input L∗j+1,q . This is without changing the functionality, since (m∗1 , q) is
what the program outputs when decrypting L∗j+1,q .
Lemma 29. advHybC,1,q,2,−1,1 ,HybC,1,q,2,−1,2 (λ) ≤ 2−Ω(νiO (λ)) , for q 6= m∗2 .
Proof. We puncture ACE keys EK2 , DK2 at the point p−1,q = (−1, m∗1 , q) and hardwire L∗−1,q =
ACE.EncEK2 (−1, m∗1 , q) to eliminate the need to encrypt or decrypt p−1,q in programs Transform, isLess,
and RetrieveTags, without changing their functionality.
More specifically, in program Transform we puncture EK2 at p−1,q = (−1, m∗1 , q) and, in order to pre-
serve the functionality, add an instruction to output L∗−1,q = ACE.EncEK2 (−1, m∗1 , q) when (i, m1 , m2 ) =
(0, m∗1 , q).
In program isLess we puncture decryption key DK2 at p−1,q = (−1, m∗1 , q) and instruct the program to output
0 fail0 , given L∗ ∗
−1,q . This is without changing the functionality, since [−1, m1 , q] is treated by the program as
an invalid input, since the value i should be between 0 and T .
In program RetrieveTags we puncture decryption key DK2 at p−1,q = (−1, m∗1 , q) and instruct the program
to output 0 fail0 , given L∗−1,q . This is without changing the functionality, since [−1, m∗1 , q] is treated by the
program as an invalid input, since the value i should be between 0 and T .
Lemma 30. advHybC,1,q,2,−1,2 ,HybC,1,q,2,−1,3 (λ) ≤ 2−Ω(νACE.Indist (λ)) , for q 6= m∗2 .
Proof. Indistinguishability immediately follows from indistinguishability of ACE ciphertexts for the
challenge plaintexts p−1,q = (−1, m∗1 , q) and p0,q = (0, m∗1 , q). Indeed, given EK2 {p−1,q , p0,q },
DK2 {p−1,q , p0,q }, and either L∗−1,q = ACE.EncEK2 (−1, m∗1 , q) or L∗0,q = ACE.EncEK2 (0, m∗1 , q), it is
easy to reconstruct the rest of the distribution. That is, we can sample remaining keys, obfuscate all pro-
gram (note that indeed at most one of two ciphertexts L∗−1,q , L∗0,q is used in programs of HybC,1,q,2,−1,2
and HybC,1,q,2,−1,3 ), and compute `∗1 = ACE.EncEK1 (1, m∗1 ) and L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ) (using the
challenge encryption key EK2 {p−1,q , p0,q } which is not punctured at (0, m∗1 , m∗2 ) since q 6= m∗2 ).
Lemma 31. advHybC,1,q,2,−1,3 ,HybC,1,q,3,1 (λ) ≤ 2−Ω(νiO (λ)) , for q 6= m∗2 .
171
Proof. We unpuncture ACE keys EK2 , DK2 at the point p0,q = (0, m∗1 , q) and remove hardwired L∗0,q =
ACE.EncEK2 (0, m∗1 , q) in programs Transform, isLess, and RetrieveTags, without changing their functional-
ity.
More specifically, in program Transform we unpuncture EK2 at p0,q = (0, m∗1 , q) and remove an instruction
to output L∗0,q = ACE.EncEK2 (0, m∗1 , q) when (i, m1 , m2 ) = (0, m∗1 , q). This is without changing the
functionality, since now the program will run an encryption ACE.EncEK2 (0, m∗1 , q) when (i, m1 , m2 ) =
(0, m∗1 , q), instead of directly outputting hardwired L∗0,q .
In program isLess we unpuncture decryption key DK2 at p0,q = (0, m∗1 , q) and remove an instruction to
output 0 fail0 given L∗0,q ; to preserve the functionality, we instruct the program to output 0 fail0 when (i0 , m01 , m02 )
or (i00 , m001 , m002 ) is equal to (0, m∗1 , q).
In program RetrieveTags we unpuncture decryption key DK2 at p0,q = (0, m∗1 , q) and remove an instruction
to output 0 fail0 given L∗0,q ; to preserve the functionality, we instruct the program to output 0 fail0 when
(i, m1 , m2 ) = (0, m∗1 , q).
challenge set {p−1,q } = {(−1, m∗1 , q)} to puncture encryption key EK2 and challenge sets {p−1,q }, ∅ to
puncture decryption key DK2 . Indeed, given EK2 {p−1,q } and key which is either DK2 {p−1,q } or DK2 , it is
easy to reconstruct the rest of the distribution. That is, we can sample remaining keys, obfuscate all programs,
and compute `∗1 = ACE.EncEK1 (1, m∗1 ) and L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ) (using the challenge encryption
key EK2 {p−1,q } which is not punctured at (0, m∗1 , m∗2 ) since q 6= m∗2 ).
Lemma 33. advHybC,1,q,3,2 ,HybC,1,q,3,3 (λ) ≤ 2−Ω(νiO (λ)) , for q 6= m∗2 .
Proof. We unpuncture ACE key EK2 at the point p−1,q = (−1, m∗1 , q) in program Transform. This is without
changing the functionality, since this program never needs to encrypt p−1,q : indeed, when (m1 , m2 ) =
(m∗1 , q), the program only encrypts (i, m1 , m2 ), where 0 ≤ i ≤ T .
Proof. In programs GenZero and Increment we puncture encryption key EK1 at p0 = (0, m∗1 ). This is
without changing the functionality, since neither program needs to encrypt this point.
Lemma 35. advHybC,1,q,4,1 ,HybC,1,q,4,2 (λ) ≤ 2−Ω(νACE.ConstrDec (λ)) .
compute `∗1 = ACE.EncEK1 (1, m∗1 ) (using the challenge encryption key EK1 {p0 } which is not punctured at
(1, m∗1 )) and L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ).
172
Proof. In program Transform we puncture encryption key EK2 at p0,q = (0, m∗1 , q). This is without changing
the functionality: indeed, in order to encrypt p0,q , the program should get ([0, m∗1 ], q) as input, but on this
input Transform instead outputs 0 fail0 , since decryption key DK1 is punctured at p0 = (0, m∗1 ).
challenge set {p0,q } = {(0, m∗1 , q)} to puncture encryption key EK2 and challenge sets {p0,q }, ∅ to puncture
decryption key DK2 . Indeed, given EK2 {p0,q } and key which is either DK2 {p0,q } or DK2 , it is easy to
EK2 {p0,q } which is not punctured at (0, m∗1 , m∗2 ) since q 6= m∗2 ).
Proof. In programs isLess and RetrieveTags we remove an instruction to output 0 fail0 , given [0, m∗1 , q]. This
is without changing the functionality, since in both programs DK2 is punctured at p0,q = (0, m∗1 , q), thus
making the programs output 0 fail0 during decryption; thus the instructions which we are removing are never
reached anyway, and we can safely remove them.
challenge set {p0,q } = {(0, m∗1 , q)} to puncture encryption key EK2 and challenge sets {p0,q }, ∅ to puncture
decryption key DK2 . Indeed, given EK2 {p0,q } and key which is either DK2 {p0,q } or DK2 , it is easy to
EK2 {p0,q } which is not punctured at (0, m∗1 , m∗2 ) since q 6= m∗2 ).
Proof. In program Transform we unpuncture encryption key EK2 at p0,q = (0, m∗1 , q). This is without
changing the functionality: indeed, in order to encrypt p0,q , the program should get ([0, m∗1 ], q) as input, but
on this input Transform instead outputs 0 fail0 , since decryption key DK1 is punctured at p0 = (0, m∗1 ).
Lemma 41. advHybC,1,q,4,7 ,HybC,1,q,4,8 (λ) ≤ 2−Ω(νACE.ConstrDec (λ)) .
173
Proof. In programs GenZero and Increment we unpuncture encryption key EK1 at p0 = (0, m∗1 ). This is
Lemma 43. advHybC,2,1,1 ,HybC,2,1,2 (λ) ≤ 2−Ω(νiO (λ)) .
Proof. In program Transform we puncture encryption key EK2 at pT,m∗2 = (T, m∗1 , m∗2 ). This is without
changing the functionality, since Transform never encrypts this point: indeed, when (m1 , m2 ) = (m∗1 , m∗2 )
the largest value it encrypts is (T − 1, m1 , m2 ).
Lemma 44. advHybC,2,1,2 ,HybC,2,1,3 (λ) ≤ 2−Ω(νACE.ConstrDec (λ)) .
challenge set pT,m∗2 = {(T, m∗1 , m∗2 )} to puncture encryption key EK2 and challenge sets pT,m∗2 , ∅ to

puncture decryption key DK2 . Indeed, given EK2 {pT,m∗2 } and key which is either DK2 {pT,m∗2 } or DK2 , it is
key EK2 {pT,m∗2 } which is not punctured at (0, m∗1 , m∗2 )).
Lemma 45. advHybC,2,2,j,1 ,HybC,2,2,j,2 (λ) ≤ 2−Ω(νiO (λ)) , for 1 ≤ j ≤ T − 1.
Proof. We puncture ACE keys EK2 , DK2 at the point pj,m∗2 = (j, m∗1 , m∗2 ) and hardwire L∗j,m∗ =
2
ACE.EncEK2 (j, m∗1 , m∗2 ) to eliminate the need to encrypt or decrypt pj,m∗2 in programs Transform, isLess,
and RetrieveTags, without changing their functionality.
More specifically, in program Transform we puncture EK2 at pj,m∗2 = (j, m∗1 , m∗2 ) and, in order to preserve
the functionality, add an instruction to output L∗j,m∗ = ACE.EncEK2 (j, m∗1 , m∗2 ) when (i, m1 , m2 ) = (j +
2
1, m∗1 , m∗2 ).
In program isLess we puncture decryption key DK2 at pj,m∗2 = (j, m∗1 , m∗2 ) and, in order to preserve the
functionality, instruct the program not to decrypt L∗j,m∗ , but to use (j + 1, m∗1 , m∗2 ) as the result of decryption
2
instead. Note that this is different from what L∗j,m∗ would normally decrypt to, which is (j, m∗1 , m∗2 ). However,
2
we argue that this doesn’t change the functionality of the program. Indeed:
• The set of inputs on which isLess outputs 0 fail0 isn’t changed; in particular, since 0 ≤ j ≤ T − 1, both
(j, m∗1 , m∗2 ) and (j + 1, m∗1 , m∗2 ) are within 0 to T limits and thus are both valid.
• The result of the comparison on inputs [i0 , m1 , m2 ] and [i00 , m1 , m2 ], where (m1 , m2 ) 6= (m∗1 , m∗2 ),
remains the same, for all i0 , i00 ;
• The result of the comparison on inputs [i0 , m∗1 , m∗2 ] and [i00 , m∗1 , m∗2 ], where i0 , i00 6= j and i0 , i00 6= j +1,
remains the same;
• The output of the program on inputs ([i0 , m∗1 , m∗2 ], [i00 , m∗1 , m∗2 ]), where i0 = j + 1 or i00 = j + 1, is
0 fail0 for both the original and modified programs, since DK is punctured at p ∗ ∗
2 j+1,m∗2 = (j + 1, m1 , m2 )
0
and thus decryption returns fail ; 0
• The result of the comparison on inputs ([i0 , m∗1 , m∗2 ], [j, m∗1 , m∗2 ] = L∗j,m∗ ), remains the same, since
2
for both programs the output is:
– true for 0 ≤ i0 < j;
174
– false for i0 = j (indeed, in the original program in this case i0 = i00 = j, and in the modified
program i0 = i00 = j + 1, since [i0 , m∗1 , m∗2 ] = L∗j,m∗ when i0 = j and the program uses j + 1 as
2
the decryption result);
– 0 fail0 for i0 = j + 1, since DK2 is punctured at pj+1,m∗2 = (j + 1, m∗1 , m∗2 ) and thus decryption
returns 0 fail0 ;
– false for j + 2 ≤ i0 ≤ T .
• Similarly, the result of the comparison on inputs ([j, m∗1 , m∗2 ] = L∗j,m∗ , [i0 , m∗1 , m∗2 ]) remains the same
2
for the original program and modified program (with the difference that the result is false for 0 ≤ i0 < j
and true for j + 2 ≤ i0 ≤ T ).
In program RetrieveTags we puncture decryption key DK2 at pj,m∗2 = (j, m∗1 , m∗2 ) and, in order to preserve
the functionality, instruct the program to output (m∗1 , m∗2 ) on input L∗j,m∗ .
2
Lemma 46. advHybC,2,2,j,2 ,HybC,2,2,j,3 (λ) ≤ 2−Ω(νACE.Indist (λ)) , for 1 ≤ j ≤ T − 1.
lenge plaintexts pj,m∗2 = (j, m∗1 , m∗2 ) and pj+1,m∗2 = (j + 1, m∗1 , m∗2 ). Indeed, given EK2 {pj,m∗2 , pj+1,m∗2 },
DK2 {pj,m∗2 , pj+1,m∗2 }, and either L∗j,m∗ = ACE.EncEK2 (j, m∗1 , m∗2 ) or L∗j+1,m∗ = ACE.EncEK2 (j +
2 2
1, m∗1 , m∗2 ), it is easy to reconstruct the rest of the distribution. That is, we can sample remaining keys,
obfuscate all programs (note that creating the programs in each of the hybrids HybC,2,2,j,2 , HybC,2,2,j,3
requires to know exactly one of the two ciphertexts L∗j,m∗ , L∗j+1,m∗ ), and compute `∗1 = ACE.EncEK1 (1, m∗1 )
2 2
and L∗0 = ACE.EncEK2 (0, m∗1 , m∗2 ) (using the challenge encryption key EK2 {pj,m∗2 , pj+1,m∗2 } which is not
punctured at (0, m∗1 , m∗2 ) since j ≥ 1).
Lemma 47. advHybC,2,2,j,3 ,HybC,2,2,j,4 (λ) ≤ 2−Ω(νiO (λ)) , for 1 ≤ j ≤ T − 1.
Proof. We unpuncture ACE keys EK2 , DK2 at the point pj+1,m∗2 = (j + 1, m∗1 , m∗2 ) and remove hardwired
L∗j+1,m∗ = ACE.EncEK2 (j +1, m∗1 , m∗2 ) in programs Transform, isLess, and RetrieveTags, without changing
2
their functionality.
More specifically, in program Transform we unpuncture EK2 at pj+1,m∗2 = (j + 1, m∗1 , m∗2 ) and remove an
instruction to output L∗j+1,m∗ = ACE.EncEK2 (j + 1, m∗1 , m∗2 ) when (i, m1 , m2 ) = (j + 1, m∗1 , m∗2 ). This is
2
without changing the functionality, since now the program will run an encryption ACE.EncEK2 (j +1, m∗1 , m∗2 )
when (i, m1 , m2 ) = (j + 1, m∗1 , m∗2 ), instead of directly outputting hardwired L∗j+1,m∗ .
2
In program isLess we unpuncture decryption key DK2 at p = (j+1, m∗1 , m∗2 ) and remove an instruction
j+1,m∗2
to use (j + 1, m1 , m2 ) as a result of decrypting Lj+1,m∗ , thus making the program decrypt L∗j+1,m∗ instead.
∗ ∗ ∗
2 2
This is without changing the functionality, since (j + 1, m∗1 , m∗2 ) is what L∗j+1,m∗ decrypts to.
2
In program RetrieveTags we unpuncture decryption key DK2 at pj+1,m∗2 = (j + 1, m∗1 , m∗2 ) and remove an
instruction to output (m∗1 , m∗2 ) on input L∗j+1,m∗ . This is without changing the functionality, since (m∗1 , m∗2 )
2
is what the program outputs when decrypting L∗j+1,m∗ .
2
175
challenge set p1,m2 = {(1, m∗1 , m∗2 )} to puncture encryption key EK2 and challenge sets p1,m∗2 , ∅ to

∗
puncture decryption key DK2 . Indeed, given EK2 {p1,m∗2 } and key which is either DK2 {p1,m∗2 } or DK2 , it is
key EK2 {p1,m∗2 } which is not punctured at (0, m∗1 , m∗2 )).
Proof. In program Transform we do the following changes. First, we change the condition for when to encrypt
i−1 from i ≤ 1 to i ≤ 0. This is without changing the functionality, since the case (i, m1 , m2 ) = (1, m∗1 , m∗2 )
corresponds to the input ([1, m∗1 ], m∗2 ), in which case the program outputs 0 fail0 at the very beginning, thus
the line with the condition is not reached on this input anyway. For the same reason we can unpuncture EK2
at p1,m∗2 = (1, m∗1 , m∗2 ).
Next, in programs GenZero and Increment we puncture encryption key EK1 at p0 = (0, m∗1 ). This is without
changing the functionality, since neither program needs to encrypt this point.
Proof. In program Transform we make the program output ACE.EncEK2 (i, m1 , m2 ) instead of
ACE.EncEK2 (i − 1, m1 , m2 ) for the case (i, m1 , m2 ) = (0, m∗1 , m∗2 ); this is without changing the funcitonal-
ity, since encryption is never reached in the case. Indeed, on input ([0, m∗1 ], m∗2 ) Transform outputs 0 fail0
during decryption, since DK1 is punctured at p0 = (0, m∗1 ).
Proof. In programs GenZero and Increment we unpuncture encryption key EK1 at p0 = (0, m∗1 ). This is
176
8 Proof of bideniability of our encryption protocol
8.1 List of hybrids
In this section we present a list of hybrids with brief explanation of why indistinguishability holds. Formal
security reductions can be found in section 8.2.
We note that we repeat some hybrids in order to get 4 clean steps (e.g. hybrids HybB,3,3 − HybB,3,5 at the
very end of the proof of lemma 55 are immediately undone at the very beginning of the proof of lemma 56).
Lemma 54. [Indistinguishability of explanations of the sender] Assuming (t(λ), ε(λ)) security of relaxed
ACE, iO and sparse extracting PRFs, the distiributions in HybA , HybB are (t(λ), O(ε(λ)))-close.
Lemma 55. [Indistinguishability of explanations of the receiver] Assuming (t(λ), ε(λ)) security of ACE,
relaxed ACE, iO, prg and sparse extracting PRFs, the distiributions in HybB , HybC are (t(λ), O(ε(λ)) +
2−τ (λ) )-close.
Lemma 56. [Semantic security] Assuming (t(λ), ε(λ)) security of ACE, relaxed ACE, iO, and sparse
extracting PRFs, the distiributions in HybC , HybD are (t(λ), O(ε(λ)) + O(2−τ (λ) ))-close.
Lemma 57. [Indistinguishability of levels] Assuming (t(λ), ε(λ)) security of relaxed ACE, iO, and sparse
extracting PRFs, and assuming (t(λ), ε1 (λ, T, τ ))-secure level system, the distiributions in HybD , HybE are
(t(λ), O(ε(λ)) + ε1 (λ, T, τ ))-close.
8.1.1 Proof of lemma 54 (Indistinguishability of explanation of the sender)

• HybA,1 . We give the adversary (PP, m∗0 , m∗1 , s∗ , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where PP =
λ ∗ ∗
Setup(1 ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup ; s , r are cho-
sen at random, µ1 ∗ = SG(s∗ , m∗0 ), µ2 ∗ = P2(r∗ , µ1 ∗ ), µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
Programs are presented on fig. 94.
Note that HybA,1 = HybA , conditioned on the fact that s∗ is outside of the image of ACE.
Setup(1 ; P1A,1 , P2, P3A,1 , Dec, SFakeA,1 , RFake; rSetup ) for randomly chosen rSetup ; s , r∗
λ ∗
are chosen at random, µ1 ∗ = SG(s∗ , m∗0 ), µ2 ∗ = P2(r∗ , µ1 ∗ ), µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).

That is, we modify programs of the sender by puncturing encryption key of sender-fake ACE EKS {S`∗0 }
at the set S`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}, decryption key of sender-fake ACE DKS {s∗ , s0 } at s∗ and s0 (where
s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 )), and the key kS of extracting PRF SG of the sender at the
points (s∗ , m∗0 ) and (s0 , m∗0 ). In addition, we hardwire certain outputs inside programs of the sender to
make sure that functionality of the programs doesn’t change. Indistinguishability holds by iO.
λ ∗ ∗
Setup(1 ; P1A,1 , P2, P3A,1 , Dec, SFakeA,1 , RFake; rSetup ) for randomly chosen rSetup ; s , r are cho-
sen at random, µ1 ∗ is chosen at random, µ2 ∗ = P2(r∗ , µ1 ∗ ), µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
That is, we choose µ1 ∗ at random instead of computing it as µ1 ∗ = SGkS (s∗ , m∗0 ). Indistinguishability
holds by pseudorandomness of the PRF SG at the punctured point (s∗ , m∗0 ).
177
• HybA,4 . We give the adversary (PP, m∗0 , m∗1 , s0 , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where PP =
λ ∗ ∗
Setup(1 ; P1A,1 , P2, P3A,1 , Dec, SFakeA,1 , RFake; rSetup ) for randomly chosen rSetup ; s , r are cho-
sen at random, µ1 ∗ is chosen at random, µ2 ∗ = P2(r∗ , µ1 ∗ ), µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ),
s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ). Programs are presented on fig. 95.
That is, we switch the roles of s∗ and s0 everywhere in the distribution: namely, we give s0 (instead of
s∗ ) to the adversary as randomness of the sender, and we change s∗ to s0 and s0 to s∗ everywhere in
the programs. Note that this doesn’t change the code of the programs since programs use s∗ and s0 in
the same way. Indistinguishability holds by the symmetry of sender-fake ACE, which says that
(s∗ , s0 , EKS {S`∗0 }, DKS {s∗ , s0 }) is indistinguishable from (s0 , s∗ , EKS {S`∗0 }, DKS {s∗ , s0 }), where
p = (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), s∗ is randomly chosen, s0 = ACE.EncEKS (p). Note that DKS {s∗ , s0 } is
first punctured at one of the points s∗ , s0 which is lexicographically smaller, and then at the other.
Setup(1 ; P1A,1 , P2, P3A,1 , Dec, SFakeA,1 , RFake; rSetup ) for randomly chosen rSetup ; s∗ , r∗
λ
are chosen at random, µ1 ∗ = SG(s∗ , m∗0 ), µ2 ∗ = P2(r∗ , µ1 ∗ ), µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ),

That is, we generate µ1 ∗ as µ1 ∗ = SGkS (s∗ , m∗0 ) instead of choosing it at random. Indistinguishability
holds by pseudorandomness of the PRF SG at the punctured point (s∗ , m∗0 ).
λ ∗ ∗
Setup(1 ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup ; s , r are cho-
sen at random, µ1 ∗ = SG(s∗ , m∗0 ), µ2 ∗ = P2(r∗ , µ1 ∗ ), µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ),
That is, we revert all changes we made to programs and thus use original programs of our deniable
encryption scheme in this hybrid. Indistinguishability holds by iO, since we remove puncturing without
changing the functionality of the programs.
Note that HybA,6 = HybB , conditioned on the fact that s∗ is outside of the image of ACE.
178
Program P1(s, m)
Inputs: sender randomness s, message m.
1. Trapdoor step:
2. Main step:
Inputs: sender randomness s, message m, the first and the second messages µ1 , µ2 in the protocol.
2. Trapdoor step:
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
Inputs: sender randomness s, real message m, fake message m̂, protocol transcript µ1 , µ2 , µ3 .
2. Trapdoor step:
(b) If m, µ1 = m0 , µ1 0 then
3. Main step:
179
Programs P1A,1 , P3A,1 , SFakeA,1 .
Program P1A,1 (s, m)
Hardwired values: punctured decryption key DKS {s∗ , s0 } of sender-fake ACE, punctured key kS {(s∗ , m∗0 ), (s0 , m∗0 )}
of an extracting PRF SG, variables s∗ , s0 , m∗0 , µ1 ∗ .
1. Trapdoor step:
(a) If (s, m) = (s∗ , m∗0 ) or (s, m) = (s0 , m∗0 ) then return µ1 ∗ ;
(b) If s = s∗ or s = s0 then goto main step;
(c) out ← ACE.DecDKS {s∗ ,s0 } (s); if out = 0 fail0 goto main step, else parse out as (m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(d) If m = m0 then return µ1 0 ;
2. Main step:
(a) Return µ1 ← SGkS {(s∗ ,m∗0 ),(s0 ,m∗0 )} (s, m).
Program P3A,1 (s, m, µ1 , µ2 )
Hardwired values: obfuscated code of algorithms P1A,1 , GenZero, Transform, RetrieveTag; punctured decryption
key DKS {s∗ , s0 } of sender-fake ACE, encryption key EK of main ACE, variables s∗ , s0 , m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 .
1. Validity check: if P1A,1 (s, m) 6= µ1 then abort;
2. Trapdoor step:
(a) If (s, m, µ1 , µ2 ) = (s∗ , m∗0 , µ1 ∗ , µ2 ∗ ) or (s, m, µ1 , µ2 ) = (s0 , m∗0 , µ1 ∗ , µ2 ∗ ) then return µ3 ∗ ;
(b) If (s, m, µ1 ) = (s∗ , m∗0 , µ1 ∗ ) or (s, m, µ1 ) = (s0 , m∗0 , µ1 ∗ ) then return µ3 ←
∗ ∗ ∗
EncEK (m0 , µ1 , µ2 , Transform(`0 , µ2 ));
(c) If s = s∗ or s = s0 then goto main step;
(d) out ← ACE.DecDKS {s∗ ,s0 } (s); if out = 0 fail0 goto main step, else parse out as (m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(e) If m, µ1 , µ2 = m0 , µ1 0 , µ2 0 then return µ3 0 ;
(f) If m, µ1 = m0 , µ1 0 then:
3. Main step:
Program SFakeA,1 (s, m, m̂, µ1 , µ2 , µ3 )
Hardwired values: obfuscated code of algorithms P1A,1 , GenZero, Increment; punctured encryption key EKS {S`∗0 }
(where S`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}) and punctured decryption key DKS {s∗ , s0 }, variables s∗ , s0 , m∗0 , µ1 ∗ , `∗0 .
1. Validity check: if P1A,1 (s, m) 6= µ1 then abort;
2. Trapdoor step:
(a) If (s, m, µ1 ) = (s∗ , m∗0 , µ1 ∗ ) or (s, m, µ1 ) = (s0 , m∗0 , µ1 ∗ ) then return
∗
EncEKS {p} (m̂, µ1 , µ2 , µ3 , Increment(`0 ));
(b) If s = s∗ or s = s0 then goto main step;
(c) out ← ACE.DecDKS {s∗ ,s0 } (s); if out = 0 fail0 goto main step, else parse out as (m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(d) If m, µ1 = m0 , µ1 0 then
ii. Return ACE.EncEKS {S`∗ } (m̂, µ1 , µ2 , µ3 , `+1 ).
0
3. Main step:
(b) Return ACE.EncEKS {S`∗ } (m̂, µ1 , µ2 , µ3 , `1 ).
0
Figure 95: Programs P1A,1 , P3A,1 , SFakeA,1 , used in the proof of lemma 54 (indistinguishability of expla-
nations of the sender).
180
8.1.2 Proof of lemma 55 (Indistinguishability of explanation of the receiver)
First in a sequence of hybrids we “eliminate” complementary ciphertext µ3 ∗ = ACE.EncEK (1 ⊕
m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), i.e. make programs Dec and SFake reject it:
• HybB,1,1 . We give the adversary (PP, m∗0 , m∗1 , s0 , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where PP =
Setup(1 ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup ; s∗ , r∗ are cho-
λ
sen at random, µ1 ∗ = SG(s∗ , m∗0 ), µ2 ∗ = RG(r∗ , µ1 ∗ ), µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ),

s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ). Programs can be found in fig. 96 (programs of the sender)
and fig. 100 (programs of the receiver).
Note that this distribution is exactly the distribution from HybB , conditioned on the fact that s∗ , r∗ are
outside of images of their ACE.
Setup(1 ; P1B,1 , P2, P3B,1 , Dec, SFakeB,1 , RFake; rSetup ) for randomly chosen rSetup ; s∗ , r∗
λ
are chosen at random, µ1 ∗ = SG(s∗ , m∗0 ), µ2 ∗ = RG(r∗ , µ1 ∗ ), µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ),

That is, in program SFake we puncture encryption key EKS of the sender-fake ACE at the set P`∗0 =
{(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ). Indistinguishability holds by iO, since this modification
doesn’t change the functionality of SFake due to the fact that SFake never encrypts plaintexts with
level `∗0 .
Setup(1 ; P1B,2 , P2, P3B,2 , Dec, SFakeB,2 , RFake; rSetup ) for randomly chosen rSetup ; s , r∗
λ ∗

That is, in programs P1, P3, SFake we puncture decryption key DKS of the sender-fake ACE at the
same set P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ). Indistinguishability holds by security of
constrained decryption of ACE, since the corresponding encryption key EKS is already punctured at
the same set.
λ ∗
Setup(1 ; P1B,2 , P2, P3B,2 , Dec, SFakeB,2 , RFake; rSetup ) for randomly chosen rSetup ; r is chosen
at random, µ1 ∗ is chosen at random, µ2 ∗ = RG(r∗ , µ1 ∗ ), µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ),
holds by the strong extracting property of the sender PRF SG (note that s∗ was not used anywhere else
in the distribution).
Setup(1 ; P1B,3 , P2, P3B,3 , Dec, SFakeB,3 , RFake; rSetup ) for randomly chosen rSetup ; r∗ is chosen
λ

181
That is, in program P3 we puncture encryption key EK of the main ACE at the point p = (1 ⊕
m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ). Indistinguishability holds by iO, since P3 never needs to encrypt this point. Roughly,
this is because of the following: since µ1 ∗ is random and outside of the image of a PRF SG, P3 never
encrypts p in the main step. In order to encrypt it in trapdoor step, P3 needs to take as input some fake
s encoding level `∗0 . However, due to the fact that DKS is punctured at the set P`∗0 which contains all
but one strings with `∗0 , the only valid fake s with `∗0 is s0 . However, running P3 on s0 cannot result in
encrypting p in the trapdoor step since p contains the wrong plaintext 1 ⊕ m∗0 (instead of m∗0 ).
λ ∗
Setup(1 ; P1B,3 , P2B,1 , P3B,3 , DecB,1 , SFakeB,3 , RFakeB,1 ; rSetup ) for randomly chosen rSetup ; r is
chosen at random, µ1 ∗ is chosen at random, µ2 ∗ = RG(r∗ , µ1 ∗ ), µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ),
That is, in programs Dec, RFake we puncture decryption key DK of the main ACE at the same point
p = (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ). Indistinguishability holds by security of constrained decryption of ACE,
since the corresponding encryption key EK is already punctured at this point.
Now µ3 ∗ = ACE.EncEK (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ) is rejected by Dec and RFake. In the following hybrids,
similarly to previous lemma, we switch the roles of r∗ and r0 , using the fact that programs treat them similarly,
once µ3 ∗ is eliminated36 .
λ ∗
That is, we modify programs of the receiver (P2, Dec, RFake) by puncturing encryption key of receiver-
fake ACE EKR {Sρ̂∗ } at Sρ̂∗ = {(∗, ∗, ∗, ∗, ∗, ρ̂∗ )} for randomly chosen ρ̂∗ . Next, we puncture
decryption key of receiver-fake ACE DKR {r∗ , r0 } at r∗ and r0 (where r0 = ACE.EncEKR (p), p =
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , ρ̂∗ )), and the key kR of extracting PRF RG of the receiver at the points (r∗ , µ1 ∗ )
and (r0 , µ1 ∗ ). In addition, we hardwire certain outputs inside programs of the receiver to make sure
that functionality of the programs doesn’t change. Indistinguishability holds by iO.
λ
Setup(1 ; P1B,3 , P2B,2 , P3B,3 , DecB,2 , SFakeB,3 , RFakeB,2 ; rSetup ) for randomly chosen
rSetup ; r∗ is chosen at random, µ1 ∗ is chosen at random, µ2 ∗ is chosen at random,
µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ). Programs
can be found in fig. 99 (programs of the sender) and fig. 102 (programs of the receiver).
That is, we choose µ2 ∗ at random instead of computing it as µ2 ∗ = RGkS (r∗ , µ1 ∗ ). Indistinguishability
holds by pseudorandomness of the PRF SG at the punctured point (r∗ , µ1 ∗ ).
The problem with µ3 ∗ is that unmodified Dec on input (r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ) outputs 1 ⊕ m∗0 (via main step), and on input
36
(r , µ1 ∗ , µ2 ∗ , µ3 ∗ ) it outputs 0 fail0 (via trapdoor step, since levels in r0 and µ3 ∗ are both 0 and “isLess = true” check fails. Because
0
of this difference, in HybB,2,1 we wouldn’t be able to modify program Dec such that the code treats r∗ and r0 in the same way.
However, after HybB,1,6 µ3 ∗ is not a valid ciphertext anymore and thus in HybB,2,1 we can instruct Dec to output 0 fail0 on both r∗
and r0 .
182
• HybB,2,3 . We give the adversary (PP, m∗0 , m∗1 , s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where PP =
λ
Setup(1 ; P1B,3 , P2B,2 , P3B,3 , DecB,2 , SFakeB,3 , RFakeB,2 ; rSetup ) for randomly cho-
sen rSetup ; r∗ is chosen at random, µ1 ∗ is chosen at random, µ2 ∗ is chosen at ran-
dom, µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ),
r0 = ACE.EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , ρ̂∗ ) for randomly chosen ρ̂∗ . Programs can be found in fig.
99 (programs of the sender) and fig. 102 (programs of the receiver).
That is, we switch the roles of r∗ and r0 everywhere in the distribution: namely, we give r0 (instead
of r∗ ) to the adversary as randomness of the receiver, and we change r∗ to r0 and r0 to r∗ everywhere
in the programs. Note that this doesn’t change the code of the programs since programs use r∗
and r0 in the same way. Indistinguishability holds by the symmetry of receiver-fake ACE, which
says that (r∗ , r0 , EKR {Sρ̂∗ }, DKR {r∗ , r0 }) is indistinguishable from (r0 , r∗ , EKR {Sρ̂∗ }, DKR {r0 , r∗ }),
where Sρ̂∗ = {(∗, ∗, ∗, ∗, ∗, ρ̂∗ )}, p = (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , ρ̂∗ ), r∗ is randomly chosen, r0 =
ACE.EncEKR (p).
Setup(1 ; P1B,3 , P2B,2 , P3B,3 , DecB,2 , SFakeB,3 , RFakeB,2 ; rSetup ) for randomly chosen rSetup ; r∗ is
λ

s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), r0 = ACE.EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , ρ̂∗ ) for randomly
chosen ρ̂∗ . Programs can be found in fig. 99 (programs of the sender) and fig. 102 (programs of the
receiver).
That is, we compute µ2 ∗ as µ2 ∗ = RGkR (r∗ , µ1 ∗ ) instead of choosing it at random. Indistinguishability
holds by pseudorandomness of the PRF RG at the punctured point (r∗ , µ1 ∗ ).
λ
Setup(1 ; P1B,3 , P2B,1 , P3B,3 , DecB,1 , SFakeB,3 , RFakeB,1 ; rSetup ) for randomly chosen rSetup ; r is ∗

receiver).
That is, we revert all changes we made to programs in HybB,2,1 and thus use original programs
P2, Dec, RFake, except that DK remains punctured at the point p = (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ). Indis-
tinguishability holds by iO, since we remove puncturing without changing the functionality of the
programs.
λ
sen rSetup ; s∗ , r∗ are chosen at random, µ1 ∗ = SGkS (s∗ , m∗0 ), µ2 ∗ = RG(r∗ , µ1 ∗ ),
µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), r0 =
ACE.EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ )) for randomly chosen ρ∗ . Programs can be found
in fig. 99 (programs of the sender) and fig. 101 (programs of the receiver).
That is, we replace randomly chosen ρ̂∗ with prg(ρ∗ ) for randomly chosen ρ∗ , when generating r0 .
Indistinguishability holds by security of a prg.
Finally, in the following hybrids we revert all changes we made in hybrids HybB,1,1 - HybB,1,6 , thus restoring
all programs (and making µ3 ∗ a valid ciphertext):
183
Setup(1 ; P1B,3 , P2, P3B,3 , Dec, SFakeB,3 , RFake; rSetup ) for randomly chosen rSetup ; r∗
λ
is chosen at random, chosen at random, µ1 ∗ is chosen at random, µ2 ∗ = RG(r∗ , µ1 ∗ ),

That is, in programs Dec, RFake we unpuncture decryption key DK of the main ACE at the point
p = (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ). Indistinguishability holds by security of constrained decryption of ACE,
since the corresponding encryption key EK is punctured at this point.
λ
Setup(1 ; P1B,2 , P2, P3B,2 , Dec, SFakeB,2 , RFake; rSetup ) for randomly chosen rSetup ; r is chosen∗

s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), r0 = ACE.EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ )) for
randomly chosen ρ∗ . Programs can be found in fig. 98 (programs of the sender) and fig. 100 (programs
of the receiver).
That is, in program P3 we unpuncture encryption key EK of the main ACE at the point p = (1 ⊕
m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ). Indistinguishability holds by iO, because of the same reason as in HybB,1,5 .
λ ∗

of the receiver).
That is, we choose µ1 ∗ as µ1 ∗ = SGkS (s∗ , m∗0 ) instead of computing it at random. Indistinguishability
holds by the strong extracting property of the sender PRF SG (note that s∗ is not used anywhere else in
the distribution).
λ ∗

of the receiver).
That is, in programs P1, P3, SFake we unpuncture decryption key DKS of the sender-fake ACE at the
the same set.
λ
Setup(1 ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup ; s , r are cho- ∗ ∗

184
of the receiver).
That is, in program SFake we unpuncture encryption key EKS of the sender-fake ACE at the set P`∗0 =
level `∗0 .
Note that HybB,3,5 is the same as HybC , conditioned on the fact that s∗ , r∗ are outside of image of
ACE.
185
Program P1(s, m)
1. Trapdoor step:
2. Main step:
2. Trapdoor step:
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
2. Trapdoor step:
(b) If m, µ1 = m0 , µ1 0 then
3. Main step:
186
Programs P1B,1 , P3B,1 , SFakeB,1 .
Program P1B,1 (s, m)
1. Trapdoor step:
2. Main step:
Program P3B,1 (s, m, µ1 , µ2 )
Hardwired values: obfuscated code of algorithms P1B,1 , GenZero, Transform, RetrieveTag; decryption
key DKS of sender-fake ACE, encryption key EK of main ACE.
1. Validity check: if P1B,1 (s, m) 6= µ1 then abort;
2. Trapdoor step:
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
Program SFakeB,1 (s, m, m̂, µ1 , µ2 , µ3 )
Hardwired values: obfuscated code of algorithms P1B,1 , GenZero, Increment; punctured encryp-
tion key EKS {P`∗0 } and decryption key DKS of sender-fake ACE, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
2. Trapdoor step:
(b) If m, µ1 = m0 , µ1 0 then
ii. Return ACE.EncEKS {P`∗ } (m̂, µ1 , µ2 , µ3 , `+1 ).
0
3. Main step:
(b) Return ACE.EncEKS {P`∗ } (m̂, µ1 , µ2 , µ3 , `1 ).
0
Figure 97: Programs P1B,1 , P3B,1 , SFakeB,1 , used in the proof of lemma 55 (indistinguishability of expla-
nations of the receiver).
187
Hardwired values: punctured decryption key DKS {P`∗0 } of sender-fake ACE, where P`∗0 =
{(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), key kS of an extracting PRF SG.
1. Trapdoor step:
(a) out ← ACE.DecDKS {P`∗ } (s); if out = 0 fail0 goto main step, else parse out as
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
2. Main step:
Hardwired values: obfuscated code of algorithms P1B,2 , GenZero, Transform, RetrieveTag; punctured
decryption key DKS {P`∗0 } of sender-fake ACE, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ),
encryption key EK of main ACE.
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
tion and decryption keys EKS {P`∗0 }, DKS {P`∗0 } of sender-fake ACE, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m, µ1 = m0 , µ1 0 then
0
3. Main step:
0
188
1. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
2. Main step:
punctured encryption key EK{p} of main ACE, where p = (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(c) If m, µ1 = m0 , µ1 0 then:
iii. Return µ3 ← ACE.EncEK{p} (m, µ1 , µ2 , L);
3. Main step:
(b) Return µ3 ← ACE.EncEK{p} (m, µ1 , µ2 , L0 ).
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m, µ1 = m0 , µ1 0 then
0
3. Main step:
0
189
Program P2(r, µ1 )
1. Trapdoor step:
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
2. Main step:
2. Trapdoor step:
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
(d) If µ1 , µ2 = µ1 0 , µ2 0 then
ii. Else abort.
3. Main step:
(c) Else abort.
Inputs: fake message m̂, protocol transcript µ1 , µ2 , µ3 , random coins ρ.
190
Programs P2B,1 , DecB,1 , RFakeB,1 .
Program P2B,1 (r, µ1 )
1. Trapdoor step:
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
2. Main step:
Program DecB,1 (r, µ1 , µ2 , µ3 )
fake ACE, punctured decryption key DK{p} of the main ACE, where p = (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
2. Trapdoor step:
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
(c) out ← ACE.DecDK{p} (µ3 ); if out00 = 0 fail0 then abort, else parse out00 as (m00 , µ1 00 , µ2 00 , L00 );
(d) If µ1 , µ2 = µ1 0 , µ2 0 then
ii. Else abort.
3. Main step:
(a) out ← ACE.DecDK{p} (µ3 ); if out = 0 fail0 then abort, else parse out as (m00 , µ1 00 , µ2 00 , L00 );
(c) Else abort.
Program RFakeB,1 (m̂, µ1 , µ2 , µ3 ; ρ)
Hardwired values: encryption key EKR of receiver-fake ACE, punctured decryption key DK{p} of the main
ACE, where p = (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
1. out ← ACE.DecDK{p} (µ3 ); if out = 0 fail0 then abort, else parse out as (m00 , µ1 00 , µ2 00 , L00 );
Figure 101: Programs P2B,1 , DecB,1 , RFakeB,1 , used in the proof of lemma 55 (indistinguishability of
explanations of the receiver).
191
Hardwired values: punctured decryption key DKR {r∗ , r0 } of receiver-fake ACE, punctured key
kR {(r∗ , µ1 ∗ ), (r0 , µ1 ∗ )} of an extracting PRF RG, variables r∗ , r0 , µ1 ∗ , µ2 ∗ .
1. Trapdoor step:
(a) If (r, µ1 ) = (r∗ , µ1 ∗ ) or (r, µ1 ) = (r0 , µ1 ∗ ) then return µ2 ∗ ;
(b) If r = r∗ or r = r0 then goto main step;
(c) out ← ACE.DecDKR {r∗ ,r0 } (r); if out = 0 fail0 then goto main step, else parse out as
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
(d) If µ1 = µ1 0 then return µ2 0 ;
2. Main step:
(a) Return µ2 ← RGkR {(r∗ ,µ1 ∗ ),(r0 ,µ1 ∗ )} (r, µ1 ).
Hardwired values: obfuscated code of algorithms P2B,2 , isLess, RetrieveTags; punctured decryption
key DKR {r∗ , r0 } of receiver-fake ACE, punctured decryption key DK{p} of the main ACE, where p =
(1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), variables r∗ , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , m∗0 .
1. Validity check: if P2B,2 (r, µ1 ) 6= µ2 then abort;
2. Trapdoor step:
(a) If (r, µ1 , µ2 , µ3 ) = (r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ) or (r, µ1 , µ2 , µ3 ) = (r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ) then return m∗0 ;
(b) If (r, µ1 , µ2 ) = (r∗ , µ1 ∗ , µ2 ∗ ) or (r, µ1 , µ2 ) = (r0 , µ1 ∗ , µ2 ∗ ) then then goto main step;
(c) If r = r∗ or r = r0 then goto main step;
(d) out ← ACE.DecDKR {r∗ ,r0 } (r); if out0 = 0 fail0 then goto main step; else parse out0 as
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
(e) if µ1 , µ2 , µ3 = µ1 0 , µ2 0 , µ3 0 then return m0 ;
(f) out ← ACE.DecDK{p} (µ3 ); if out00 = 0 fail0 then abort, else parse out00 as (m00 , µ1 00 , µ2 00 , L00 );
(g) If µ1 , µ2 = µ1 0 , µ2 0 then
ii. Else abort.
3. Main step:
(c) Else abort.
Hardwired values: punctured encryption key EKR {Sρ̂∗ } of receiver-fake ACE, where Sρ̂∗ =
{(∗, ∗, ∗, ∗, ∗, ρ̂∗ )} for randomly chosen ρ̂∗ , punctured decryption key DK{p} of the main ACE, where
p = (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
2. Return r0 ← ACE.EncEKR {p} (m̂, µ1 , µ2 , µ3 , L00 , prg(ρ)).
192
8.1.3 Proof of lemma 56 (Semantic security)
• HybC,1,1 . We give the adversary (PP, m∗0 , m∗1 , s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where PP =
λ

randomly chosen ρ∗ . Programs can be found in fig. 103 (programs of the sender) and fig. 107
(programs of the receiver).
Note that this distribution is exactly the distribution from HybC , conditioned on the fact that s∗ , r∗ are
outside of image of ACE.
Setup(1λ ; P1C,1 , P2, P3C,1 , Dec, SFakeC,1 , RFake; rSetup ) for randomly chosen rSetup ; s∗ , r∗
level `∗0 .
Setup(1 ; P1C,2 , P2, P3C,2 , Dec, SFakeC,2 , RFake; rSetup ) for randomly chosen rSetup ; s , r∗
λ ∗

the same set.
λ
Setup(1 ; P1C,2 , P2, P3C,2 , Dec, SFakeC,2 , RFake; rSetup ) for randomly chosen rSetup ; r is chosen∗

Setup(1 ; P1C,2 , P2, P3C,2 , Dec, SFakeC,2 , RFake; rSetup ) for randomly chosen rSetup ; µ1 ∗
λ
is chosen at random, µ2 ∗ is chosen at random, µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ),
193
s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), r0 = ACE.EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ ))
for randomly chosen ρ∗ . Programs can be found in fig. 105 (programs of the sender) and fig. 107
That is, we choose µ2 ∗ at random instead of computing it as µ2 ∗ = RGkR (r∗ , µ1 ∗ ). Indistinguishability
holds by the strong extracting property of the receiver PRF RG (note that r∗ was not used anywhere
else in the distribution).
λ

That is, in program P3 we puncture encryption key EK of the main ACE at the points p0 =
(m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ). Indistinguishability holds by iO, since P3 never needs to
encrypt these points. Roughly, this is because of the following: since µ1 ∗ is random and outside of
the image of a PRF SG, P3 never encrypts p0 , p1 in the main step. In order to encrypt it in trapdoor
step, P3 needs to take as input some fake s encoding level `∗0 . However, due to the fact that DKS is
punctured at the set P`∗0 which contains all but one strings with `∗0 , the only valid fake s with `∗0 is s0 .
However, running P3 on s0 cannot result in encrypting p0 or p1 in the trapdoor step: in order to hit the
trapdoor step with s0 , the input to P3 should be (s0 , m∗0 , µ1 ∗ , µ2 ∗ ); however, in this case the program
immediately outputs µ3 0 without running an encryption algorithm.
λ
Setup(1 ; P1C,3 , P2C,1 , P3C,3 , DecC,1 , SFakeC,3 , RFakeC,1 ; rSetup ) for randomly chosen rSetup ;
µ1 ∗ is chosen at random, µ2 ∗ is chosen at random, µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ),
That is, in programs Dec, RFake we puncture decryption key DK of the main ACE at the point
p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ). Indistinguishability holds by security of constrained decryption of ACE,
since the corresponding encryption key EK is already punctured at this point (and encryption of p1 is
not used anywhere in the distribution).
λ
That is, we modify programs Dec and RFake by additionally puncturing decryption key of main ACE
DK at the point p0 = (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ). In addition, we hardwire certain outputs inside program
RFake to make sure that its functionality doesn’t change. (Note that in program Dec we only puncture
keys, without hardwiring anything. However, this doesn’t change the functionality of Dec. This is
because Dec would output ⊥ when trying to decrypt an encryption of p0 anyway: roughly, this is
194
because the main step cannot be reached because µ2 ∗ doesn’t have a preimage, and trapdoor step would
output ⊥ because there doesn’t exist fake randomness with level smaller than 0.) Indistinguishability
holds by iO.
λ
That is, we generate µ3 ∗ as an encryption of p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ) instead of p0 =
(m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ). Indistinguishability holds by security of the main ACE, since encryption and
decryption keys EK, DK are punctured at both p0 , p1 .
λ
That is, we modify programs Dec and RFake by unpuncturing decryption key of main ACE DK at the
point p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ) (note that DK remains punctured at p0 = (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 )). We also
remove additional instructions introduced in HybC,2,3 . Indistinguishability holds by iO, since we don’t
change functionality of the programs.
λ

p0 = (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ). Indistinguishability holds by security of constrained decryption of ACE,
since the corresponding encryption key EK is punctured at this point (and encryption of p0 is not used
anywhere in the distribution).
λ

That is, in program P3 we unpuncture encryption key EK of the main ACE at the points p0 =
(m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ). Indistinguishability holds by iO, since this doesn’t
change functionality of P3 for the same reason as in HybC,2,1 .
195
λ
Setup(1 ; P1C,2 , P2, P3C,2 , Dec, SFakeC,2 , RFake; rSetup ) for randomly chosen rSetup ; r is chosen∗

holds by the strong extracting property of the receiver PRF RG (note that r∗ is not used anywhere else
λ
Setup(1 ; P1C,2 , P2, P3C,2 , Dec, SFakeC,2 , RFake; rSetup ) for randomly chosen rSetup ; s is ∗
chosen at random, r∗ is chosen at random, µ1 ∗ = SGkS (s∗ , m∗1 ), µ2 ∗ = RG(r∗ , µ1 ∗ ),

That is, we compute µ1 ∗ as µ1 ∗ = SGkS (s∗ , m∗1 ) instead of choosing it at random. Indistinguishability
the distribution).
Setup(1 ; P1C,1 , P2, P3C,1 , Dec, SFakeC,1 , RFake; rSetup ) for randomly chosen rSetup ; s∗ is
λ
chosen at random, r∗ is chosen at random, µ1 ∗ = SGkS (s∗ , m∗1 ), µ2 ∗ = RG(r∗ , µ1 ∗ ),

That is, in programs P1, P3, SFake we unpuncture decryption key DKS of the sender-fake ACE at
the set P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ). Indistinguishability holds by security of
constrained decryption of ACE, since the corresponding encryption key EKS is punctured at the same
set.
λ
Setup(1 ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup ; s is cho- ∗
sen at random, r∗ is chosen at random, µ1 ∗ = SGkS (s∗ , m∗1 ), µ2 ∗ = RG(r∗ , µ1 ∗ ),

That is, in program SFake we unpuncture encryption key EKS of the sender-fake ACE at the set P`∗0 =
level `∗0 .
Note that HybC,3,4 = HybD , conditioned on the fact that s∗ , r∗ are outisde of image of ACE.
196
Program P1(s, m)
1. Trapdoor step:
2. Main step:
2. Trapdoor step:
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
2. Trapdoor step:
(b) If m, µ1 = m0 , µ1 0 then
3. Main step:
197
Programs P1C,1 , P3C,1 , SFakeC,1 .
Program P1C,1 (s, m)
1. Trapdoor step:
2. Main step:
Program P3C,1 (s, m, µ1 , µ2 )
Hardwired values: obfuscated code of algorithms P1C,1 , GenZero, Transform, RetrieveTag; decryption
1. Validity check: if P1C,1 (s, m) 6= µ1 then abort;
2. Trapdoor step:
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
Program SFakeC,1 (s, m, m̂, µ1 , µ2 , µ3 )
Hardwired values: obfuscated code of algorithms P1C,1 , GenZero, Increment; punctured encryp-
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
2. Trapdoor step:
(b) If m, µ1 = m0 , µ1 0 then
0
3. Main step:
0
Figure 104: Programs P1C,1 , P3C,1 , SFakeC,1 , used in the proof of lemma 56 (semantic security).
198
1. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
2. Main step:
Hardwired values: obfuscated code of algorithms P1C,2 , GenZero, Transform, RetrieveTag; punctured
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m, µ1 = m0 , µ1 0 then
0
3. Main step:
0
199
1. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
2. Main step:
Hardwired values: obfuscated code of algorithms P1C,3 , GenZero, Transform, RetrieveTag; punctured
decryption key DKS {P`∗0 } of sender-fake ACE, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), punc-
tured encryption key EK{p0 , p1 } of main ACE, where p0 = (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ).
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(c) If m, µ1 = m0 , µ1 0 then:
iii. Return µ3 ← ACE.EncEK{p0 ,p1 } (m, µ1 , µ2 , L);
3. Main step:
(b) Return µ3 ← ACE.EncEK{p0 ,p1 } (m, µ1 , µ2 , L0 ).
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m, µ1 = m0 , µ1 0 then
0
3. Main step:
0
200
Program P2(r, µ1 )
1. Trapdoor step:
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
2. Main step:
2. Trapdoor step:
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
(d) If µ1 , µ2 = µ1 0 , µ2 0 then
ii. Else abort.
3. Main step:
(c) Else abort.
201
Programs P2C,1 , DecC,1 , RFakeC,1 .
Program P2C,1 (r, µ1 )
1. Trapdoor step:
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
2. Main step:
Program DecC,1 (r, µ1 , µ2 , µ3 )
Hardwired values: obfuscated code of algorithms P2C,1 , isLess, RetrieveTags; decryption key DKR of
receiver-fake ACE, punctured decryption key DK{p1 } of the main ACE, where p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ).
1. Validity check: if P2C,1 (r, µ1 ) 6= µ2 then abort;
2. Trapdoor step:
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
(c) out ← ACE.DecDK{p1 } (µ3 ); if out00 = 0 fail0 then abort, else parse out00 as (m00 , µ1 00 , µ2 00 , L00 );
(d) If µ1 , µ2 = µ1 0 , µ2 0 then
ii. Else abort.
3. Main step:
(a) out ← ACE.DecDK{p1 } (µ3 ); if out = 0 fail0 then abort, else parse out as (m00 , µ1 00 , µ2 00 , L00 );
(c) Else abort.
Program RFakeC,1 (m̂, µ1 , µ2 , µ3 ; ρ)
Hardwired values: encryption key EKR of receiver-fake ACE, punctured decryption key DK{p1 } of the
main ACE, where p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ).
1. out ← ACE.DecDK{p1 } (µ3 ); if out = 0 fail0 then abort, else parse out as (m00 , µ1 00 , µ2 00 , L00 );
Figure 108: Programs P2C,1 , DecC,1 , RFakeC,1 , used in the proof of lemma 56 (semantic security).
202
1. Trapdoor step:
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
2. Main step:
receiver-fake ACE, punctured decryption key DK{p0 , p1 } of the main ACE, where p0 = (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ),
p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ).
2. Trapdoor step:
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
(c) out ← ACE.DecDK{p0 ,p1 } (µ3 ); if out00 = 0 fail0 then abort, else parse out00 as (m00 , µ1 00 , µ2 00 , L00 );
(d) If µ1 , µ2 = µ1 0 , µ2 0 then
ii. Else abort.
3. Main step:
(a) out ← ACE.DecDK{p0 ,p1 } (µ3 ); if out = 0 fail0 then abort, else parse out as (m00 , µ1 00 , µ2 00 , L00 );
(c) Else abort.
Hardwired values: encryption key EKR of receiver-fake ACE, punctured decryption key DK{p0 , p1 } of the
main ACE, where p0 = (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ), variables µ3 ∗ , L∗0 .
1. If µ3 = µ3 ∗ then set L00 = L∗0 ;
else out ← ACE.DecDK{p0 ,p1 } (µ3 ); if out = 0 fail0 then abort, else parse out as (m00 , µ1 00 , µ2 00 , L00 );
203
1. Trapdoor step:
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
2. Main step:
receiver-fake ACE, punctured decryption key DK{p0 } of the main ACE, where p0 = (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
2. Trapdoor step:
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
(c) out ← ACE.DecDK{p0 } (µ3 ); if out00 = 0 fail0 then abort, else parse out00 as (m00 , µ1 00 , µ2 00 , L00 );
(d) If µ1 , µ2 = µ1 0 , µ2 0 then
ii. Else abort.
3. Main step:
(a) out ← ACE.DecDK{p0 } (µ3 ); if out = 0 fail0 then abort, else parse out as (m00 , µ1 00 , µ2 00 , L00 );
(c) Else abort.
Hardwired values: encryption key EKR of receiver-fake ACE, punctured decryption key DK{p0 } of the
main ACE, where p0 = (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
1. out ← ACE.DecDK{p0 } (µ3 ); if out = 0 fail0 then abort, else parse out as (m00 , µ1 00 , µ2 00 , L00 );
204
8.1.4 Proof of lemma 57 (Indistinguishability of levels)
• HybD,1,1 . We give the adversary (PP, m∗0 , m∗1 , s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), where PP =
λ

randomly chosen ρ∗ . Programs of the sender can be found in fig. 111.
Note that this distribution is exactly the distribution from HybC , conditioned on the fact that s∗ , r∗ are
outside of image of ACE.
Setup(1 ; P1D,1 , P2, P3D,1 , Dec, SFakeD,1 , RFake; rSetup ) for randomly chosen rSetup ; s , r∗
λ ∗

level `∗0 .
Setup(1 ; P1D,2 , P2, P3D,2 , Dec, SFakeD,2 , RFake; rSetup ) for randomly chosen rSetup ; s , r∗
λ ∗

the same set.
λ
Setup(1 ; P1D,2 , P2, P3D,2 , Dec, SFakeD,2 , RFake; rSetup ) for randomly chosen rSetup ; r is chosen∗

λ

That is, in programs P3 and SFake we use punctured programs GenZero[µ1 ∗ ], Transform[`∗0 , µ2 ∗ ].
205
Indistinguishability holds by iO, since this doesn’t change functionality of P3 and SFake. Roughly,
this is because of the following:
Since µ1 ∗ is random and outside of the image of a PRF SG, programs P3 and SFake never call
GenZero(µ1 ∗ ) in the main step, and program P3 never calls Transform(`∗0 , µ2 ∗ ) in the main step.
In order to call Transform(`∗0 , µ2 ∗ ) in trapdoor step, P3 needs to take as input some fake s encoding
level `∗0 . However, due to the fact that DKS is punctured at the set P`∗0 which contains all but one
strings with `∗0 , the only valid fake s with `∗0 is s0 . However, running P3 on s0 cannot result in calling
Transform(`∗0 , µ2 ∗ ) in the trapdoor step: in order to hit the trapdoor step with s0 and run Transform with
µ2 = µ2 ∗ , the input to P3 should be (s0 , m∗0 , µ1 ∗ , µ2 ∗ ); however, in this case the program immediately
outputs µ3 0 without running Transform.
Setup(1 ; P1D,4 , P2, P3D,4 , Dec, SFakeD,4 , RFake; rSetup ) for randomly chosen rSetup ; r∗ is chosen
λ

That is, we switch the single-tag level used in generation of s0 from `∗0 = [0, µ1 ∗ ] to `∗1 = [1, µ1 ∗ ].
Indistinguishability holds by security of level system: recall that it guarantees that `∗0 is indistinguishable
from `∗1 , even given L∗0 = [0, µ1 ∗ , µ2 ∗ ] and punctured programs of the level system.
Note that now keys EKS , DKS of the sender-fake ACE become punctured at the set P`∗1 =
{(∗, ∗, ∗, ∗, `∗1 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ) instead of P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ),
and program Transform becomes punctured at the point (`∗1 , µ2 ∗ ) instead of (`∗0 , µ2 ∗ ).
λ

That is, in programs P3 and SFake we use original programs GenZero, Transform instead of punctured
programs GenZero[µ1 ∗ ], Transform[`∗1 , µ2 ∗ ]. Indistinguishability holds by iO, since this doesn’t change
functionality of P3 and SFake. Roughly, this is because of similar reasoning as in HybD , except for `∗1
instead of `∗0 :
Since µ1 ∗ is random and outside of the image of a PRF SG, programs P3 and SFake never call
GenZero(µ1 ∗ ) in the main step, and program P3 never calls Transform(`∗1 , µ2 ∗ ) in the main step.
In order to call Transform(`∗1 , µ2 ∗ ) in trapdoor step, P3 needs to take as input some fake s encoding
level `∗1 . However, due to the fact that DKS is punctured at the set P`∗1 which contains all but one
strings with `∗1 , the only valid fake s with `∗1 is s0 . However, running P3 on s0 cannot result in calling
Transform(`∗1 , µ2 ∗ ) in the trapdoor step: in order to hit the trapdoor step with s0 and run Transform with
µ2 = µ2 ∗ , the input to P3 should be (s0 , m∗0 , µ1 ∗ , µ2 ∗ ); however, in this case the program immediately
outputs µ3 0 without running Transform.
λ ∗
Setup(1 ; P1D,6 , P2, P3D,6 , Dec, SFakeD,6 , RFake; rSetup ) for randomly chosen rSetup ; r is chosen
206
That is, in program SFake we additionally puncture encryption key EKS of the sender-fake ACE at
the set P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} (recall that it is already punctured at the set P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )} \
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 )). Indistinguishability holds by security of iO, since this modification doesn’t
change the functionality of SFake due to the fact that SFake never encrypts plaintexts with level `∗0 .
λ

That is, in programs P1, P3, SFake we additionally puncture decryption key DKS of the sender-
fake ACE at the set P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} (recall that it is already punctured at the set P`∗1 =
{(∗, ∗, ∗, ∗, `∗1 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 )). Indistinguishability holds by security of constrained de-
cryption of ACE, since the corresponding encryption key EK is already punctured at P`∗0 ∪ P`∗1 .
λ

That is, in programs P1, P3, SFake we unpuncture decryption key DKS of the sender-fake ACE at
the set P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ) (but this key still remains punctured at the set
P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}). Indistinguishability holds by security of constrained decryption of ACE, since
the corresponding encryption key EK is already punctured at P`∗0 ∪ P`∗1 .
λ

That is, in program SFake we unpuncture encryption key EKS of the sender-fake ACE at the set
P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ) (but this key still remains punctured at the set
P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}). Indistinguishability holds by security of iO, since this doesn’t change the
functionality of SFake. Indeed, the program never needs to encrypt any plaintext containing `∗1 because
of the following. Since µ1 ∗ is random and outside of the image of a PRF SG, program SFake never
calls GenZero(µ1 ∗ ) in the main step and thus never needs to encrypt `∗1 = Increment(GenZero(µ1 ∗ )).
In order to encrypt a plaintext containing `∗1 in the trapdoor step, SFake needs to get as input fake s
which contains `∗0 . However, since DKS is punctured at P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}, there do not exist valid
fake s with `∗0 , thus the program never needs to encrypt plaintexts with `∗1 .
Setup(1 ; P1D,10 , P2, P3D,10 , Dec, SFakeD,10 , RFake; rSetup ) for randomly chosen rSetup ; r∗ is cho-
λ
sen at random, µ1 ∗ is chosen at random, µ2 ∗ = RG(r∗ , µ1 ∗ ), µ3 ∗ = ACE.EncEK (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ),
207
set P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}. Indistinguishability holds by security of constrained decryption of ACE,
since the corresponding encryption key EK is already punctured at P`∗0 .
λ
Setup(1 ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup ; r is chosen at ∗
random, µ1 ∗ is chosen at random, µ2 ∗ = RG(r∗ , µ1 ∗ ), µ3 ∗ = ACE.EncEK (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ),

P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}. Indistinguishability holds by security of iO, since this doesn’t change the
functionality of SFake since SFake never needs to encrypt plaintexts with `∗0 .
Setup(1 ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup ; s∗ is cho-
λ
sen at random, r∗ is chosen at random, µ1 ∗ = SGkS (s∗ , m∗1 ), µ2 ∗ = RG(r∗ , µ1 ∗ ),

ACE.EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ )) for randomly chosen ρ∗ . Programs of the sender
can be found in fig. 122.
That is, we compute µ1 ∗ as µ1 ∗ = SGkS (s∗ , m∗1 ) instead of choosing it at random. Indistinguishability
the distribution).
Note that HybD,3,7 = HybE .
208
Program P1(s, m)
1. Trapdoor step:
2. Main step:
2. Trapdoor step:
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
2. Trapdoor step:
(b) If m, µ1 = m0 , µ1 0 then
3. Main step:
209
Programs P1D,1 , P3D,1 , SFakeD,1 .
Program P1D,1 (s, m)
1. Trapdoor step:
2. Main step:
Program P3D,1 (s, m, µ1 , µ2 )
Hardwired values: obfuscated code of algorithms P1D,1 , GenZero, Transform, RetrieveTag; decryption
1. Validity check: if P1D,1 (s, m) 6= µ1 then abort;
2. Trapdoor step:
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
Program SFakeD,1 (s, m, m̂, µ1 , µ2 , µ3 )
Hardwired values: obfuscated code of algorithms P1D,1 , GenZero, Increment; punctured encryp-
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
2. Trapdoor step:
(b) If m, µ1 = m0 , µ1 0 then
0
3. Main step:
0
Figure 112: Programs P1D,1 , P3D,1 , SFakeD,1 , used in the proof of lemma 57 (security of levels).
210
1. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
2. Main step:
Hardwired values: obfuscated code of algorithms P1D,2 , GenZero, Transform, RetrieveTag; punctured
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m, µ1 = m0 , µ1 0 then
0
3. Main step:
0
211
1. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
2. Main step:
Hardwired values: obfuscated code of algorithms P1D,3 , punctured GenZero[µ1 ∗ ], punctured
Transform[(`∗0 , µ2 ∗ )], RetrieveTag; punctured decryption key DKS {P`∗0 } of sender-fake ACE, where
P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), encryption key EK of main ACE.
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(c) If m, µ1 = m0 , µ1 0 then:
ii. Set L ← Transform[(`∗0 , µ2 ∗ )](`0 , µ2 );
3. Main step:
(a) Set L0 ← Transform[(`∗0 , µ2 ∗ )](GenZero[µ1 ∗ ](µ1 ), µ2 );
Hardwired values: obfuscated code of algorithms P1D,3 , punctured GenZero[µ1 ∗ ], Increment; punctured
encryption and decryption keys EKS {P`∗0 }, DKS {P`∗0 } of sender-fake ACE, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m, µ1 = m0 , µ1 0 then
0
3. Main step:
(a) Set `1 ← Increment(GenZero[µ1 ∗ ](µ1 ));
0
212
1. Trapdoor step:
1
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
2. Main step:
Hardwired values: obfuscated code of algorithms P1D,4 , punctured GenZero[µ1 ∗ ], punctured
Transform[(`∗1 , µ2 ∗ )], RetrieveTag; punctured decryption key DKS {P`∗1 } of sender-fake ACE, where
P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ), encryption key EK of main ACE.
2. Trapdoor step:
1
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(c) If m, µ1 = m0 , µ1 0 then:
ii. Set L ← Transform[(`∗1 , µ2 ∗ )](`0 , µ2 );
3. Main step:
(a) Set L0 ← Transform[(`∗1 , µ2 ∗ )](GenZero[µ1 ∗ ](µ1 ), µ2 );
Hardwired values: obfuscated code of algorithms P1D,4 , punctured GenZero[µ1 ∗ ], Increment; punctured
encryption and decryption keys EKS {P`∗1 }, DKS {P`∗1 } of sender-fake ACE, where P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )} \
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ).
2. Trapdoor step:
1
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m, µ1 = m0 , µ1 0 then
1
3. Main step:
(a) Set `1 ← Increment(GenZero[µ1 ∗ ](µ1 ));
1
213
1. Trapdoor step:
1
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
2. Main step:
2. Trapdoor step:
1
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ).
2. Trapdoor step:
1
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m, µ1 = m0 , µ1 0 then
1
3. Main step:
1
214
1. Trapdoor step:
1
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
2. Main step:
2. Trapdoor step:
1
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
Hardwired values: obfuscated code of algorithms P1D,6 , GenZero, Increment; punctured encryption
and decryption keys EKS {P`∗1 ∪ P`∗0 }, DKS {P`∗1 } of sender-fake ACE, where P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )} \
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ), P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}.
2. Trapdoor step:
1
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m, µ1 = m0 , µ1 0 then
ii. Return ACE.EncEKS {P`∗ ∪P`∗ } (m̂, µ1 , µ2 , µ3 , `+1 ).
1 0
3. Main step:
(b) Return ACE.EncEKS {P`∗ ∪P`∗ } (m̂, µ1 , µ2 , µ3 , `1 ).
1 0
215
Hardwired values: punctured decryption key DKS {P`∗1 ∪ P`∗0 } of sender-fake ACE, where P`∗1 =
{(∗, ∗, ∗, ∗, `∗1 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ), P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}, key kS of an extracting PRF SG.
1. Trapdoor step:
(a) out ← ACE.DecDKS {P`∗ ∪P`∗ } (s); if out = 0 fail0 goto main step, else parse out as
1 0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
2. Main step:
decryption key DKS {P`∗1 ∪ P`∗0 } of sender-fake ACE, where P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )}\(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ),
P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}, encryption key EK of main ACE.
2. Trapdoor step:
1 0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
Hardwired values: obfuscated code of algorithms P1D,7 , GenZero, Increment; punctured encryption and
decryption keys EKS {P`∗1 ∪ P`∗0 }, DKS {P`∗1 ∪ P`∗0 } of sender-fake ACE, where P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )} \
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ), P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}.
2. Trapdoor step:
1 0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m, µ1 = m0 , µ1 0 then
1 0
3. Main step:
1 0
216
Hardwired values: punctured decryption key DKS {P`∗0 } of sender-fake ACE, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )},
key kS of an extracting PRF SG.
1. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
2. Main step:
decryption key DKS {P`∗0 } of sender-fake ACE, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}, encryption key EK of main
ACE.
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
Hardwired values: obfuscated code of algorithms P1D,8 , GenZero, Increment; punctured encryption
and decryption keys EKS {P`∗1 ∪ P`∗0 }, DKS {P`∗0 } of sender-fake ACE, where P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )} \
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ), P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}.
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m, µ1 = m0 , µ1 0 then
1 0
3. Main step:
1 0
217
1. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
2. Main step:
decryption key DKS {P`∗0 } of sender-fake ACE, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}, encryption key EK of main
ACE.
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
Hardwired values: obfuscated code of algorithms P1D,9 , GenZero, Increment; punctured encryption and
decryption keys EKS {P`∗0 }, DKS {P`∗0 } of sender-fake ACE, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}.
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m, µ1 = m0 , µ1 0 then
0
3. Main step:
0
218
1. Trapdoor step:
2. Main step:
Hardwired values: obfuscated code of algorithms P1D,10 , GenZero, Transform, RetrieveTag; decryption
2. Trapdoor step:
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
Hardwired values: obfuscated code of algorithms P1D,10 , GenZero, Increment; punctured encryption key
EKS {P`∗0 } and decryption key DKS of sender-fake ACE, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}.
2. Trapdoor step:
(b) If m, µ1 = m0 , µ1 0 then
0
3. Main step:
0
219
Program P1(s, m)
1. Trapdoor step:
2. Main step:
2. Trapdoor step:
(c) If m, µ1 = m0 , µ1 0 then:
3. Main step:
2. Trapdoor step:
(b) If m, µ1 = m0 , µ1 0 then
3. Main step:
220
8.2 Detailed proof of security
In this section we present formal security reductions for each hybrid described in section 8.1.
We denote by σ 0 the maximum size of programs of deniable encryption in the construction and the proof.
Since our construction uses multiple layers of obfuscation, σ 0 is some polynomial of λ. As we note in
appendix B, we could instead use only one layer of obfuscation, and the resulting code would have size
σ = O(λ3 ).
8.2.1 Reductions in the proof of lemma 54 (Indistinguishability of explanation of the sender)

Let t(λ) be any function in Ω(poly(λ)), and let ε(λ) be a negligible function in w(2−λ ). Assuming the
sender-fake relaxed ACE, sparse extracting puncturable PRF, and iO for program size σ 0 is (t(λ), ε(λ))-secure,
we show that no time-t(λ) adversary can distinguish between HybA and HybB with more than O(ε(λ))
advantage.
Note that conditioning on s∗ begin not in the image of ACE incurs only 2−λ loss and therefore we omit it.
Lemma 58. Statistical distance between distributions HybA , HybA,1 is at most 2−λ .
Proof. Since randomly chosen s∗ is a valid ciphertext of sender ACE with probability at most 2−λ , with
all but this probability both P1 and P3 will fail do decrypt s∗ under DKS and therefore will run main step,
outputting µ1 ∗ = SGkS (s∗ , m∗0 ) and µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), respectively.
Lemma 59. Assume s∗ is outside of the image of sender ACE. Then, if there exists an adversary which can
distinguish HybA,1 and HybA,2 in time t(λ) with advantage ε(λ), then there exists an adversary which can
break iO for programs of size σ 0 in time t(λ) + poly(λ) with distinguishing advantage 13 · ε(λ).
Proof. Below we analyze all three pairs of programs assuming that s∗ is outside the image of sender ACE,
and thus ACE.DecDKS (s∗ ) = 0 fail0 . We show that programs have the same functionality. We use the fact that
all underlying primitives satisfy correctness.
Program P1. We present case analysis to show that the behavior of programs P1 and P1A,1 on each input is
the same:
• Case s = s∗ :
– Case m = m∗0 : P1 outputs µ1 ∗ via main step since s∗ is outside of image of ACE. P1A,1 outputs
µ1 ∗ due to hardwired instruction.
– Case m 6= m∗0 : P1 executes main step and outputs SGkS (s∗ , m) since s∗ is outside of image of
ACE. P1A,1 executes main step and outputs SGkS (s∗ , m) due to hardwired instruction.
• Case s = s0 :
– Case m = m∗0 : P1 outputs µ1 ∗ via trapdoor step. P1A,1 outputs µ1 ∗ due to hardwired instruction.
– Case m 6= m∗0 : P1 skips the trapdoor step since s0 contains the wrong m∗0 6= m, and outputs
SGkS (s0 , m). P1A,1 executes main step and output SGkS (s0 , m) due to hardwired instruction.
221
• Case s 6= s0 , s∗ : P1 and P1A,1 execute the same code, since punctured keys preserve functionality on
all inputs which are not punctured (note that when s 6= s0 , s∗ keys are indeed never used at punctured
points).
Program P3. Next we compare programs P3 and P3A,1 . Note that validity check passes on the same set of
inputs in programs P3 and P3A,1 , since programs P1 and P1A,1 are functionally equivalent. We present the
analysis assuming inputs passed the validity check.
• Case s = s∗ :
– Case (m, µ1 ) = (m∗0 , µ1 ∗ ):
∗ Case µ2 = µ2 ∗ : P3 outputs µ3 ∗ via main step since s∗ is outside of image of ACE. P3A,1
outputs µ3 ∗ due to hardwired instruction.
∗ Case µ2 6= µ2 ∗ : P3 outputs EncEK (m∗0 , µ1 ∗ , µ2 , Transform(GenZero(µ1 ∗ ), µ2 ))
via main step since s∗ is outside of image of ACE. P3A,1 outputs
EncEK (m∗0 , µ1 ∗ , µ2 , Transform(`∗0 , µ2 )) due to hardwired instruction. Note that
GenZero(µ1 ∗ ) = `∗0 and thus both outputs are the same.
– Case (m, µ1 ) 6= (m∗0 , µ1 ∗ ): P3 executes main step and outputs
EncEK (m, µ1 , µ2 , Transform(GenZero(µ1 ), µ2 )) since s∗ is outside of image
of ACE. P3A,1 executes main step due to hardwired instruction and outputs
EncEK (m, µ1 , µ2 , Transform(GenZero(µ1 ), µ2 )).
• Case s = s0 :
– Case (m, µ1 ) = (m∗0 , µ1 ∗ ):
∗ Case µ2 = µ2 ∗ : P3 outputs µ1 ∗ via trapdoor step. P3A,1 outputs µ1 ∗ due to hardwired
instruction.
∗ Case µ2 6= µ2 ∗ : P3 gets level `∗0 from s0 and outputs EncEK (m∗0 , µ1 ∗ , µ2 , Transform(`∗0 , µ2 ))
via trapdoor step. P3A,1 outputs EncEK (m∗0 , µ1 ∗ , µ2 , Transform(`∗0 , µ2 )) due to hardwired
instruction.
– Case (m, µ1 ) 6= (m∗0 , µ1 ∗ ): P3 skips the trapdoor step since s0 contains the wrong
(m∗0 , µ1 ∗ ) 6= (m, µ1 ), and outputs EncEK (m, µ1 , µ2 , Transform(GenZero(µ1 ), µ2 )) via
main step. P3A,1 executes main step due to hardwired instruction and outputs
EncEK (m, µ1 , µ2 , Transform(GenZero(µ1 ), µ2 )).
• Case s 6= s0 , s∗ : P3 and P3A,1 execute the same code, since punctured keys preserve functionality on
all inputs which are not punctured. Note that in this case these keys are never used at punctured points.
Program SFake.Next we compare programs SFake and SFakeA,1 . Note that validity check passes on the
same set of inputs in programs SFake and SFakeA,1 , since programs P1 and P1A,1 are functionally equivalent.
We present the analysis assuming inputs passed the validity check.
• Case s = s∗ :
– Case (m, µ1 ) = (m∗0 , µ1 ∗ ) (for arbitrary (m̂, µ2 , µ3 )): SFake outputs
ACE.EncEKS (m̂, µ1 , µ2 , µ3 , Increment(GenZero(µ1 ))) via main step since s∗ is out-
∗ ∗
side of image of ACE. SFakeA,1 outputs ACE.EncEKS (m̂, µ1 ∗ , µ2 , µ3 , Increment(`∗0 )) due to
222
hardwired instruction. Note that GenZero(µ1 ∗ ) = `∗0 and thus both outputs are the same.
– Case (m, µ1 ) 6= (m∗0 , µ1 ∗ ) (for arbitrary (m̂, µ2 , µ3 )): SFake executes main step since s∗ is
outside of image of ACE and outputs ACE.EncEKS (m̂, µ1 , µ2 , µ3 , Increment(GenZero(µ1 ))).
SFakeA,1 skips the trapdoor step due to hardwired instruction and outputs the same value via
main step.
• Case s = s0 :
– Case (m, µ1 ) = (m∗0 , µ1 ∗ ) (for arbitrary (m̂, µ2 , µ3 )): SFake gets `∗0 from s0 , increments it and
outputs ACE.EncEKS (m̂, µ1 ∗ , µ2 , µ3 , Increment(`∗0 )). SFakeA,1 outputs the same value due to
hardwired instruction.
– Case (m, µ1 ) 6= (m∗0 , µ1 ∗ ) (for arbitrary (m̂, µ2 , µ3 )): SFake skips the
trapdoor step since s0 contains the wrong (m∗0 , µ1 ∗ ) 6= (m, µ1 ), and
outputs ACE.EncEKS (m̂, µ1 , µ2 , µ3 , Increment(GenZero(µ1 ))) via main step.
SFakeA,1 skips the trapdoor step due to hardwired instruction and outputs
EncEK (m, µ1 , µ2 , Transform(GenZero(µ1 ), µ2 )) via main step.
• Case s 6= s0 , s∗ : SFake and SFakeA,1 execute the same code, since punctured keys preserve func-
tionality on all inputs which are not punctured. Note that keys are never used at punctured points
(in particular, the program never needs to encrypt a plaintext containing `∗0 , and thus the key can be
punctured at S`∗0 = {∗, ∗, ∗, ∗, `∗0 }).
break security of a puncturable PRF SGkS in time t(λ) + poly(λ) with distinguishing advantage ε(λ).
Proof. We give a reduction from indistinguishability of hybrids HybA,2 and HybA,3 to security of a punc-
turable PRF SGkS at the punctured point (s∗ , m∗0 ).
The reduction first takes plaintexts m∗0 , m∗1 from the adversary. Next it chooses random s∗ and sends the
point (s∗ , m∗0 ) to the challenger of puncturable PRF game. The reduction gets back from the challenger the
punctured key kS {(s∗ , m∗0 )} and the value µ1 ∗ , which is either SGkS (s∗ , m∗0 ) or randomly chosen.
Next the reduction reconstructs the rest of the distribution as follows. It samples all keys used in programs
(except kS {(s∗ , m∗0 )}), namely keys EK, DK of the main ACE, keys EKS , DKS of the sender ACE, keys
EKR , DKR of the receiver ACE, key kR of the sparse extracting PRF RG of the receiver. It also runs setup of
the level system to create the code of GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags.
It chooses random r∗ and sets µ2 ∗ = RGkR (r∗ , µ1 ∗ ). It computes levels `∗0 = GenZero(µ1 ∗ ), L∗0 =
Transform(`∗0 , µ2 ∗ ). It sets µ3 ∗ = EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ) and s0 = EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
Next it computes punctured keys DKS {s∗ , s0 }, kS {(s∗ , m∗0 ), (s0 , m∗0 )} (by additionally puncturing challenge
kS {(s∗ , m∗0 )} at (s0 , m∗0 )), and EKS {S`∗0 }, S`∗0 = {∗, ∗, ∗, ∗, `∗0 }.
Then the reduction uses variables and code created above to construct and obfuscate programs P1, P3, SFake,
(fig. 95) and P2, Dec, RFake (fig. 19). It gives obfuscated programs to the adversary, together with
s∗ , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge µ1 ∗ was SGkS (s∗ , m∗0 ), then the resulting distribution is exactly the
distribution from HybA,2 . If µ1 ∗ was randomly chosen, then the resulting distribution is exactly the distribution
223
from HybA,3 .
Note that this reduction is using the fact that an adversary who holds the punctured key can additionally
puncture it at another point. We note that the construction of an extracting PRF [SW14] is based on GGM
PRF and satisfies this property.
break symmetry of a sender-fake relaxed ACE scheme in time t(λ) + poly(λ) with distinguishing advantage
ε(λ).
Proof. We give a reduction from indistinguishability of hybrids HybA,3 and HybA,4 to symmetry of sender
ACE.
The reduction first takes plaintexts m∗0 , m∗1 from the adversary. Next it samples all keys used in
programs (except EKS , DKS ), namely keys EK, DK of the main ACE, keys EKR , DKR of the re-
ceiver ACE, key kS of the sparse extracting PRF SG of the sender, key kR of the sparse ex-
tracting PRF RG of the receiver. It also runs setup of the level system to create the code of
GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags.
It chooses random r∗ and sets µ1 ∗ to be randomly chosen, µ2 ∗ = RGkR (r∗ , µ1 ∗ ). It computes levels
`∗0 = GenZero(µ1 ∗ ), L∗0 = Transform(`∗0 , µ2 ∗ ). It sets µ3 ∗ = EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
Next the reduction sends p = (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ) as the challenge point to the challenger of the symmetry
of ACE. The challenger chooses random s∗ , samples keys EKS , DKS of ACE and computes s0 = EncEKS (p),
and punctures EKS at S`∗0 = {∗, ∗, ∗, ∗, `∗0 } and DKS at s∗ , s0 (DKS is first punctured at one of the strings
s∗ , s0 which is lexicographically smaller, and then at the other). The reduction gets back from the challenger
(s1 , s2 , EKS {S`∗0 }, DKS {s∗ , s0 }), where s1 = s∗ , s2 = s0 or s1 = s0 , s2 = s∗ .
Next the reduction computes punctured key kS {(s1 , m∗0 ), (s2 , m∗0 )}. Then it uses variables and code created
above to construct and obfuscate programs P1, P3, SFake, (fig. 95) and P2, Dec, RFake (fig. 19). In particular,
in every place where s∗ , s0 appear, e.g. in code of programs, or as a punctured point, the reduction first uses
one of the strings s1 , s2 which is lexicographically smaller, and then the other (note that s∗ , s0 always appear
together in the distribution, except for the value given to the adversary as randomness of the sender).
Next the reduction gives obfuscated programs to the adversary, together with s1 , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ . If
challenge s1 , s2 are s∗ , s0 , then the resulting distribution is exactly the distribution from HybA,3 . If s1 , s2 are
s0 , s∗ , then the resulting distribution is exactly the distribution from HybA,4 .
break security of a puncturable PRF SGkS in time t(λ) + poly(λ) with distinguishing advantage ε(λ).
Proof. The proof is very similar to the proof of indistinguishability of hybrids HybA,2 , HybA,3 , except that
the reduction gives s0 instead of s∗ as randomness of the sender to the adversary.
We give a reduction from indistinguishability of hybrids HybA,4 and HybA,5 to security of a puncturable PRF
SGkS at the punctured point (s∗ , m∗0 ).
The reduction first takes plaintexts m∗0 , m∗1 from the adversary. Next it chooses random s∗ and sends the
224
point (s∗ , m∗0 ) to the challenger of puncturable PRF game. The reduction gets back from the challenger the
punctured key kS {(s∗ , m∗0 )} and the value µ1 ∗ , which is either SGkS (s∗ , m∗0 ) or randomly chosen.
(except kS {(s∗ , m∗0 )}), namely keys EK, DK of the main ACE, keys EKS , DKS of the sender ACE, keys
EKR , DKR of the receiver ACE, key kR of the sparse extracting PRF RG of the receiver. It also runs setup of
Next it computes punctured keys DKS {s∗ , s0 }, kS {(s∗ , m∗0 ), (s0 , m∗0 )} (by additionally puncturing challenge
kS {(s∗ , m∗0 )} at (s0 , m∗0 )), and EKS {S`∗0 }, S`∗0 = {∗, ∗, ∗, ∗, `∗0 }
s0 , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge µ1 ∗ was SGkS (s∗ , m∗0 ), then the resulting distribution is exactly the distri-
bution from HybA,5 . If µ1 ∗ was randomly chosen, then the resulting distribution is exactly the distribution
from HybA,4 .
puncture it at another point. We note that the construction of an extracting PRF [SW14] is based on GGM
PRF and satisfies this property.
(t(λ), ε(λ))-distinguish HybA,5 and HybA,6 , then there exists an adversary which can break iO for programs
of size σ 0 in time t(λ) + poly(λ) with distinguishing advantage 13 · ε(λ).
Proof. The proof is identical to the proof of lemma 59, except that we give s0 , and not s∗ , as randomness of
the sender to the adversary.
Finally, we note that the distributions in HybA,6 and HybB are 2−λ -close (the reasoning is similar to
distributions HybA , HybA,1 ).
8.2.2 Reductions in the proof of lemma 55 (Indistinguishability of explanation of the receiver)

Let t(λ) be any function in Ω(poly(λ)), and let ε(λ) be a negligible function in w(2−λ ). Assuming the prg,
the sender-fake relaxed ACE, receiver-fake relaxed ACE, main ACE, sparse extracting puncturable PRF, and
iO for program size σ 0 are (t(λ), ε(λ))-secure, we show that no time-t(λ) adversary can distinguish between
HybB and HybC with more than O(ε(λ)) + 2−τ (λ) advantage.
(Note that security loss 2−τ (λ) comes from conditioning on the fact that µ1 ∗ is outside of the image of the
PRF SG. Conditioning on s∗ , r∗ , ρ̂∗ incurs only 2−λ loss and therefore we omit it.).
Lemma 64. Statistical distance between distributions HybB , HybB,1,1 is at most 2 · 2−λ .
Proof. Since randomly chosen s∗ is a valid ciphertext of sender ACE with probability senderACE.sparsity(λ),
with all but this probability both P1 and P3 will fail do decrypt s∗ under DKS and therefore will run main
step, outputting µ1 ∗ = SGkS (s∗ , m∗0 ) and µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), respectively.
225
Similarly, randomly chosen r∗ is a valid ciphertext of receiver ACE with probability receiverACE.sparsity(λ),
and thus with all but this probability P2 will fail do decrypt r∗ under DKR and therefore will run main step,
outputting µ2 ∗ = RGkR (r∗ , µ1 ∗ ).
Lemma 65. Assume s∗ , r∗ are outside of the image of the sender-fake ACE and the receiver-fake ACE,
respectively. Then, if there exists an adversary which can (t(λ), ε(λ))-distinguish HybB,1,1 and HybB,1,2 ,
then there exists an adversary which can break iO for programs of size σ 0 in time t(λ) + poly(λ) with
distinguishing advantage ε(λ).
Proof. The only difference between programs SFake and SFakeB,1 is that SFakeB,1 uses a punctured key
EKS {P`∗0 }, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ). This is without changing functionality,
since SFake never needs to encrypt a plaintext with level `∗0 , since `∗0 = [0, µ1 ∗ ] and SFake encrypts levels
with value at least 1.
then there exists an adversary which can break security of constrained decryption of sender-fake relaxed
ACE in time t(λ) + poly(λ) with distinguishing advantage ε(λ).
Proof. We give a reduction from indistinguishability of hybrids HybB,1,2 and HybB,1,3 to security of con-
strained decryption of sender ACE.
The reduction first takes plaintexts m∗0 , m∗1 from the adversary. It samples all keys used in programs (except
EKS , DKS ), namely keys EK, DK of the main ACE, keys EKR , DKR of the receiver ACE, key kS of the sparse
extracting PRF SG of the sender, key kR of the sparse extracting PRF RG of the receiver. It also runs setup of
It chooses random s∗ , r∗ and sets µ1 ∗ = SGkS (s∗ , m∗0 ), µ2 ∗ = RGkR (r∗ , µ1 ∗ ). It computes levels `∗0 =
GenZero(µ1 ∗ ), L∗0 = Transform(`∗0 , µ2 ∗ ). It sets µ3 ∗ = EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
Next the reduction sends the set P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ) to puncture encryption key
and sets P`∗0 , ∅ to puncture decryption key to the challenger of constrained decryption game. The challenger
samples keys EKS , DKS and it sends back to the reduction EKS {P`∗0 } and key which is either DKS {P`∗0 } or
DKS {∅}.
Next the reduction computes s0 = EncEKS {P`∗ } (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ) (note that this point is not punctured).
0
(fig. 97, fig. 98) and P2, Dec, RFake (fig. 19). It gives obfuscated programs to the adversary, together
with s0 , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge key was DKS {∅}, then the resulting distribution is exactly the
distribution from HybB,1,2 . If key was DKS {P`∗0 }, then the resulting distribution is exactly the distribution
from HybB,1,3 .
then there exists an adversary which can break the strong computational extractor property of the PRF SG in
time t(λ) + poly(λ) with distinguishing advantage ε(λ).
226
Proof. We give a reduction from indistinguishability of hybrids HybB,1,3 and HybB,1,4 to strong computa-
tionally extracting PRF SGkS .
The reduction first takes plaintexts m∗0 , m∗1 from the adversary. It sends the point m∗0 to the challenger of
strong extractor game. The challenger samples the key kS for SG and either chooses µ1 ∗ at random or
computes it as µ1 ∗ = SGkS (s∗ , m∗0 ) for randomly chosen s∗ . The reduction gets back from the challenger
the key kS and the value µ1 ∗ .
(except kS ), namely keys EK, DK of the main ACE, keys EKS , DKS of the sender ACE, keys EKR , DKR
of the receiver ACE, key kR of the sparse extracting PRF RG of the receiver. It also runs setup of the level
system to create the code of GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags.
Next it computes punctured keys EKS {P`∗0 }, DKS {P`∗0 }, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
s0 , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge µ1 ∗ was SGkS (s∗ , m∗0 ), then the resulting distribution is exactly the distri-
bution from HybB,1,3 . If µ1 ∗ was randomly chosen, then the resulting distribution is exactly the distribution
from HybB,1,4 .
respectively. Further, assume that µ1 ∗ is outside the image of the PRF SG. Then, if there exists an adversary
which can (t(λ), ε(λ))-distinguish HybB,1,4 and HybB,1,5 , then there exists an adversary which can break
iO for programs of size σ 0 in time t(λ) + poly(λ) with distinguishing advantage ε(λ).
Proof. The only difference between programs P3B,2 and P3B,3 is that P3B,3 uses a punctured key EK{p},
where p = (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ). We argue that the program never needs to encrypt any plaintext of the
form (∗, µ1 ∗ , µ2 ∗ , L∗0 ), and therefore puncturing this point doesn’t change the functionality:
Note that, since µ1 ∗ is random, it is outside of the image of a PRF SG with overwhelming probability, and
thus validity check can pass only if P3 is run on some (s, m, µ1 ∗ , µ2 ∗ ), where s encodes m, µ1 ∗ (and other
values). However, note that P3B,2 on such input can only execute trapdoor step (and not the main step);
thus the key in the main step can be safely punctured. Further, in order for the program to run encryption
algorithm in the trapdoor step on any plaintext of the form (∗, µ1 ∗ , µ2 ∗ , L∗0 ), fake s should encode level `∗0 .
However, note that DKS is punctured at the set P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), and thus
P3B,2 rejects all fake s with `∗0 inside except s which encodes (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), that is, s0 . Finally,
note that running P3B,2 on (s0 , m, µ1 ∗ , µ2 ∗ ) will pass validity check only if m = m∗0 (again, since µ1 ∗ is
outside of the image of PRF SG). Thus (s0 , m∗0 , µ1 ∗ , µ2 ∗ ) is the only potentially problematic input. However,
running P3B,2 on (s0 , m∗0 , µ1 ∗ , µ2 ∗ ) will not trigger encryption algorithm, since the program directly outputs
the value µ3 ∗ encoded in s0 . Thus P3B,2 never encrypts any plaintext of the form (∗, µ1 ∗ , µ2 ∗ , L∗0 ) in the
trapdoor step.
227
security of constrained decryption of the main ACE in time t(λ) + poly(λ) with distinguishing advantage
ε(λ).
Proof. We give a reduction from indistinguishability of hybrids HybB,1,5 and HybB,1,6 to security of con-
strained decryption of main ACE.
EK, DK), namely keys EKS , DKS of sender ACE, keys EKR , DKR of the receiver ACE, key kS of the sparse
It chooses random r∗ and sets µ1 ∗ at random, µ2 ∗ = RGkR (r∗ , µ1 ∗ ). It computes levels `∗0 = GenZero(µ1 ∗ ),
L∗0 = Transform(`∗0 , µ2 ∗ ).
Next the reduction sends the set consisting of a single point p = (1⊕m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ) to puncture encryption
key and sets p, ∅ to puncture decryption key to the challenger of constrained decryption game. The challenger
samples keys EK, DK and it sends back to the reduction EK{p} and key which is either DK{p} or DK{∅}.
Next the reduction computes µ3 ∗ = EncEK{p} (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ) (note that this point isn’t punctured, thus
the reduction can indeed encrypt it).
It punctured keys EKS {P`∗0 }, DKS {P`∗0 }, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), and sets
s0 = EncEKS {P`∗ } (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
0
Then the reduction uses variables and code created above to construct and obfuscate programs P1, P3, SFake
(fig. 99) and P2, Dec, RFake (fig. 100, fig. 101). It gives obfuscated programs to the adversary, together with
s0 , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge key was DK{∅}, then the resulting distribution is exactly the distribution
from HybB,1,5 . If key was DKS {p}, then the resulting distribution is exactly the distribution from HybB,1,6 .
respectively. Further, assume that µ1 ∗ is outside the image of the PRF SG, and ρˆ∗ is outside of the image of
the prg. Then, if there exists an adversary which can (t(λ), ε(λ))-distinguish HybB,1,6 and HybB,2,1 , then
there exists an adversary which can break security of iO for σ 0 -sized programs in time t(λ) + poly(λ) with
distinguishing advantage 31 · ε(λ).
Proof. In this analysis we assume that r∗ is outside the image of receiver ACE, and thus ACE.DecDKR (r∗ ) =
0 fail0 .
Programs P2 and P2B,2 . We present case analysis to show that the behavior of programs P2 and P2B,2 on
each input is the same:
• Case r = r∗ :
– Case µ1 = µ1 ∗ : P2 outputs µ2 ∗ via main step since r∗ is outside of image of ACE. P2B,2 outputs
µ2 ∗ due to hardwired instruction.
– Case µ1 6= µ1 ∗ : P2 executes main step and outputs RGkR (r∗ , µ1 ) since r∗ is outside of image of
ACE. P2B,2 executes main step and outputs RGkR (r∗ , µ1 ) due to hardwired instruction.
228
• Case r = r0 :
– Case µ1 = µ1 ∗ : P2 outputs µ2 ∗ via trapdoor step. P2B,2 outputs µ2 ∗ due to hardwired instruction.
– Case µ1 6= µ1 ∗ : P2 skips the trapdoor step since r0 contains the wrong µ1 ∗ 6= µ1 , and outputs
RGkR (r0 , µ1 ). P2B,2 executes main step due to hardwired instruction and outputs RGkR (r0 , µ1 ).
• Case r 6= r0 , r∗ : P2 and P2B,2 execute the same code, since punctured keys preserve functionality on
all inputs which are not punctured. Note that keys are never used at punctured points.
Programs Dec and DecB,2 . Next we compare programs Dec and DecB,2 . Note that validity check passes on
the same set of inputs in programs Dec and DecB,2 , since programs P2 and P2B,1 are functionally equivalent.
We present the analysis assuming inputs passed the validity check.
• Case r = r∗ :
– Case (µ1 , µ2 ) = (µ1 ∗ , µ2 ∗ ):
∗ Case µ3 = µ3 ∗ : Dec outputs m∗0 via main step since r∗ is outside of image of ACE. DecB,1
outputs m∗0 due to hardwired instruction.
∗ Case µ3 6= µ3 ∗ : since r∗ is outside of image of ACE, Dec executes the main step. DecB,2
skips the trapdoor step due to hardwired instruction and performes exactly the same actions
in the main step.
– Case (µ1 , µ2 ) 6= (µ1 ∗ , µ2 ∗ ): Dec executes main step since r∗ is outside of image of ACE. DecB,2
skips the trapdoor step due to hardwired instruction and performes exactly the same actions in
the main step.
• Case r = r0 :
– Case (µ1 , µ2 ) = (µ1 ∗ , µ2 ∗ ):
∗ Case µ3 = µ3 ∗ : Dec outputs m∗0 via trapdoor step. DecB,2 outputs m∗0 due to hardwired
instruction.
∗ Case µ3 6= µ3 ∗ : Dec executes trapdoor step. That is, it tries to decrypt µ3 and either outputs
its plaintext or 0 fail0 . In order for Dec to outputs a plaintext (and not 0 fail0 ), µ1 , µ2 should be
the same in the input, in µ3 , in r0 , and in L00 , and moreover, isLess(L0 , L00 ) should be true.
Since r0 has level L0 = L∗0 , isLess is true for all L00 of the form [i, µ1 ∗ , µ2 ∗ ], where i > 0.
In other words, µ3 should be an encryption of (m, µ1 ∗ , µ2 ∗ , L00 ), where L00 = [i, µ1 ∗ , µ2 ∗ ],
i > 0, and m is arbitrary. We call it condition 1.
DecB,2 is instructed to skip the trapdoor step and execute the main step. That is, it decrypts
µ3 and either outputs its plaintext or 0 fail0 . In order for DecB,1 to outputs a plaintext (and not
0 fail0 ), µ , µ should be the same in the input, in µ , and in L00 (however, unlike Dec, there
1 2 3
is no “isLess(L0 , L00 ) = true” condition). In other words, µ3 should be an encryption of
(m, µ1 ∗ , µ2 ∗ , L00 ), where L00 = [i, µ1 ∗ , µ2 ∗ ], i ≥ 0, and m is arbitrary. We call it condition
2.
Thus, the only difference in these conditions for Dec and DecB,2 is that, given an encryption
of (m, µ1 ∗ , µ2 ∗ , [0, µ1 ∗ , µ2 ∗ ]) for any m (that is, µ3 ∗ or µ3 ∗ ), condition 1 instructs to output
0 fail0 and condition 2 instructs to output m. However, we claim that both programs Dec
and DecB,2 still behave the same on inputs µ3 ∗ or µ3 ∗ . Indeed, recall that if the input was
229
(r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), both programs would output m∗0 as analysed in the previous case. If the
input was (r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), both programs would output 0 fail0 , since decryption key DK of
the main ACE is punctured at the point p = (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , [0, µ1 ∗ , µ2 ∗ ]).
Thus, in this case both programs have the same functionality.
– Case (µ1 , µ2 ) 6= (µ1 ∗ , µ2 ∗ ): Dec skips the trapdoor step since r0 contains the wrong (µ1 ∗ , µ2 ∗ ) 6=
(µ1 , µ2 ), and executes the main step. DecB,2 skips the trapdoor step due to hardwired instruction
and executes the main step.
• Case r 6= r0 , r∗ : Dec and DecB,2 execute the same code, since punctured keys preserve functionality
on all inputs which are not punctured. Note that DecB,2 never uses key DKR at the punctured points,
thus puncturing it doesn’t change the functionality of the program. Note that the key DKp can be used
by Dec and DecB,2 to decrypt an encryption of p, however it is punctured at both programs and thus
functionality of both programs is the same in this case.
Programs RFake and RFakeB,2 . Next we compare programs RFake and RFakeB,2 . Note that the only
difference is that RFakeB,2 uses a punctured key EKR {Sρ̂∗ }, where Sρ̂∗ = {(∗, ∗, ∗, ∗, ∗, ρ̂∗ )} for randomly
chosen ρ̂∗ . By assumption of the lemma, ρ̂∗ is outside of the image of this prg, and thus RFakeB,2 never
needs to encrypt any of points ending with ρ̂∗ . Therefore puncturing the key doesn’t change the functionality
of the program.
there exists an adversary which can break security of of a puncturable PRF RGkR in time t(λ) + poly(λ)
with distinguishing advantage ε(λ).
the reduction is for PRF of the receiver, not the PRF of the sender.
We give a reduction to security of a puncturable PRF RGkR at the punctured point (r∗ , µ1 ∗ ).
The reduction first takes plaintexts m∗0 , m∗1 from the adversary. Next it chooses random r∗ , µ1 ∗ and sends the
point (r∗ , µ1 ∗ ) to the challenger of puncturable PRF game. The reduction gets back from the challenger the
punctured key kR {(r∗ , µ1 ∗ )} and the value µ2 ∗ , which is either RGkR (r∗ , µ1 ∗ ) or randomly chosen.
(except kR {(r∗ , µ1 ∗ )}), namely keys EK, DK of the main ACE, keys EKS , DKS of the sender ACE, keys
EKR , DKR of the receiver ACE, key kS of the sparse extracting PRF SG of the sender. It also runs setup of
It computes levels `∗0 = GenZero(µ1 ∗ ), L∗0 = Transform(`∗0 , µ2 ∗ ). It sets µ3 ∗ = EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ),
s0 = EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), r0 = EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , ρ̂∗ ) for randomly chosen ρ̂∗ .
Next it computes punctured keys DKR {r∗ , r0 }, kR {(r∗ , µ1 ∗ ), (r0 , µ1 ∗ )} (by additionally puncturing challenge
kR {(r∗ , µ1 ∗ )} at (r0 , µ1 ∗ )), and EKR {Sρ̂∗ }, Sρ̂∗ = {(∗, ∗, ∗, ∗, ∗, ρ̂∗ )} for randomly chosen ρ̂∗ . It also
punctures keys EKS {P`∗0 }, DKS {P`∗0 }, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), and EK{p},
DK{p} at p = (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
230
s0 , r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge µ2 ∗ was RGkR (r∗ , µ1 ∗ ), then the resulting distribution is exactly the
distribution from HybB,2,1 . If µ2 ∗ was randomly chosen, then the resulting distribution is exactly the
distribution from HybB,2,2 .
puncture it at another point. We note that the construction of an extracting puncturable PRF of [SW14] is
based on GGM PRF and satisfies this property.
there exists an adversary which can break the symmetry of a receiver-fake relaxed ACE in time t(λ) + poly(λ)
the reduction is to the ACE of the receiver, not ACE of the sender.
We give a reduction to symmetry of receiver ACE.
The reduction first takes plaintexts m∗0 , m∗1 from the adversary. Next it samples all keys used
in programs (except EKR , DKR ), namely keys EK, DK of the main ACE, keys EKS , DKS of the
sender ACE, key kS of the sparse extracting PRF SG of the sender, key kR of the sparse ex-
tracting PRF RG of the receiver. It also runs setup of the level system to create the code of
It chooses random µ1 ∗ , µ2 ∗ . It computes levels `∗0 = GenZero(µ1 ∗ ), L∗0 = Transform(`∗0 , µ2 ∗ ). It sets
µ3 ∗ = EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), s0 = EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
Next the reduction chooses ρ̂∗ at random and sends p = (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , ρ̂∗ ) as the challenge point
to the challenger of the symmetry of ACE. The challenger chooses random r∗ , samples keys EKR , DKR
of ACE and computes r0 = EncEKR (p), and punctures EKR at Sρ̂∗ = {(∗, ∗, ∗, ∗, ∗, ρ̂∗ )} and DKR at r∗ , r0
(DKR is first punctured at one of the strings r∗ , r0 which is lexicographically smaller, and then at the other).
The reduction gets back from the challenger (r1 , r2 , EKR {Sρ̂∗ }, DKR {r∗ , r0 }), where r1 = r∗ , r2 = r0 or
r1 = r0 , r2 = r∗ .
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), and EK{p}, DK{p} where p = (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
Next the reduction computes punctured key kR {(r1 , µ1 ∗ ), (r2 , µ1 ∗ )}. Then it uses variables and code created
above to construct and obfuscate programs P1, P3, SFake, (fig. 99) and P2, Dec, RFake (fig. 102). In
particular, in every place where r∗ , r0 appear, e.g. in code of programs, or as a punctured point, the reduction
first uses one of the strings r1 , r2 which is lexicographically smaller, and then the other (note that r∗ , r0
always appear together in the distribution, except for the value given to the adversary as randomness of the
receiver).
Next the reduction gives obfuscated programs to the adversary, together with s0 , r1 , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge
r1 , r2 are r∗ , r0 , then the resulting distribution is exactly the distribution from HybB,2,2 . If r1 , r2 are r0 , r∗ ,
then the resulting distribution is exactly the distribution from HybB,2,3 .
231
there exists an adversary which can break security of a puncturable PRF RGkR in time t(λ) + poly(λ) with
distinguishing advantage ε(λ).
Proof. The proof is very similar to the proof of indistinguishability of hybrids HybB,2,1 , HybB,2,2 , except
that r0 and not r∗ is given to the adversary as randomness of the receiever.
We give a reduction to security of a puncturable PRF RGkR at the punctured point (r∗ , µ1 ∗ ).
The reduction first takes plaintexts m∗0 , m∗1 from the adversary. Next it chooses random r∗ , µ1 ∗ and sends the
point (r∗ , µ1 ∗ ) to the challenger of puncturable PRF game. The reduction gets back from the challenger the
punctured key kR {(r∗ , µ1 ∗ )} and the value µ2 ∗ , which is either RGkR (r∗ , µ1 ∗ ) or randomly chosen.
(except kR {(r∗ , µ1 ∗ )}), namely keys EK, DK of the main ACE, keys EKS , DKS of the sender ACE, keys
EKR , DKR of the receiver ACE, key kS of the sparse extracting PRF SG of the sender. It also runs setup of
s0 = EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), r0 = EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , ρ̂∗ ) for randomly chosen ρ̂∗ .
Next it computes punctured keys DKR {r∗ , r0 }, kR {(r∗ , µ1 ∗ ), (r0 , µ1 ∗ )} (by additionally puncturing challenge
kR {(r∗ , µ1 ∗ )} at (r0 , µ1 ∗ )), and EKR {Sρ̂∗ }, Sρ̂∗ = {(∗, ∗, ∗, ∗, ∗, ρ̂∗ )} for randomly chosen ρ̂∗ . It also
punctures keys EKS {P`∗0 }, DKS {P`∗0 }, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), and EK{p},
DK{p} at p = (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge µ2 ∗ was RGkR (r∗ , µ1 ∗ ), then the resulting distribution is exactly the
distribution from HybB,2,4 . If µ2 ∗ was randomly chosen, then the resulting distribution is exactly the
distribution from HybB,2,3 .
puncture it at another point. We note that the construction of an extracting puncturable PRF of [SW14] is
based on GGM PRF and satisfies this property.
there exists an adversary which can break security of iO for σ 0 -sized programs in time t(λ) + poly(λ) with
distinguishing advantage 31 · ε(λ).
Proof. The proof is identical to the proof of lemma 70.
security of a prg in time t(λ) + poly(λ) with distinguishing advantage ε(λ).
232
Proof. We give a reduction to security of a prg.
The reduction first takes plaintexts m∗0 , m∗1 from the adversary.
It samples all keys used in programs, namely keys EK, DK of the main ACE, keys EKS , DKS of the sender
ACE, keys EKR , DKR of the receiver ACE, key kS of the sparse extracting PRF SG of the sender, key kR
of the sparse extracting PRF RG of the receiver. It also runs setup of the level system to create the code of
Next it chooses random r∗ , µ1 ∗ and computes µ2 ∗ = RGkR (r∗ , µ1 ∗ ). It computes levels `∗0 = GenZero(µ1 ∗ ),
L∗0 = Transform(`∗0 , µ2 ∗ ). It sets µ3 ∗ = EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), s0 = EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
It receives ρ̂∗ from a challenger of a prg game which is either randomly chosen or prg(ρ∗ ) for randomly
chosen ρ∗ . Then the reduction sets r0 = EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , ρ̂∗ ).
Next it punctures keys EKS {P`∗0 }, DKS {P`∗0 }, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), and
EK{p}, DK{p} at p = (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge ρ̂∗ was an image of a prg, then the resulting distribution is exactly the distri-
bution from HybB,2,6 . If ρ̂∗ was randomly chosen, then the resulting distribution is exactly the distribution
from HybB,2,5 .
security of constrained decryption of the main ACE in time t(λ) + poly(λ) with distinguishing advantage
ε(λ).
that r0 and not r∗ is given to the adversary as randomness of the receiver.
security of iO for σ 0 -sized programs in time t(λ) + poly(λ) with distinguishing advantage ε(λ).
then there exists an adversary which can break the strong computational extractor property of a PRF SGkS
in time t(λ) + poly(λ) with distinguishing advantage ε(λ).
233
then there exists an adversary which can break security of contrained decryption of a sender-fake relaxed
Finally, we note that the distributions in HybB,3,5 and HybC are 2−λ -close (the reasoning is similar to
distributions HybB , HybB,1,1 ).
8.2.3 Reductions in the proof of lemma 56 (Semantic Security)

sender-fake relaxed ACE, receiver-fake relaxed ACE, main ACE, sparse extracting puncturable PRF, and iO
for program size σ 0 are (t(λ), ε(λ))-secure, we show that no time-t(λ) adversary can distinguish between
HybC and HybD with more than O(ε(λ)) + O(2−τ (λ) ) advantage.
(Note that security loss O(2−τ (λ) ) comes from conditioning on the fact that µ1 ∗ , µ2 ∗ are outside of the image
of the corresponding PRFs. Conditioning on s∗ , r∗ incurs only 2−λ loss and therefore we omit it.).
Lemma 81. Statistical distance between distributions HybC , HybC,1,1 is at most 2 · 2−λ .
Proof. Same as indistinguishability between hybrids HybB , HybB,1,1 .
respectively. Then, if there exists an adversary which can (t(λ), ε(λ))-distinguish HybC,1,1 and HybC,1,2 ,
then there exists an adversary which can break security of iO for σ 0 -sized programs in time t(λ) + poly(λ)
Proof. The only difference between programs SFake and SFakeC,1 is that SFakeC,1 uses a punctured key
Proof. Same as indistinguishability between hybrids HybB,3,3 , HybB,3,4 .
234
Proof. Same as indistinguishability between hybrids HybB,3,2 , HybB,3,3 .
which can (t(λ), ε(λ))-distinguish HybC,1,4 and HybC,1,5 , then there exists an adversary which can break the
strong computational extractor property of a PRF RGkR in time t(λ) + poly(λ) with distinguishing advantage
ε(λ).
Proof. The proof is similar to the proof of indistinguishability of hybrids HybB,1,3 , HybB,1,4 , except that the
reduction is to the strong extracting PRF of the receiver, not the sender.
We give a reduction to strong computationally extracting PRF RGkR .
The reduction first takes plaintexts m∗0 , m∗1 from the adversary. It chooses µ1 ∗ at random and sends the point
µ1 ∗ to the challenger of strong extractor game. The challenger samples the key kR for RG and either chooses
µ2 ∗ at random or computes it as µ2 ∗ = RGkR (r∗ , µ1 ∗ ) for randomly chosen r∗ . The reduction gets back
from the challenger the key kR and the value µ2 ∗ .
(except kR ), namely keys EK, DK of the main ACE, keys EKS , DKS of the sender ACE, keys EKR , DKR of
the receiver ACE, key kS of the sparse extracting PRF SG of the sender. It also runs setup of the level system
to create the code of GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags.
s0 = EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), r0 = EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ )) for randomly chosen ρ∗ .
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge µ2 ∗ was RGkR (r∗ , µ1 ∗ ), then the resulting distribution is exactly the
distribution from HybC,1,4 . If µ2 ∗ was randomly chosen, then the resulting distribution is exactly the
distribution from HybC,1,5 .
respectively. Further, assume that µ1 ∗ is outside the image of the PRF SG, and µ2 ∗ is outside the image of
the PRF RG. Then, if there exists an adversary which can (t(λ), ε(λ))-distinguish HybC,1,5 and HybC,2,1 ,
Proof. The only difference between programs P3B,2 and P3B,3 is that P3B,3 uses a punctured key
EK{p0 , p1 }, where p0 = (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ). We argue that the program never
235
needs to encrypt p0 , p1 , and therefore puncturing these points doesn’t change the functionality:
Since we assumed that µ1 ∗ is outside of the image of a PRF SG, validity check can pass only if P3 is
run on some (s, m, µ1 ∗ , µ2 ∗ ), where s encodes m, µ1 ∗ (and other values). However, note that P3C,2 on
such input can only execute trapdoor step (and not the main step); thus the key in the main step can be
safely punctured. Further, in order for the program to run encryption algorithm in the trapdoor step on
input p0 or p1 , fake s should encode level `∗0 . However, note that DKS is punctured at the set P`∗0 =
{(∗, ∗, ∗, ∗, `∗0 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), and thus P3C,2 rejects all fake s with `∗0 inside except s which
encodes (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), that is, s0 . Finally, note that running P3C,2 on (s0 , m, µ1 ∗ , µ2 ∗ ) will pass
validity check only if m = m∗0 (again, since µ1 ∗ is outside of the image of PRF SG). Thus (s0 , m∗0 , µ1 ∗ , µ2 ∗ )
is the only potentially problematic input (in particular, the key is never used to encrypt p1 ). However, running
P3C,2 on (s0 , m∗0 , µ1 ∗ , µ2 ∗ ) will not trigger encryption algorithm, since the program directly outputs the
value µ3 ∗ encoded in s0 . Thus P3C,2 never encrypts p0 or p1 in the trapdoor step.
then there exists an adversary which can break security of constrained decryption of main ACE in time
t(λ) + poly(λ) with distinguishing advantage ε(λ).
Proof. The proof is similar to the proof of indistinguishability of hybrids HybB,3,3 , HybB,3,4 , except that EK
is additionally punctured at another point, and µ2 ∗ is randomly chosen.
We give a reduction to security of constrained decryption of main ACE.
It chooses random µ1 ∗ , µ2 ∗ . It computes levels `∗0 = GenZero(µ1 ∗ ), L∗0 = Transform(`∗0 , µ2 ∗ ).
Next the reduction sends the set consisting of two points p0 = (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 )
to puncture encryption key, sets p1 , ∅ to puncture decryption key, and plaintext p0 to the challenger of
constrained decryption game (note that plaintext p0 doesn’t belong to the set {p1 } for puncturing DK
and thus this is a valid query to the challenger of constrained decryption game). The challenger samples
keys EK, DK and it sends back to the reduction EK{p0 , p1 }, key which is either DK{p1 } or DK{∅}, and
µ3 ∗ = EncEK (p0 ).
Next the reduction punctures keys EKS {P`∗0 }, DKS {P`∗0 }, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), and sets s0 = EncEKS {P`∗ } (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), r0 =
0
EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ )) for randomly chosen ρ∗ .
s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge key was DK{∅}, then the resulting distribution is exactly the distribution
from HybC,2,1 . If key was DKS {p1 }, then the resulting distribution is exactly the distribution from HybC,2,2 .
236
then there exists an adversary which can break security of iO for σ 0 -sized circuits in time t(λ) + poly(λ) with
distinguishing advantage 21 ε(λ).
Proof. We start with analyzing program Dec: The only difference between programs DecC,1 and DecC,2
is that DecC,1 uses key DK{p1 } and DecC,2 uses DK{p0 , p1 }, i.e. the key is additionally punctured at p0
(here p0 = (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 )). We will argue that if DecC,1 on input µ3 ∗ =
ACE.EncEK (p0 ) reaches the line where it needs to decrypt µ3 ∗ , then it always outputs 0 fail0 . Therefore
puncturing this point (and thus forcing DecC,2 to output 0 fail0 when attempt to decrypt µ3 ∗ ) doesn’t change
the functionality:
First, note that if input µ3 = µ3 ∗ , but (µ1 , µ2 ) 6= (µ1 ∗ , µ2 ∗ ) and the program reached decryption of µ3 ∗ , then
the program outputs 0 fail0 : indeed, µ3 ∗ encrypts µ1 ∗ , µ2 ∗ and thus the check (µ1 , µ2 ) = (µ1 ∗ , µ2 ∗ ) will not
pass.
Second, by assumption µ2 ∗ is outside of the image of a PRF RG, and thus validity check can pass only if
DecC,1 is run on some (r, µ1 ∗ , µ2 ∗ , µ3 ∗ ), where r encodes µ1 ∗ , µ2 ∗ (and other values). However, note that
DecC,1 on such input can only execute the trapdoor step (and not the main step); thus the key in the main
step can be safely punctured. Further, in order for the program to output m after decryption in the trapdoor
step, the condition “isLess(L0 , L00 )” should hold. However, when input µ3 = µ3 ∗ , L00 is equal to [0, µ1 ∗ , µ2 ∗ ],
which is the smallest possible level and therefore there doesn’t exist L0 such that isLess(L0 , L00 ) = true.
Thus, if DecC,1 reached decryption in the trapdoor step on input µ3 ∗ , it will anyway output 0 fail0 due to failed
“isLess” check and therefore we can puncture DK at p0 such that an attempt to decrypt µ3 ∗ would cause Dec
to output 0 fail0 immediately.
Next we analyze program RFake. The difference between RFakeC,1 and RFakeC,2 is that the key DK, which
is already punctured at p1 , is additionally punctured at p0 . In order to preserve the functionality of RFake
on input µ3 ∗ , we additionally instruct RFake to use level L∗0 = [0, µ1 ∗ , µ2 ∗ ] on input µ3 ∗ (without actually
decrypting µ3 ∗ ). Note that this is what RFakeC,1 would do on input µ3 ∗ ; thus this doesn’t change the
functionality.
then there exists an adversary which can break indistinguishability of ciphertexts of main ACE in time
t(λ) + poly(λ) with distinguishing advantage 12 ε(λ).
Proof. We give a reduction to indistinguishability of ciphertexts of main ACE.

237
to puncture encryption key, the same set {p0 , p1 } to puncture decryption key, and plaintexts p0 , p1 to the
challenger of indistinguishability of ciphertexts game (note that plaintexts belong to both punctured sets
and thus this is a valid query to the challenger of indistinguishability of ciphertexts game). The challenger
samples keys EK, DK and it sends back to the reduction EK{p0 , p1 }, DK{p0 , p1 }, and µ3 ∗ which is either
EncEK (p0 ) or EncEK (p1 ).
0
s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge µ3 ∗ was EncEK (p0 ), then the resulting distribution is exactly the distribution
from HybC,2,3 . If µ3 ∗ was EncEK (p1 ), then the resulting distribution is exactly the distribution from HybC,2,4 .
then there exists an adversary which can break security of iO for σ 0 -sized circuits in time t(λ) + poly(λ) with
distinguishing advantage 21 ε(λ).
Proof. The proof is very similar to the proof of lemma 88, except that in this hybrid µ3 ∗ = EncEK (p1 ) instead
of p0 , and we unpuncture DK at p1 instead of p0 .
We start with analyzing program Dec: The only difference between programs DecC,3 and DecC,2 is that
DecC,3 uses key DK{p0 } and DecC,2 uses DK{p0 , p1 }, i.e. the key is additionally punctured at p1 (here
p0 = (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 )). We will argue that if DecC,3 on input µ3 ∗ = EncEK (p1 )
reaches the line where it needs to decrypt µ3 ∗ , then it always outputs 0 fail0 . Therefore puncturing this point
(and thus forcing DecC,2 to output 0 fail0 when attempt to decrypt µ3 ∗ ) doesn’t change the functionality:
First, note that if input µ3 = µ3 ∗ , but (µ1 , µ2 ) 6= (µ1 ∗ , µ2 ∗ ) and the program reached decryption of µ3 ∗ , then
the program outputs 0 fail0 : indeed, µ3 ∗ encrypts µ1 ∗ , µ2 ∗ and thus the check (µ1 , µ2 ) = (µ1 ∗ , µ2 ∗ ) will not
pass.
Second, since µ2 ∗ is random, it is outside of the image of a PRF RG with overwhelming probability, and thus
validity check can pass only if DecC,3 is run on some (r, µ1 ∗ , µ2 ∗ , µ3 ∗ ), where r encodes µ1 ∗ , µ2 ∗ (and other
values). However, note that DecC,3 on such input can only execute trapdoor step (and not the main step);
thus the key in the main step can be safely punctured. Further, in order for the program to output m after
decryption in the trapdoor step, the condition “isLess(L0 , L00 )” should hold. However, when input µ3 = µ3 ∗ ,
L00 is equal to [0, µ1 ∗ , µ2 ∗ ], which is the smallest possible level and therefore there doesn’t exist L0 such that
isLess(L0 , L00 ) = true. Thus, if DecC,3 reached decryption in the trapdoor step on input µ3 ∗ , it will anyway
output 0 fail0 due to failed “isLess” check and therefore we can puncture DK at p1 such that an attempt to
decrypt µ3 ∗ would cause Dec to output 0 fail0 immediately.
Next we analyze program RFake. The difference between RFakeC,3 and RFakeC,2 is that the key DK, which
is already punctured at p0 , is additionally punctured at p1 . In order to preserve the functionality of RFake
on input µ3 ∗ , we additionally instruct RFake to use level L∗0 = [0, µ1 ∗ , µ2 ∗ ] on input µ3 ∗ (without actually
decrypting µ3 ∗ ). Note that this is what RFakeC,3 would do on input µ3 ∗ ; thus this doesn’t change the
238
functionality.
then there exists an adversary which can break security of constrained decryption of main ACE in time
t(λ) + poly(λ) with distinguishing advantage ε(λ).
Proof. The proof is similar to the proof of indistinguishability of hybrids HybC,2,1 , HybC,2,2 , except that we
unpuncture DK at p0 instead of p1 , and our third message is µ3 ∗ = EncEK (p1 ) instead of µ3 ∗ = EncEK (p0 ).
We give a reduction to security of constrained decryption of main ACE.
to puncture encryption key, sets p0 , ∅ to puncture decryption key, and plaintext p1 to the challenger of
constrained decryption game (note that plaintext p1 doesn’t belong to the set {p0 } for puncturing DK
and thus this is a valid query to the challenger of constrained decryption game). The challenger samples
keys EK, DK and it sends back to the reduction EK{p0 , p1 }, key which is either DK{p0 } or DK{∅}, and
µ3 ∗ = EncEK (p1 ).
0
s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge key was DK{∅}, then the resulting distribution is exactly the distribution
from HybC,2,6 . If key was DKS {p0 }, then the resulting distribution is exactly the distribution from HybC,2,5 .
which can (t(λ), ε(λ))-distinguish HybC,2,7 and HybC,3,1 , then there exists an adversary which can break the
239
strong computational extractor property of a PRF RGkR in time t(λ) + poly(λ) with distinguishing advantage
ε(λ).
Proof. The proof is identical to the proof of indistinguishability of hybrids HybC,1,4 , HybC,1,5 , except that
µ3 ∗ = EncEK (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ) instead of µ3 ∗ = EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ).
Proof. The proof is similar to the proof of indistinguishability of hybrids HybC,1,3 , HybC,1,4 (with the
difference that µ3 ∗ = EncEK (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ) instead of µ3 ∗ = EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), and the reduction
is made for the point (s∗ , m∗1 ) instead of (s∗ , m∗0 )).
Proof. The proof is similar to the proof of indistinguishability of hybrids HybC,1,2 , HybC,1,3 (with the
difference that µ3 ∗ = EncEK (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ) instead of µ3 ∗ = EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), and µ1 ∗ =
SG(s∗ , m∗1 ) instead of µ1 ∗ = SG(s∗ , m∗0 )).
Proof. The only difference between programs SFake and SFakeC,1 is that SFakeC,1 uses a punctured key
Finally, we note that the distributions in HybC,3,4 and HybD are O(2−λ )-close (the reasoning is similar to
8.2.4 Reductions in the proof of lemma 57 (Indistinguishability of Levels)

sender-fake relaxed ACE, sparse extracting puncturable PRF, and iO for program size σ 0 are (t(λ), ε(λ))-
secure, and assuming the level system is (t(λ), ε1 (λ, T, τ ))-secure, we show that no time-t(λ) adversary can
distinguish between HybD and HybE with more than O(ε(λ)) + ε1 (λ, T, τ ) advantage.
(Note that security loss O(2−τ (λ) ) comes from conditioning on the fact that µ1 ∗ is outside of the image of
the corresponding PRF. Conditioning on s∗ , r∗ incurs only 2−λ loss and therefore we omit it.).
Lemma 97. Statistical distance between distributions HybD , HybD,1,1 is at most 2 · 2−λ .
240
Proof. Same as indistinguishability between hybrids HybB , HybB,1,1 .
respectively. Then, if there exists an adversary which can (t(λ), ε(λ))-distinguish HybD,1,1 and HybD,1,2 ,
Proof. The only difference between programs SFake and SFakeD,1 is that SFakeD,1 uses a punctured key
then there exists an adversary which can break security of constrained decryption of sender-fake relaxed
Proof. The proof is similar to the proof of indistinguishability of hybrids HybB,1,2 , HybB,1,3 (with the
difference that r0 instead of r∗ is given to the adversary, and µ3 ∗ = EncEK (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ) instead of
µ3 ∗ = EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), µ1 ∗ = SG(s∗ , m∗1 ) instead of µ1 ∗ = SG(s∗ , m∗0 )).
then there exists an adversary which can break computational strong extractor property of the PRF SG in
Proof. The proof is similar to the proof of indistinguishability of hybrids HybB,1,3 , HybB,1,4 (with the
difference that r0 (instead of r∗ ) is given to the adversary, µ3 ∗ = EncEK (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ) instead of
µ3 ∗ = EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), and the reduction is made for the point (s∗ , m∗1 ) instead of (s∗ , m∗0 )).
which can (t(λ), ε(λ))-distinguish HybD,1,4 and HybD,2,1 , then there exists an adversary which can break
security of iO for σ 0 -sized programs in time t(λ) + poly(λ) with distinguishing advantage 12 ε(λ).
Proof. The difference between programs in the two hybrids is that in HybD,2,1 programs use only punctured
versions of programs of the level system. We argue that this doesn’t change the functionality of the programs
of deniable encryption, since these programs never need to call programs of the level system on punctured
inputs.
We start with analyzing program P3D,2 . By assumption, µ1 ∗ is outside of the image of a PRF SG, and
thus when µ1 = µ1 ∗ validity check can pass only if P3 is run on some (s, m, µ1 ∗ , µ2 ), where s encodes
m, µ1 ∗ (and other values). However, note that P3D,2 on such input can only execute trapdoor step (and
not the main step); thus in the main step we can use GenZero[µ1 ∗ ] which is punctured at µ1 ∗ . Moreover,
since GenZero[µ1 ∗ ] never outputs `∗0 , we can also use Transform[(`∗0 , µ2 ∗ )] which is punctured at the input
(`∗0 , µ2 ∗ ).
241
It remains to argue that we can puncture Transform[(`∗0 , µ2 ∗ )] at the input (`∗0 , µ2 ∗ ) in the trapdoor step as
well. Note that in order to run Transform on this input in the trapdoor step, P3 should take as input fake
s which encodes `∗0 (among other things). However, since DKS is punctured at P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), the only such fake s is ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ), that is, s0 . Further, in
order for “(m, µ1 ) = (m0 , µ1 0 )” check to pass, inputs to P3 should be m = m∗0 and µ1 = µ1 ∗ . Finally, in
order to call Transform on (`∗0 , µ2 ∗ ), the input µ2 to P3 should be µ2 ∗ . In other words, the only input on
which P3 could potentially run Transform at the punctured point is (s0 , m∗0 , µ1 ∗ , µ2 ∗ ); however, in this case
P3 simply outputs µ3 ∗ , which is encoded in s0 , without running Transform at all. Thus we can puncture
Transform safely.
Next we analyze program SFakeD,2 . By assumption, µ1 ∗ is is outside of the image of a PRF SG, and thus
validity check can pass only if SFake is run on some (s, m, m̂, µ1 ∗ , µ2 , µ3 ), where s encodes m, µ1 ∗ (and
other values). However, note that SFakeD,2 on such input can only execute trapdoor step (and not the main
step); thus in the main step we can use GenZero[µ1 ∗ ] which is punctured at µ1 ∗ .
security of the level system with an upper bound T and tag size τ in time t(λ) + poly(λ) with distinguishing
advantage ε(λ).
Proof. We give a reduction to security of the level system.

The reduction first takes plaintexts m∗0 , m∗1 from the adversary. It samples all keys used in programs, namely
keys EK, DK of the main ACE, keys EKS , DKS of the sender ACE, keys EKR , DKR of the receiver ACE,
key kS of the sparse extracting PRF SG of the sender, key kR of the sparse extracting PRF RG of the receiver.
It chooses random r∗ and µ1 ∗ and computes µ2 ∗ = RGkR (r∗ , µ1 ∗ ). It sends µ1 ∗ , µ2 ∗ as the first and the
second tag to the challenger of the level system. The challenger chooses bit b at random and runs setup of the
level system to obtain programs GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags. Then
it computes `∗0 = GenZero(µ1 ∗ ), `∗1 = Increment(`∗0 ), and L∗0 = Transform(`∗0 , µ2 ∗ ). It also obfuscates
punctured programs GenZero[µ1 ∗ ], Increment, Transform[(`∗b , µ2 ∗ )], isLess, RetrieveTag, RetrieveTags. It
sends these obfuscated punctured programs to the reduction, together with `∗b and L∗0 .
The reduction computes µ3 ∗ = EncEK (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ), s0 = EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗b ), and r0 =
Next the reduction punctures keys EKS {P`∗b }, DKS {P`∗b } at the set P`∗b = {(∗, ∗, ∗, ∗, `∗b )} \
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗b ).
Then the reduction uses variables and code obtained from the challenger to construct and obfuscate programs
P1, P3, SFake, (fig. 114, fig. 115) and P2, Dec, RFake (fig. 19). It gives obfuscated programs to the
adversary, together with s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge bit b is 0, then the resulting distribution is exactly
the distribution from HybD,2,1 . If b is 1, then the resulting distribution is exactly the distribution from
HybD,2,2 .
242
security of iO for σ 0 -sized programs in time t(λ) + poly(λ) with distinguishing advantage 12 ε(λ).
Proof. This proof is very similar to the proof of lemma 101, except that Transform is punctured at (`∗1 , µ2 ∗ )
instead of (`∗0 , µ2 ∗ ).
The difference between programs in HybD,2,2 , HybD,2,3 is that in HybD,2,2 programs use only punctured
versions of programs of the level system. We argue that this doesn’t change the functionality of the programs
of deniable encryption, since these programs never need to call programs of the level system on punctured
inputs.
We start with analyzing program P3D,4 . By assumption µ1 ∗ is outside of the image of a PRF SG, and
thus when µ1 = µ1 ∗ validity check can pass only if P3 is run on some (s, m, µ1 ∗ , µ2 ), where s encodes
m, µ1 ∗ (and other values). However, note that P3D,4 on such input can only execute trapdoor step (and
not the main step); thus in the main step we can use GenZero[µ1 ∗ ] which is punctured at µ1 ∗ . Moreover,
since GenZero[µ1 ∗ ] never outputs `∗1 , we can also use Transform[(`∗1 , µ2 ∗ )] which is punctured at the input
(`∗1 , µ2 ∗ ).
It remains to argue that we can puncture Transform[(`∗1 , µ2 ∗ )] at the input (`∗1 , µ2 ∗ ) in the trapdoor step as
well. Note that in order to run Transform on this input in the trapdoor step, P3D,5 should take as input fake
s which encodes `∗1 (among other things). However, since DKS is punctured at P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )} \
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ), the only such fake s is ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ), that is, s0 . Further, in
order for “(m, µ1 ) = (m0 , µ1 0 )” check to pass, inputs to P3 should be m = m∗0 and µ1 = µ1 ∗ . Finally, in
order to call Transform on (`∗1 , µ2 ∗ ), the input µ2 to P3 should be µ2 ∗ . In other words, the only input on
which P3 could potentially run Transform at the punctured point is (s0 , m∗0 , µ1 ∗ , µ2 ∗ ); however, in this case
P3 simply outputs µ3 ∗ , which is encoded in s0 , without running Transform at all. Thus we can puncture
Transform safely.
Next we analyze program SFakeD,4 . Since µ1 ∗ is outside of the image of a PRF SG, and thus validity check
can pass only if SFake is run on some (s, m, m̂, µ1 ∗ , µ2 , µ3 ), where s encodes m, µ1 ∗ (and other values).
However, note that SFakeD,4 on such input can only execute trapdoor step (and not the main step); thus in
the main step we can use GenZero[µ1 ∗ ] which is punctured at µ1 ∗ .
Proof. The only difference between programs SFakeD,5 and SFakeD,6 is that in SFakeD,6 the key EKS is also
punctured at P`∗0 , where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} (in addition to being punctured at P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )} \
(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 )). This is without changing functionality, since SFake never needs to encrypt a plaintext
with level `∗0 , since `∗0 = [0, µ1 ∗ ] and SFake encrypts levels with value at least 1.
security of constrained decryption of sender-fake relaxed ACE in time t(λ) + poly(λ) with distinguishing
advantage ε(λ).
243
Proof. The proof is similar to the proof of indistinguishability of hybrids HybD,1,2 , HybD,1,3 , except that
`∗1 instead of `∗0 is used in the distribution, and keys EK, DK are additionally punctured at the set P`∗1 =
{(∗, ∗, ∗, ∗, `∗1 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ).
We give a reduction to security of constrained decryption of sender ACE.
It chooses random r∗ and µ1 ∗ and computes µ2 ∗ = RGkR (r∗ , µ1 ∗ ). It computes levels `∗0 = GenZero(µ1 ∗ ),
`∗1 = Increment(`∗0 ), L∗0 = Transform(`∗0 , µ2 ∗ ). It sets µ3 ∗ = EncEK (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ).
Next the reduction sends the set P`∗0 ∪ P`∗1 as a set to puncture encryption key (where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )},
P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 )), and sends sets P`∗1 and P`∗0 ∪ P`∗1 as sets to puncture
decryption key to the challenger of constrained decryption game. The challenger samples keys EKS , DKS
and it sends back to the reduction EKS {P`∗0 ∪ P`∗1 } and key which is either DKS {P`∗1 } or DKS {P`∗0 ∪ P`∗1 }.
Next the reduction computes s0 = EncEKS {P`∗ ∪P`∗ } (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ) (note that this point is not punc-
0 1
tured) and r0 = EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ )) for randomly chosen ρ∗ .
with s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge key is DKS {P`∗0 ∪ P`∗1 }, then the resulting distribution is exactly the
distribution from HybD,3,2 . If key is DKS {P`∗1 }, then the resulting distribution is exactly the distribution
from HybD,3,1 .
advantage ε(λ).
Proof. The proof is similar to the proof of indistinguishability of hybrids HybD,3,1 , HybD,3,2 , except that we
unpuncture DK at the set P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ) instead of P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} .
We give a reduction to security of constrained decryption of sender ACE.
Next the reduction sends the set P`∗0 ∪ P`∗1 as a set to puncture encryption key (where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )},
P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 )), and sends sets P`∗0 and P`∗0 ∪ P`∗1 as sets to puncture
decryption key to the challenger of constrained decryption game. The challenger samples keys EKS , DKS
and it sends back to the reduction EKS {P`∗0 ∪ P`∗1 } and key which is either DKS {P`∗0 } or DKS {P`∗0 ∪ P`∗1 }.
244
Next the reduction computes s0 = EncEKS {P`∗ ∪P`∗ } (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ) (note that this point is not punc-
0 1
tured) and r0 = EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ )) for randomly chosen ρ∗ .
with s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge key is DKS {P`∗0 ∪ P`∗1 }, then the resulting distribution is exactly the
distribution from HybD,3,2 . If key is DKS {P`∗0 }, then the resulting distribution is exactly the distribution
from HybD,3,3 .
Proof. The only difference between programs SFakeD,8 and SFakeD,9 is that in SFakeD,8 the key EKS is
also punctured at P`∗1 , where P`∗1 = {(∗, ∗, ∗, ∗, `∗1 )} \ (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ) (in addition to being punctured
at P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}). We argue that this is without changing functionality:
First, note that the trapdoor step never needs to encrypt the plaintext with `∗1 : for that SFake would need to
get as input some fake s which encodes `∗0 , but such fake s doesn’t exist since DKS is punctured on the whole
set P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}.
Second, in order to encrypt `∗1 in the main step, SFakeD,9 should get µ1 ∗ as input. However, in order to
pass validity check with µ1 ∗ (which is outside of the image of PRF SG), SFakeD,9 should get as input
some (s, m, m̂, µ1 ∗ , µ2 , µ3 ), where s is fake and encodes (m, µ1 ∗ ) (among other things). But on such input
SFakeD,9 never executes the main step - it executes the trapdoor step. Thus we can additionally puncture EK
at P`∗1 in the main step.
advantage ε(λ).
Proof. The proof is similar to the proof of indistinguishability of hybrids HybD,3,2 , HybD,3,3 , except that
EKS , DKS are punctured at different sets. We give a reduction to security of constrained decryption of sender
ACE.
Next the reduction sends the set P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} as a set to puncture encryption key, and sends sets P`∗0
and ∅ as sets to puncture decryption key to the challenger of constrained decryption game. The challenger
245
samples keys EKS , DKS and it sends back to the reduction EKS {P`∗0 } and key which is either DKS {P`∗0 } or
DKS {∅}.
Next the reduction computes s0 = EncEKS {P`∗ } (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ) (note that this point is not punctured)
0
and r0 = EncEKR (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ )) for randomly chosen ρ∗ .
(fig. 118, fig. 119) and P2, Dec, RFake (fig. 19). It gives obfuscated programs to the adversary, together with
s0 , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ . If challenge key is DKS {P`∗0 }, then the resulting distribution is exactly the distribution
from HybD,3,4 . If key is DKS {∅}, then the resulting distribution is exactly the distribution from HybD,3,5 .
Proof. The only difference between programs SFakeD,9 and SFakeD,10 is that in SFakeD,9 the key EKS is
punctured at P`∗0 , where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}. This is without changing functionality, since SFake never
needs to encrypt a plaintext with level `∗0 , since `∗0 = [0, µ1 ∗ ] and SFake encrypts levels with value at least
1.
then there exists an adversary which can break computational strong extractor property of the PRF SG in
Proof. The proof is identical to the proof of indistinguishability of hybrids HybD,1,3 , HybD,1,4 , except that
fake s0 is computed using level `∗1 instead of `∗0 .
Finally, we note that the distributions in HybD,3,7 and HybE are O(2−λ )-close (the reasoning is similar to
246
9 Proof of off-the-record deniability of our encryption protocol
In this section we show that our scheme also satisfies off-the-record property, which says that the adversary
who gets contradicting claims from parties (that is, the sender claims that the plaintext was m∗0 and shows
consistent randomness, but the receiver claims that the plaintext was m∗1 and also shows consistent random-
ness) cannot tell which party is lying (if not both) and which plaintext was actually sent. In other words,
neither party can prove which plaintext was used in the protocol. We underline however that this property
only holds as long as parties act honestly during the protocol: indeed, a malicious party can always choose its
randomness as a result of a prg and provide the seed of this prg as a proof that its randomness is genuine.
Recall the definition of off-the-record deniability states that the following three distributions are computation-
ally indistinguishable:
• the sender claims m∗0 was sent, the receiver claims m∗1 was sent, the plain-
text was m∗0 : (PP, m∗0 , m∗1 , m∗2 , s∗ , r0 , tr(s∗ , r∗ , m∗0 )), where s∗ , r∗ are randomly
chosen, r0 = RFake(m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ ; ρ∗ ) for randomly chosen ρ∗ , and PP =
λ
Setup(1 ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup .
• the sender claims m∗0 was sent, the receiver claims m∗1 was sent, the plaintext was
m∗1 : (PP, m∗0 , m∗1 , m∗2 , s0 , r∗ , tr(s∗ , r∗ , m∗1 )), where s∗ , r∗ are randomly chosen, s0 =
SFake(s∗ , m∗1 , m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), and PP = Setup(1λ ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for
• the sender claims m∗0 was sent, the receiver claims m∗1 was sent, the plaintext was
m∗2 : (PP, m∗0 , m∗1 , m∗2 , s0 , r0 , tr(s∗ , r∗ , m∗2 )), where s∗ , r∗ are randomly chosen, s0 =
SFake(s∗ , m∗2 , m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ), r0 = RFake(m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ ; ρ∗ ) for randomly chosen ρ∗ , and
PP = Setup(1λ ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup .
Note that the first distribution is the same as the following distribution, since RFake(m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ ; ρ∗ )
outputs ACE.EncEKR (m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ )):
HybA = (PP, m∗0 , m∗1 , s∗ , r0 , tr(s∗ , r∗ , m∗0 )), where s∗ , r∗ are randomly chosen,
r 0 = ACE.EncEKR (m1 , µ1 , µ2 , µ3 , L0 , prg(ρ )) for randomly chosen ρ∗ , and PP
∗ ∗ ∗ ∗ ∗ ∗ =
λ
Setup(1 ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup .
Further, note that the second distribution is statistically close to the following distribution, since
SFake(s∗ , m∗1 , m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ) with overwhelming probability over the choice of s∗ outputs
ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ):
HybE = (PP, m∗0 , m∗1 , s0 , r∗ , tr(s∗ , r∗ , m∗1 )), where s∗ , r∗ are randomly chosen, s0 =
Finally, note that the third distribution is statistically close to the following distribution:
HybD0 = (PP, m∗0 , m∗1 , m∗2 , s0 , r0 , tr(s∗ , r∗ , m∗2 )), where s∗ , r∗ are randomly chosen, s0 =
ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ), r0 = ACE.EncEKR (m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ )) for randomly cho-
sen ρ∗ , and PP = Setup(1λ ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup .
Thus to prove off-the-record deniability it suffices to show indistinguishability between hybrids HybA , HybE ,
and HybD0 . The proof of this statement consists of the same main components as the proof of deniability,
albeit in a different order and with slight changes. Below we describe the structure of the proof and comment
247
on the differences with the proof of deniability. Conscretely, we show that HybA ≈ HybB ≈ HybC
≈ HybD ≈ HybE and that HybC ≈ HybD0 , where hybrids are as follows:
1. Indistinguishability of explanations of the sender: starting from HybA , we switch real s∗ to fake s0 ,
which encodes plaintext m∗0 , transcript µ1 ∗ , µ2 ∗ , µ3 ∗ , and level `∗ = [0, µ1 ∗ ], moving to the following
distribution:
HybB = (PP, m∗0 , m∗1 , m∗2 , s0 , r0 , tr(s∗ , r∗ , m∗0 )), where s∗ , r∗ are randomly chosen, s0 =
The proof of this step is identical to the proof of lemma 54, except that everywhere (in all hybrids and
reductions) we additionally generate r0 = ACE.EncEKR (m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ )) for randomly
chosen ρ∗ and give r0 (instead of r∗ ) to the adversary.
2. Indistinguishability of levels: we switch the level encoded in s0 from `∗0 = [0, µ1 ∗ ] to `∗1 = [1, µ1 ∗ ]
(while keeping L∗0 = [0, µ1 ∗ , µ2 ∗ ] the same), moving to the following distribution:
HybC = (PP, m∗0 , m∗1 , m∗2 , s0 , r0 , tr(s∗ , r∗ , m∗0 )), where s∗ , r∗ are randomly chosen, s0 =
chosen ρ∗ and PP = Setup(1λ ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup .
The proof of this step is identical to the proof of lemma 57, except that in all hybrids and reduc-
tions we generate r0 = RFake(m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ ; ρ∗ ) instead of r0 = RFake(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ; ρ∗ ),
µ3 ∗ = ACE.EncEK (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ) instead of µ3 ∗ = ACE.EncEK (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ), and µ1 ∗ =
SG(s∗ , m∗0 ) instead of µ1 ∗ = SG(s∗ , m∗1 ) (except when µ1 ∗ is randomly chosen).
3. Semantic security: we switch the transcript from encrypting m∗0 to encrypting m∗1 , moving to the
HybD = (PP, m∗0 , m∗1 , m∗2 , s0 , r0 , tr(s∗ , r∗ , m∗1 )), where s∗ , r∗ are randomly chosen, s0 =
The proof of this step is identical to the proof of lemma 56, except that in all hybrids and reduc-
tions we generate r0 = RFake(m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ ; ρ∗ ) instead of r0 = RFake(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ; ρ∗ ),
for randomly chosen ρ∗ , and s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ) instead of s0 =
ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ).
4. Indistinguishability of explanations of the receiver: we switch fake r0 , which encodes plaintext m∗1 ,
transcript µ1 ∗ , µ2 ∗ , µ3 ∗ , and level L∗ = [0, µ1 ∗ , µ2 ∗ ], to real (randomly chosen) r∗ , thus moving to the
HybE = (PP, m∗0 , m∗1 , m∗2 , s0 , r∗ , tr(s∗ , r∗ , m∗1 )), where s∗ , r∗ are randomly chosen, s0 =
The proof of this step is very close to the proof of lemma 55, except for a couple of changes. First,
we switch the role of m∗0 , m∗1 everywhere (in hybrids and reductions), and we generate s0 using level
`∗1 instead of `∗0 . However, we still generate s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ) (as opposed
to s0 = ACE.EncEKS (m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 )), and we use the set P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} (isntead of
P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )} \ (m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 )).
248
For the ease of verification, in the paragraph below we present the list of hybrids proving indistin-
guishability of HybD and HybE .
Semantic security for plaintext m∗2 : besides showing indistinguishability between HybC and HybD , we
also show indistinguishability between HybC and HybD0 , i.e. we switch the transcript from encrypting m∗0 to
encrypting m∗2 , moving from HybC to the following distribution:
HybD0 = (PP, m∗0 , m∗1 , m∗2 , s0 , r0 , tr(s∗ , r∗ , m∗2 )), where s∗ , r∗ are randomly chosen, s0 =
ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ), r0 = ACE.EncEKR (m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , prg(ρ∗ )) for randomly cho-
sen ρ∗ , and PP = Setup(1λ ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup .
The proof of this step is identical to the proof of lemma 56, except that in all hybrids and reductions we generate
r0 = RFake(m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ ; ρ∗ ) instead of r0 = RFake(m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ; ρ∗ ), for randomly chosen ρ∗ ,
and s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ) instead of s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗0 ). Also,
everywhere in hybrids and reductions we use p0 = (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), p2 = (m∗2 , µ1 ∗ , µ2 ∗ , L∗0 ) instead of
p0 = (m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), p1 = (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ).
List of hybrids for the proof of indistinguishability of HybD and HybE
Now we present the list of hybrids for the proof of indistinguishability of receiver explanation of off-the-record
deniability. We do not present the reductions since they are very similar to the corresponding reductions
(section 8.2.2), used for hybrids in section 8.1.2 in the proof of lemma 55. For a more convenient reference to
security reductions, we do not change enumeration of hybrids from section 8.1.2, and we keep hybrids in the
same order as there (starting from randomly chosen r∗ , and moving to fake r0 ).
We also present programs (those which require changes compared to their version in the proof of lemma 55).
List of hybrids. First in a sequence of hybrids we “eliminate” complementary ciphertext µ3 ∗ =
ACE.EncEK (1 ⊕ m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ), i.e. make programs Dec and SFake reject it:
Setup(1 ; P1, P2, P3, Dec, SFake, RFake; rSetup ) for randomly chosen rSetup ; s∗ , r∗ are cho-
λ

Note that this distribution is exactly the distribution from HybD , conditioned on the fact that s∗ , r∗ are
outside of images of their ACE.
Setup(1 ; P1B,1 , P2, P3B,1 , Dec, SFakeB,1 , RFake; rSetup ) for randomly chosen rSetup ; s∗ , r∗
λ

That is, in program SFake we puncture encryption key EKS of the sender-fake ACE at the set
P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}. Indistinguishability holds by iO, since this modification doesn’t change
the functionality of SFake due to the fact that SFake never encrypts plaintexts with level `∗0 .
λ ∗
249
same set P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}. Indistinguishability holds by security of constrained key of ACE,
since the corresponding encryption key EKS is already punctured at the same set.
Setup(1 ; P1B,2 , P2, P3B,2 , Dec, SFakeB,2 , RFake; rSetup ) for randomly chosen rSetup ; r∗ is chosen
λ

λ ∗
Setup(1 ; P1B,3 , P2, P3B,3 , Dec, SFakeB,3 , RFake; rSetup ) for randomly chosen rSetup ; r is chosen
That is, in program P3 we puncture encryption key EK of the main ACE at the point p = (1 ⊕
m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ). Indistinguishability holds by iO, since P3 never needs to encrypt this point. Roughly,
this is because of the following: since µ1 ∗ is random and outside of the image of a PRF SG, P3 never
encrypts p in the main step. In order to encrypt it in trapdoor step, P3 needs to take as input some fake
s encoding level `∗0 , which doesn’t exist due to the fact that DKS is punctured at the set P`∗0 .
λ ∗
That is, in programs Dec, RFake we puncture decryption key DK of the main ACE at the same point
p = (1 ⊕ m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ). Indistinguishability holds by security of constrained key of ACE, since
the corresponding encryption key EK is already punctured at this point.
Now µ3 ∗ = ACE.EncEK (1 ⊕ m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ) is rejected by Dec and RFake. In the following hybrids,
similarly to previous lemma, we switch the roles of r∗ and r0 , using the fact that programs treat them similarly,
once µ3 ∗ is eliminated37 .
37
The problem with µ3 ∗ is that unmodified Dec on input (r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ) outputs 1 ⊕ m∗1 (via main step), and on input
(r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ) it outputs 0 fail0 (via trapdoor step, since levels in r0 and µ3 ∗ are both 0 and “isLess = true” check fails. Because
of this difference, in HybB,2,1 we wouldn’t be able to modify program Dec such that the code treats r∗ and r0 in the same way.
However, after HybB,1,6 µ3 ∗ is not a valid ciphertext anymore and thus in HybB,2,1 we can instruct Dec to output 0 fail0 on both r∗
and r0 .
250
Setup(1λ ; P1B,3 , P2B,2 , P3B,3 , DecB,2 , SFakeB,3 , RFakeB,2 ; rSetup ) for randomly chosen rSetup ; r∗ is
That is, we modify programs of the receiver (P2, Dec, RFake) by puncturing encryption key of receiver-
fake ACE EKR {p} at the point p = (m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , ρ̂∗ ), decryption key of receiver-fake ACE
DKR {r∗ , r0 } at r∗ and r0 (where r0 = ACE.EncEKR (p)), and the key kR of extracting PRF RG of the
receiver at the points (r∗ , µ1 ∗ ) and (r0 , µ1 ∗ ). In addition, we hardwire certain outputs inside programs
of the receiver to make sure that functionality of the programs doesn’t change. Indistinguishability
holds by iO.
λ
Setup(1 ; P1B,3 , P2B,2 , P3B,3 , DecB,2 , SFakeB,3 , RFakeB,2 ; rSetup ) for randomly chosen
rSetup ; r∗ is chosen at random, µ1 ∗ is chosen at random, µ2 ∗ is chosen at random,
µ3 ∗ = ACE.EncEK (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ), s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ). Programs
can be found in fig. 123 (programs of the sender) and fig. 125 (programs of the receiver).
That is, we choose µ2 ∗ at random instead of computing it as µ2 ∗ = RGkS (r∗ , µ1 ∗ ). Indistinguishability
holds by pseudorandomness of the PRF SG at the punctured point (r∗ , µ1 ∗ ).
λ
sen rSetup ; r∗ is chosen at random, µ1 ∗ is chosen at random, µ2 ∗ is chosen at ran-
dom, µ3 ∗ = ACE.EncEK (m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ), s0 = ACE.EncEKS (m∗0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , `∗1 ),
r0 = ACE.EncEKR (m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , ρ̂∗ ) for randomly chosen ρ̂∗ . Programs can be found in fig.
123 (programs of the sender) and fig. 125 (programs of the receiver).
That is, we switch the roles of r∗ and r0 everywhere in the distribution: namely, we give r0 (instead
of r∗ ) to the adversary as randomness of the receiver, and we change r∗ to r0 and r0 to r∗ everywhere
in the programs. Note that this doesn’t change the code of the programs since programs use r∗ and
r0 in the same way. Indistinguishability holds by the symmetry of receiver-fake ACE, which says
that (r∗ , r0 , EKR {p}, DKR {r∗ , r0 }) is indistinguishable from (r0 , r∗ , EKR {p}, DKR {r0 , r∗ }), where
p = (m∗1 , µ1 ∗ , µ2 ∗ , µ3 ∗ , L∗0 , ρ̂∗ ), r∗ is randomly chosen, r0 = ACE.EncEKR (p).
λ

receiver).
holds by pseudorandomness of the PRF RG at the punctured point (r∗ , µ1 ∗ ).
λ

251
receiver).
That is, we revert all changes we made to programs in HybB,2,1 and thus use original programs
P2, Dec, RFake, except that DK remains punctured at the point p = (1 ⊕ m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ). Indis-
tinguishability holds by iO, since we remove puncturing without changing the functionality of the
programs.
λ
sen rSetup ; s∗ , r∗ are chosen at random, µ1 ∗ = SGkS (s∗ , m∗1 ), µ2 ∗ = RG(r∗ , µ1 ∗ ),
That is, we replace randomly chosen ρ̂∗ with prg(ρ∗ ) for randomly chosen ρ∗ , when generating r0 .
Indistinguishability holds by security of a prg.
Finally, in the following hybrids we revert all changes we made in hybrids HybB,1,1 - HybB,1,6 , thus restoring
all programs (and making µ3 ∗ a valid ciphertext):
Setup(1 ; P1B,3 , P2, P3B,3 , Dec, SFakeB,3 , RFake; rSetup ) for randomly chosen rSetup ; r∗
λ
is chosen at random, chosen at random, µ1 ∗ is chosen at random, µ2 ∗ = RG(r∗ , µ1 ∗ ),

p = (1 ⊕ m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ). Indistinguishability holds by security of constrained key of ACE, since
the corresponding encryption key EK is punctured at this point.
λ
Setup(1 ; P1B,2 , P2, P3B,2 , Dec, SFakeB,2 , RFake; rSetup ) for randomly chosen rSetup ; r is chosen∗

of the receiver).
That is, in program P3 we unpuncture encryption key EK of the main ACE at the point p = (1 ⊕
m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ). Indistinguishability holds by iO, because of the same reason as in HybB,1,5 .
λ ∗

of the receiver).
That is, we choose µ1 ∗ as µ1 ∗ = SGkS (s∗ , m∗1 ) instead of computing it at random. Indistinguishability
252
the distribution).
λ ∗

of the receiver).
same set P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}. Indistinguishability holds by security of constrained key of ACE,
since the corresponding encryption key EKS is already punctured at the same set.
λ

of the receiver).
P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}. Indistinguishability holds by iO, since this modification doesn’t change the
functionality of SFake due to the fact that SFake never encrypts plaintexts with level `∗0 .
Note that HybB,3,5 is the same as HybC , conditioned on the fact that s∗ , r∗ are outside of image of
ACE.
253
1. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
2. Main step:
decryption key DKS {P`∗0 } of sender-fake ACE, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}, punctured encryption key
EK{p} of main ACE, where p = (1 ⊕ m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ).
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(c) If m, µ1 = m0 , µ1 0 then:
iii. Return µ3 ← ACE.EncEK{p} (m, µ1 , µ2 , L);
3. Main step:
(b) Return µ3 ← ACE.EncEK{p} (m, µ1 , µ2 , L0 ).
Hardwired values: obfuscated code of algorithms P1B,3 , GenZero, Increment; punctured encryption and
decryption keys EKS {P`∗0 }, DKS {P`∗0 } of sender-fake ACE, where P`∗0 = {(∗, ∗, ∗, ∗, `∗0 )}.
2. Trapdoor step:
0
(m0 , µ1 0 , µ2 0 , µ3 0 , `0 );
(b) If m, µ1 = m0 , µ1 0 then
0
3. Main step:
0
Figure 123: Programs P1B,3 , P3B,3 , SFakeB,3 , used in the proof indistinguishability of explanations of the
receiver for off-the-record deniability.
254
1. Trapdoor step:
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
2. Main step:
fake ACE, punctured decryption key DK{p} of the main ACE, where p = (1 ⊕ m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ).
2. Trapdoor step:
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
(c) out ← ACE.DecDK{p} (µ3 ); if out00 = 0 fail0 then abort, else parse out00 as (m00 , µ1 00 , µ2 00 , L00 );
(d) If µ1 , µ2 = µ1 0 , µ2 0 then
ii. Else abort.
3. Main step:
(c) Else abort.
Hardwired values: encryption key EKR of receiver-fake ACE, punctured decryption key DK{p} of the main
ACE, where p = (1 ⊕ m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ).
255
Hardwired values: punctured decryption key DKR {r∗ , r0 } of receiver-fake ACE, punctured key
kR {(r∗ , µ1 ∗ ), (r0 , µ1 ∗ )} of an extracting PRF RG, variables r∗ , r0 , µ1 ∗ , µ2 ∗ .
1. Trapdoor step:
(a) If (r, µ1 ) = (r∗ , µ1 ∗ ) or (r, µ1 ) = (r0 , µ1 ∗ ) then return µ2 ∗ ;
(b) If r = r∗ or r = r0 then goto main step;
(c) out ← ACE.DecDKR {r∗ ,r0 } (r); if out = 0 fail0 then goto main step, else parse out as
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
(d) If µ1 = µ1 0 then return µ2 0 ;
2. Main step:
(a) Return µ2 ← RGkR {(r∗ ,µ1 ∗ ),(r0 ,µ1 ∗ )} (r, µ1 ).
Hardwired values: obfuscated code of algorithms P2B,2 , isLess, RetrieveTags; punctured decryption
key DKR {r∗ , r0 } of receiver-fake ACE, punctured decryption key DK{p} of the main ACE, where p =
(1 ⊕ m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ), variables r∗ , r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ , m∗1 .
1. Validity check: if P2B,2 (r, µ1 ) 6= µ2 then abort;
2. Trapdoor step:
(a) If (r, µ1 , µ2 , µ3 ) = (r∗ , µ1 ∗ , µ2 ∗ , µ3 ∗ ) or (r, µ1 , µ2 , µ3 ) = (r0 , µ1 ∗ , µ2 ∗ , µ3 ∗ ) then return m∗1 ;
(b) If (r, µ1 , µ2 ) = (r∗ , µ1 ∗ , µ2 ∗ ) or (r, µ1 , µ2 ) = (r0 , µ1 ∗ , µ2 ∗ ) then then goto main step;
(c) If r = r∗ or r = r0 then goto main step;
(d) out ← ACE.DecDKR {r∗ ,r0 } (r); if out0 = 0 fail0 then goto main step; else parse out0 as
(m0 , µ1 0 , µ2 0 , µ3 0 , L0 , ρ̂);
(e) if µ1 , µ2 , µ3 = µ1 0 , µ2 0 , µ3 0 then return m0 ;
(f) out ← ACE.DecDK{p} (µ3 ); if out00 = 0 fail0 then abort, else parse out00 as (m00 , µ1 00 , µ2 00 , L00 );
(g) If µ1 , µ2 = µ1 0 , µ2 0 then
ii. Else abort.
3. Main step:
(c) Else abort.
Hardwired values: punctured encryption key EKR {Sρ̂∗ } of receiver-fake ACE, where Sρ̂∗ =
{∗, ∗, ∗, ∗, ∗, ρ̂∗ } for randomly chosen ρ̂∗ , punctured decryption key DK{p} of the main ACE, where
p = (1 ⊕ m∗1 , µ1 ∗ , µ2 ∗ , L∗0 ).
2. Return r0 ← ACE.EncEKR {Sρ̂∗ } (m̂, µ1 , µ2 , µ3 , L00 , prg(ρ)).
256
Acknowledgements
RC is a member of the Check Point Institute for Information Security. Supported by the NSF MACS project.
SP’s research is supported by the MIT Media Lab’s Digital Currency Initiative and its funders, and earlier,
was supported by the following grants: NSF MACS (CNS-1413920), DARPA IBM (W911NF-15-C-0236),
Simons Investigator award agreement dated June 5th, 2012, and the Center for Science of Information (CSoI),
an NSF Science & Technology Center, under grant agreement CCF-0939370.
References
[AFL16] Daniel Apon, Xiong Fan, and Feng-Hao Liu. Deniable attribute based encryption for branching
programs from LWE. In Theory of Cryptography - 14th International Conference, TCC 2016-B,
Beijing, China, October 31 - November 3, 2016, Proceedings, Part II, pages 299–329, 2016. 9,
259, 260
[BCG+ 18] Nir Bitansky, Ran Canetti, Sanjam Garg, Justin Holmgren, Abhishek Jain, Huijia Lin, Rafael
Pass, Sidharth Telang, and Vinod Vaikuntanathan. Indistinguishability obfuscation for RAM
programs and succinct randomized encodings. SIAM J. Comput., 47(3):1123–1210, 2018. 50,
51
[BCP14] Elette Boyle, Kai-Min Chung, and Rafael Pass. On extractability obfuscation. In Theory of
Cryptography - 11th Theory of Cryptography Conference, TCC 2014, San Diego, CA, USA,
February 24-26, 2014. Proceedings, pages 52–73, 2014. 42, 102, 104, 265
[BGB04] Nikita Borisov, Ian Goldberg, and Eric A. Brewer. Off-the-record communication, or, why not
to use PGP. In Vijay Atluri, Paul F. Syverson, and Sabrina De Capitani di Vimercati, editors,
Proceedings of the 2004 ACM Workshop on Privacy in the Electronic Society, WPES 2004,
Washington, DC, USA, October 28, 2004, pages 77–84. ACM, 2004. 2
[BNNO11] Rikke Bendlin, Jesper Buus Nielsen, Peter Sebastian Nordholt, and Claudio Orlandi. Lower and
upper bounds for deniable public-key encryption. In Advances in Cryptology - ASIACRYPT 2011
- 17th International Conference on the Theory and Application of Cryptology and Information
Security, Seoul, South Korea, December 4-8, 2011. Proceedings, pages 125–142, 2011. 1, 5, 9,
10, 11, 12, 13, 15, 259
[BPR15] Nir Bitansky, Omer Paneth, and Alon Rosen. On the cryptographic hardness of finding a nash
equilibrium. Electronic Colloquium on Computational Complexity (ECCC), 22:1, 2015. 3, 7,
42, 73, 74
[BPW16] Nir Bitansky, Omer Paneth, and Daniel Wichs. Perfect structure on the edge of chaos -
trapdoor permutations from indistinguishability obfuscation. In Theory of Cryptography - 13th
International Conference, TCC 2016-A, Tel Aviv, Israel, January 10-13, 2016, Proceedings,
Part I, pages 474–502, 2016. 3, 59
[CDMW09] Seung Geol Choi, Dana Dachman-Soled, Tal Malkin, and Hoeteck Wee. Improved non-
committing encryption with applications to adaptively secure protocols. In Advances in Cryp-
tology - ASIACRYPT 2009, 15th International Conference on the Theory and Application of
Cryptology and Information Security, Tokyo, Japan, December 6-10, 2009. Proceedings, pages
287–302, 2009. 9
257
[CDNO96] Ran Canetti, Cynthia Dwork, Moni Naor, and Rafail Ostrovsky. Deniable encryption. IACR
Cryptology ePrint Archive, 1996:2, 1996. 1, 2, 9, 10, 259
[CFGN96] Ran Canetti, Uriel Feige, Oded Goldreich, and Moni Naor. Adaptively secure multi-party
computation. In Proceedings of the Twenty-Eighth Annual ACM Symposium on the Theory of
Computing, Philadelphia, Pennsylvania, USA, May 22-24, 1996, pages 639–648, 1996. 9
[CHJV14] Ran Canetti, Justin Holmgren, Abhishek Jain, and Vinod Vaikuntanathan. Indistinguishability
obfuscation of iterated circuits and RAM programs. IACR Cryptology ePrint Archive, 2014:769,
2014. 3, 7, 22, 50, 51, 53, 60, 261, 262, 263, 265
[CHK+ 08] Alexei Czeskis, David J. St. Hilaire, Karl Koscher, Steven D. Gribble, Tadayoshi Kohno, and
Bruce Schneier. Defeating encrypted and deniable file systems: Truecrypt v5.1a and the case of
the tattling OS and applications. In 3rd USENIX Workshop on Hot Topics in Security, HotSec’08,
San Jose, CA, USA, July 29, 2008, Proceedings, 2008. 260
[CIO16] Angelo De Caro, Vincenzo Iovino, and Adam O’Neill. Deniable functional encryption. In
Public-Key Cryptography - PKC 2016 - 19th IACR International Conference on Practice and
Theory in Public-Key Cryptography, Taipei, Taiwan, March 6-9, 2016, Proceedings, Part I,
pages 196–222, 2016. 9, 259, 260
[CPR17] Ran Canetti, Oxana Poburinnaya, and Mariana Raykova. Optimal-rate non-committing encryp-
tion. In Advances in Cryptology - ASIACRYPT 2017 - 23rd International Conference on the
Theory and Applications of Cryptology and Information Security, Hong Kong, China, December
3-7, 2017, Proceedings, Part III, pages 212–241, 2017. 49, 50
[Dac12] Dana Dachman-Soled. On the impossibility of sender-deniable public key encryption. IACR
Cryptology ePrint Archive, 2012:727, 2012. 9, 10, 259
[DH76] Whitfield Diffie and Martin E. Hellman. New directions in cryptography. IEEE Trans. Informa-
tion Theory, 22(6):644–654, 1976. 1
[DKSW09] Yevgeniy Dodis, Jonathan Katz, Adam D. Smith, and Shabsi Walfish. Composability and
on-line deniability of authentication. In Theory of Cryptography, 6th Theory of Cryptography
Conference, TCC 2009, San Francisco, CA, USA, March 15-17, 2009. Proceedings, pages
146–162, 2009. 9
[GGM84] Oded Goldreich, Shafi Goldwasser, and Silvio Micali. On the cryptographic applications of
random functions. In Advances in Cryptology, Proceedings of CRYPTO ’84, Santa Barbara,
California, USA, August 19-22, 1984, Proceedings, pages 276–288, 1984. 49
[GKW17] Shafi Goldwasser, Saleet Klein, and Daniel Wichs. The edited truth. In Theory of Cryptography
- 15th International Conference, TCC 2017, Baltimore, MD, USA, November 12-15, 2017,
Proceedings, Part I, pages 305–340, 2017. 9, 259, 260
[GM84] Shafi Goldwasser and Silvio Micali. Probabilistic encryption. J. Comput. Syst. Sci., 28(2):270–
299, 1984. 1
[GPS16] Sanjam Garg, Omkant Pandey, and Akshayaram Srinivasan. Revisiting the cryptographic
hardness of finding a nash equilibrium. In Advances in Cryptology - CRYPTO 2016 - 36th
Annual International Cryptology Conference, Santa Barbara, CA, USA, August 14-18, 2016,
Proceedings, Part II, pages 579–604, 2016. 50, 263
258
[IKOS10] Yuval Ishai, Abishek Kumarasubramanian, Claudio Orlandi, and Amit Sahai. On invertible
sampling and adaptive security. In Advances in Cryptology - ASIACRYPT 2010 - 16th Inter-
national Conference on the Theory and Application of Cryptology and Information Security,
Singapore, December 5-9, 2010. Proceedings, pages 466–482, 2010. 8
[KLW15] Venkata Koppula, Allison Bishop Lewko, and Brent Waters. Indistinguishability obfuscation
for turing machines with unbounded memory. In Proceedings of the Forty-Seventh Annual ACM
on Symposium on Theory of Computing, STOC 2015, Portland, OR, USA, June 14-17, 2015,
pages 419–428, 2015. 3
[Nie02] Jesper Buus Nielsen. Separating random oracle proofs from complexity theoretic proofs: The
non-committing encryption case. In Advances in Cryptology - CRYPTO 2002, 22nd Annual
International Cryptology Conference, Santa Barbara, California, USA, August 18-22, 2002,
Proceedings, pages 111–126, 2002. 10
[OPW11] Adam O’Neill, Chris Peikert, and Brent Waters. Bi-deniable public-key encryption. In Advances
in Cryptology - CRYPTO 2011 - 31st Annual Cryptology Conference, Santa Barbara, CA, USA,
August 14-18, 2011. Proceedings, pages 525–542, 2011. 2, 8, 9, 259, 260, 261
[RSA78] Ronald L. Rivest, Adi Shamir, and Leonard M. Adleman. A method for obtaining digital
signatures and public-key cryptosystems. Commun. ACM, 21(2):120–126, 1978. 1
[SW14] Amit Sahai and Brent Waters. How to use indistinguishability obfuscation: deniable encryption,
and more. In Symposium on Theory of Computing, STOC 2014, New York, NY, USA, May 31 -
June 03, 2014, pages 475–484, 2014. 1, 4, 5, 6, 7, 8, 9, 10, 11, 13, 20, 49, 59, 60, 65, 224, 225,
231, 232, 260, 263
A On Flexible Deniability: Discussion

This weaker notion of deniability [CDNO96, OPW11, BNNO11, Dac12, AFL16, CIO16, GKW17], some-
times called flexible deniability, multi-distributional deniability or dual-scheme deniability postulates two
schemes, S and S 0 , where S is “deniable with respect to S 0 ”. When applied to sender-deniability, the
requirement is roughly as follows: The sender can use scheme S to encrypt plaintext m with random string
r to obtain ciphertext c, and then can present an appropriate fake random string r̃ such that c is obtained
as an encryption of m0 6= m with randomness r̃, but under the scheme S 0 . In other words, this security
property assumes that the adversary doesn’t know which scheme was used by the sender, S or S 0 , and that the
adversary is willing to believe the sender who claims to have used the non-deniable version. Another way to
look at flexible schemes is to say that S is a “trapdoored” version of S 0 , i.e. when parties generate a ciphertext
according to deniable scheme S, they additionally generate a faking trapdoor which is required to compute
fake randomness; in constrast, in S 0 no such trapdoor is generated. Deniability holds only as long as this
trapdoor remains secret; upon coercion, the parties claim that they never generated a trapdoor to begin with.
In contrast, in the standard definition of deniable encryption [CDNO96] the adversary is fully aware of the
fact that the sender is using a deniable algorithm, and thus has the right to demand to see any potential “faking
trapdoors” or any information which may be required for generating fake randomness.
On a positive side, flexibly deniable encryption already guarantees plausible deniability, since the coercer
cannot prove that S was used - even though it may have reasons to believe so. Thus, flexible deniability
already protects parties in many scenarios where plausible deniability suffices, e.g. in court. Another benefit
259
of flexible schemes is their efficiency: unlike fully deniable schemes (including this work and [SW14]) which,
to date, are only known from obfuscatoin, known flexibly deniable schemes can be implemented in practice.
Flexible deniability, due to having a weaker security guarantee, allows for fewer rounds, more efficiency,
and weaker assumptions than fully deniable schemes, and requires no setup. For instance, [OPW11] build a
2-message flexibly bideniable encryption from LWE and from simulatable encryption. In fact we even have
more advanced encryption schemes (like identity-based encryption [OPW11], functional encryption [CIO16],
and attribute-based encryption ([AFL16])) with flexible deniability, and we have flexibly deniable encryption
scheme with succinct keys [GKW17], where the size of a key is proportional to the number of possible fake
messages (which can be smaller than the total number of possible plaintexts).
However, flexible notion of deniability has significant drawbacks. Indeed, having two different algorithms,
which have two different security guarantees and which are up to the parties to choose, leaves room for
suspicion, misuse, and can even cause harm to parties themselves. It also requires additional coordination
between parties. But most importantly, flexible deniability doesn’t provide perhaps the most desirable benefit
of deniability - preventing coercion in the first place by making it useless. Below we explain these issues in
more detail.
First, refusal to provide keys for deniable version could significantly increase the adversary’s certainty that
parties are lying - compared to the ideal channels case where the coercer has nothing besides parties’ claims.
Indeed, in the real world the opinion of the coercer will be shifted by its certainty that deniable version was
used. However, this is not captured by security definition of flexible deniability, which doesn’t take into
account how exactly parties choose an algorithm, e.g. by assuming some distribution on the choices of S
and S 0 , or considering rational behavior. For instance, one could argue that rational players would prefer S
over S 0 because of better security guarantees, which is further aggravated by the fact that flexible deniability
could actually harm those who use the non-deniable version. Indeed, as [CHK+ 08], who analyze plausible
deniability of TrueCrypt hidden volume, put it, “deniability cuts both ways, and sometimes that’s not a
benefit”.
Second, note that fully deniable encryption doesn’t allow parties to prove what their plaintext was even if they
want to38 . This is crucial in preventing bribery or vote selling. In contrast, in flexibly deniable encryption
parties can choose whether they want it or not by choosing deniable or non-deniable algorithm. As a result,
with fully deniable encryption one could set up receipt-free voting scheme using a physical booth which, for
instance, provides parties with randomness (so that they can still lie about their vote, but cannot use preset
randomness to sell their vote). But if flexible scheme is used, then voters can lie about their vote but at the
same time sell their true vote if they want (if deniable version is used), or can do neither (if non-deniable
version is used).
Another important issue which arises in flexible setting is the need for coordination. That is, parties need a
way to agree whether they run S or S 0 , and do so by the time of encryption39 . It is not clear how to do such
coordination without another deniable channel. As a result, well-being of each party is in the other party’s
hands: e.g. the sender’s claim will look credible only as long as the receiver also used deniable algorithm
at time of encryption, also decided to fake at time of coercion, and used the same fake plaintext. This is a
problem not only when the receiver turns against the sender, but also when the receiver remains honest but
doesn’t know what actions to take out of lack of coordination.
38
As discussed before, this property only holds if parties execute the protocol correctly.
39
However coordination is not required for correctness and semantic security, since these properties hold even if the sender and
the receiver use different schemes [OPW11].
260
Finally and most importantly, as already pointed out by [OPW11], deniable encryption not only allows to
withstand coercion, but also makes in useless in the first place - just like it is useless in the ideal world, where
there is no way of verifying parties’ claims. However, flexible deniability doesn’t give this guarantee: the
coercer (who suspects that deniable version could be used) can gradually increase the pressure - be it a sum
of money or “enhanced interrogation” - until the parties find it more preferable to prove what their plaintext
was by disclosing keys of deniable version, S.
To summarize this discussion, we think that flexible deniability as a real-life application already suffices in
many cases - e.g. when plausible deniability is sufficient, or when the coercer is not aware of the concept of
deniable encryption and will be satisfied by seeing some working key. However, to obtain security guarantees
of the ideal channel, one should use encryption which is (fully) deniable and off-the-record deniable.
Needless to say, we still believe that flexible deniability is a fascinating concept to explore. For instance,
coming up with flexible scheme where S 0 is some standard encryption, e.g. RSA, would mitigate some issues
mentioned above, thus making flexible deniability as good as full deniability for many practical purposes.
Further, flexibly deniable encryption is an interesting primitive whose connections to non-committing
encryption and full deniability are yet to be explored.
B On removing layers of obfuscation

When our construction described in section 6 is instantiated with ACE from [CHJV14], relaxed ACE described
in section C, and the level system described in section 7 (which in turn uses ACE of [CHJV14]), the resulting
CRS ends up containing three layers of obfuscation. Since even a single obfuscation incurs a significant
blowup in the program size, ideally we would like to have only one layer of obfuscation.
In this section we explain why the whole proof of bideniability and off-the-record deniability can still go
through, if we use non-obfuscated version and “unroll” all the proofs. More concretely, we do the following:
• Instead of using ACE keys and the programs of the level system, which are all obfuscated programs,
we use their non-obfuscated versions. Still, we use one layer of obfuscation on top of programs of
deniable encryption. We pad the size of the non-obfuscated programs of deniable encryption to size σ
such that σ is larger than the size of any (non-obfuscated) program (including programs variants in the
hybrids) of deniable encryption, ACE, relaxed ACE, or the level system.
• In the proof we replace each hybrid reducing to security of any of ACE, relaxed ACE, or the level
system with a sequence of hybrids proving the corresponding property of the primitive.
Now we briefly comment on why each security reduction can still be proven. Let program C1 of a primitive
∆1 , and program C2 of a primitive ∆2 be such that C1 uses an obfuscated version of C2 , i.e. iO(C2 ), as a
black box (e.g. ∆1 can be deniable encryption and ∆2 can be relaxed ACE, ACE or the level system, or ∆1
can be the level system and ∆2 can be ACE). We denote this by C1 [iO(C2 )]. Further, let C1 [C2 ] be program
C1 which uses program C2 , instead of iO(C2 ). Note that this is syntactically well-defined since C1 uses
iO(C2 ) as a black box and since iO(C2 ) and C2 have the same syntax.
Further, let all reductions in the security proof of ∆1 use iO(C2 ) as a black box. We claim that the “unrThen
all reductions in security proofs of deniable encryption, ACE, relaxed ACE, and the level system can be
classified as follows:
Reductions in the proof of security of ∆1 :
261
• Reductions which rely on security of ∆2 : we replace each reduction with a sequence of reductions
from the proof of ∆2 , and as we argue later, they all still can be proven.
• Reductions which do not rely on security of ∆2 , but which use the fact that iO(C2 ) has a certain
functionality (e.g. an iO-based reduction, which uses the fact that the functionality of C1 in the two
consecutive hybrids doesn’t change, and analyzes functionality of iO(C2 ) as part of the argument). We
claim that if such a reduction is possible with C1 [iO(C2 )], then it is also possible with C1 [C2 ]. This is
because iO preserves the functionality with all-but-negligible probability over the randomness of iO.
• All other reductions: these reductions merely use the fact that in the reduction it is possible to
reconstruct iO(C2 ) in polynomial time. Note that this is true for C2 as well, thus such reductions still
go through.
Reductions in the proof of security of ∆2
• Reductions to security of obfuscation for a program C2 , relying on the fact that C2 has the same
functionality in the two consecutive hybrids: we claim that we can instead reduce to security of
obfuscation for a program iO(C1 [C2 ]). Indeed, since C1 uses iO(C2 ) as a black box, and since iO
preserves functionality except for negligible probability over the choice of randomness of iO, C1 [C2 ]
also has the same functionality in those two hybrids. Thus, as long as we pad the program C1 [C2 ]
sufficiently, the reduction to security of iO still holds.
• Reductions which rely on the fact that in some cases iO allows to extract a differing input of programs
C20 , C200 , given iO(C20 ), iO(C200 ). We argue that security of there hybrids can still be reduced to security
of iO and one-way functions, even though the resulting programs C1 [C20 ] and C1 [C200 ] can be different
on exponentially many inputs. Recall that those security reductions work by constructing a circuit
M2 such that M2 is the same as C20 or C200 , and use it do to binary search over a differing value, which
could be an input, or part of an input, or some intermediate variable in the program. But this means
that the reduction in the “unrolled” proof can do the same binary search, over the same differing value,
by using program M1 = C1 [M2 ], which can be constructed using iO(C1 [C20 ]), iO(C1 [C200 ]): indeed,
since M2 is the same as either C20 or C200 , C1 [M2 ] is the same as either C1 [C20 ] or C1 [C200 ].
• All other reductions: in such reductions we need to make sure that the reduction can reconstruct the
whole distribution, which now includes an obfuscated program iO(C1 [C2 ]), together with any values
the adversary is supposed to get as part of the game for primitive ∆1 . We note that this can be done:
since it was possible to do in the reduction (of the proof for ∆1 ) to security of ∆2 , it should be possible
as well for every hybrid in security proof of ∆2 , since otherwise the reduction of the proof of ∆1 can
be used as a distinguisher for ∆2 . Indeed, since the reduction uses iO(C2 ) as a black box, we can
replace iO(C2 ) with C2 and the reduction still succeeds.
C Construction of relaxed ACE

In this section we describe how to modify the construction of ACE from [CHJV14] to obtain relaxed ACE (def.
9). Recall that the differences between ACE and relaxed ACE are that relaxed ACE doesn’t necessarily satisfy
indistinguishability of ciphertexts; that its distinguishing advantage in security of constrained decryption game
is negligible for certain sets (as opposed to being proportional to size of those sets); and that it additionally
satisfies symmetry.
Brief motivation and explanation of the construction. The first attempt to remove dependency on the size
262
of the sets is perhaps to use the technique from [GPS16] - that is, instead of having a single PRF-based
signature on the plaintext m, have |m| signatures of each prefix of m. This allows to change the key on
many inputs (with the same prefix) in a single step. However, with this approach we are not able to prove
symmetry: it requires to switch c∗ = Enc(m∗ ) to random and thus to puncture all keys for each PRF; however,
such puncturing cannot be done without changing the functionality of the encryption program, since e.g.
puncturing the PRF which is applied on the first bit already prohibits encrypting of half of all inputs.
To deal with this, we notice that in the proof of deniable encryption we use security of relaxed ACE on sets of
special structure, which is either all strings ending with the same suffix of a fixed size, or all such strings
except one. Thus we require relaxed ACE to be parametrized with prefix parameter t, which denotes the size
of this prefix. 40 An encryption of m will be an ACE ciphertext where instead of a single PRF signature of m,
we will have n − t + 1 PRF signatures of suffixt (m), . . . , suffixn (m). We say that a set S is consistent with
some suffix suf of size t, if S consists of all strings ending with suf; we say that a plaintext m is consistent
with suf, if m ends with suf. Using n − t + 1 signatures allows us to prove the following:
• symmetry for random c∗ and c0 = Enc(m∗ ), as long as encryption key is punctured at the set S, and
both S and m∗ are consistent with the same suffix suf of size t;
• security of constrained decryption with distinguishing advantage independent of set sizes, as long as
S1 \ S0 is either Ssuf (e.g. a set consistent with some suf of size t), or Ssuf \ {m}, where both S and
m are consistent with the same suf of size t.
Security of constrained decryption follows a by-now standard proof, which punctures the key at the whole
set Ssuf i at once (for each i = t + 1, . . . , n), by adding an injective prg on top of a signature check and
then switching the prg image to random (in the actual proof we instead use an injective OWF to minimize
assumptions). For the case S1 \ S0 = Ssuf it is enough to do one step, and for the case S1 \ S0 = Ssuf \ {m}
we need n − t steps.41
Symmetry argument is essentially a Sahai-Waters [SW14] symmetry argument in the proof of deniable
encryption, with a difference that they didn’t use ACE as an abstraction, and we instead decided to formulate
it on ACE level to shorten the main proof of deniable encryption. The proof follows essentially the same
steps, except that, since we have more signatures, we also need to argue that in the proof the decryption key
can be punctured at a certain set of points (this is done using an argument similar to the proof of security
of constrained decryption, since encryption key is already punctured on those points). Indeed, the proof of
[SW14] uses the fact that the (only) signature uniquely defines the plaintext. This is not true in our case
anymore, since some signatures only define the corresponding prefix of the plaintext. This introduces “bad”
plaintexts which we need to get rid of. To do this, we rely on the fact that S \ {m∗ } can be represented as a
union of Ssuf i , where all suf i are different from suffixes of m∗ .
Construction of relaxed ACE. The construction of relaxed ACE is the same as the construction of ACE
from [CHJV14], except that we use different programs. Namely, let Ft , . . . , Fn be injective PRFs with sparse
images, mapping t, . . . , n bits, respectively, to nout = O(λ) bits. Let F be a PRF mapping nout bits to O(λ)
bits. Then a (possibly punctured) encryption key is obfuscated GEnc (m), a (possibly punctured) decryption
key is obfuscated GDec (m), and a ciphertext-based punctured key is obfuscated GPuncture (c)[c(0) , c(1) ], where
one of c(0) , c(1) is a valid ciphertext and the other is randomly chosen. Programs can be found on fig. 126.
40
In the construction of deniable encryption, t = |`0 | for the sender ACE and t = |prg(ρ)| for the receiver ACE.
41
We write S0 , S1 (sets to puncture keys at in the security game) and Ssuf (a set denoting all strings ending with suf), somewhat
abusing the notation, since the subscript means an index in the former case and a prefix in the latter. However, all our suffixes are of
length at least t, so there should be no confusion.
263
Programs of relaxed ACE.
Program GEnc (m)
Inputs: message m.
Hardwired values: keys Kt , . . . , Kn , K of PRFs Ft , . . . , Fn , F ; circuit CU describing set U . Parameters
t, n.
1. If CU (m) then return ⊥;
2. For each i = t, . . . , n set αi ← Fi (Ki ; suffixi (m));
3. Set β ← F (K; αn ) ⊕ m;
4. Return (αt , . . . , αn , β).
Program GDec (c)
Inputs: ciphertext c.
Hardwired values: keys Kt , . . . , Kn , K of PRFs Ft , . . . , Fn , F ; circuit CS . Parameters t, n.
1. Parse c = (αt , . . . , αn , β);
2. Set m ← F (K; αn ) ⊕ β
3. If CS (m) then return ⊥;
4. For each i = t, . . . , n do: if αi 6= Fi (Ki ; suffixi (m)) then return ⊥;
5. Return m.
Program GPuncture (c)
Hardwired values: keys Kt , . . . , Kn , K of PRFs Ft , . . . , Fn , F . In addition, strings c(0) and c(1) , hardwired
in lexicographic order. Parameters t, n.
1. If c = c(0) or c = c(1) then return ⊥; (c(0) and c(1) are written in lexicographic order)
2. Parse c = (αt , . . . , αn , β);
3. Set m ← F (K; αn ) ⊕ β
5. Return m.
Figure 126: Programs of constrained keys of relaxed ACE. By suffixi (m) we denote mn−i+1 , . . . , mn .
264
Theorem 4. Assuming iO and injective one way functions, the construction of [CHJV14] instantiated with
programs on fig. 126 is a relaxed ACE for plaintext length n and suffix parameter t. Concretely, assuming
o(1)
iO is (t1 , ε1 )-secure and one way function is (t2 , ε2 )-secure, and let (t3 , ε3 ) be such that ε3 ≥ ε1 , and
t3 · ε11 (n − t) = O(t2 ).
Then the resulting ACE is (min(t1 , t3 ), O((n − t) · (ε1 + ε2 + ε)))-secure.
Proof. Correctness. All necessary correctness properties follow from correctness of iO, injectivity of PRFs
and can be immediately verified.
Security of constrained decryption with negligible advantage. We prove security for a harder case of
S1 \ S0 = Ssuf t \ {m∗ } (the case when S1 \ S0 = Ssuf t can be shown by doing a single step of this proof
for the PRF Ft ). Note that S1 \ S0 = Ssuf t \ {m∗ } can be represented as Ssuf n ∪ . . . ∪ Ssuf t+1 , where
suf n = m∗1 , m∗2 , . . . , m∗n , suf n−1 = m∗2 , m∗3 , . . . , m∗n , suf t+1 = m∗n−t+1 , m∗n−t+2 , . . . , m∗n .
We start with a distribution corresponding to the key DK which is punctured at S0 (which we denote by
Hyb0 ) and eventially reach a distribution where the key DK is punctured at S1 (which we denote by Hybn,5 ).
We show indistinguishability via a sequence of hybrids Hybj,k for j = t + 1, . . . , n, k = 0, . . . , 5. Programs
can be found on fig. 127:
• Hyb0 corresponds to the game where DK is punctured at S0 , i.e. the adversary gets
(EK{U }, DK{S0 }).
j,0
• Hybj,0 : the adversary gets (EK{U }, DK j,0 ), where DKi is an obfuscation of a program GDec (fig.
127). Note that when j = t + 1, Hybj,0 = Hyb0 .
j,1
• Hybj,1 : the adversary gets (EK j,1 , DK j,1 ), where DK j,1 is an obfuscation of a program GDec , where
∗ j,1 j,1
z = Fj (Kj ; suf j )), and EK is an obfuscation of GEnc . Indistinguishability from the previous
j,0
hybrid follows from iO, since both pairs of programs have the same functionality. Indeed, in GDec
j,1
and GDec we replaced the condition αj = Fj (Kj ; suffixj (m)) with two different checks for the case
suffixj (m) 6= suf j and suffixj (m) = suf j . For the former, we didn’t change the check (but punctured
the key Kj at suf j ), and for the latter, we replaced the check αj = Fj (Kj ; suf j ) with the check
g(αj ) = z ∗ , where z ∗ = g(Fj (Kj ; suf j )). Since g is injective, this doesn’t change the functionality.
j,1
In GEnc we punctured the key Kj at suf j . This is without changing the functionality, since the program
outputs ⊥ on input m ∈ Ssuf j ⊂ U .
j,1
∗ ∗ ∗ j,1 j,1
z = g(y ) for random y , and EK is an obfuscation of GEnc . Indistinguishability holds by security
of a punctured PRF Fj at suf j .
j,3
∗ ∗ ∗ j,1 j,1
z = g(y ) for random y , and EK is an obfuscation of GEnc . In other words, we instruct the
program to output ⊥ instead of m when g(αj ) = z ∗ .
Similar to lemma 1 from [BCP14], we argue that if any adversary can distinguish between hy-
brids Hybj,2 and Hybj,3 and iO is secure, then we can invert the one-way function g. Note that in
our case programs differ on exponentially many inputs; however, differing inputs are a subset of
{αt , . . . , αj = y ∗ , . . . , αn , β}, where y ∗ = g −1 (z ∗ ) and other values can be arbitrary. In other words,
differing inputs share the block y ∗ , and we can do binary search over y ∗ similar to how the proof of
265
lemma 1 does a binary search over a single differing input.
More concretely, the extractor works as follows. It creates a program M which on input
αt , . . . , αj , . . . , αn , β first checks if αj < y 0 (where y 0 is a binary search guess for y ∗ , i.e. in the
j,1 j,3
first iteration y 0 = 2|αj | /2). If so, then M executes GDec , otherwise it executes GDec . Note that if
∗ 0 j,1 ∗ 0
y < y , then M is functionally equivalent to GDec , and if y ≥ y , then M is functionally equivalent
j,3
to GDec . (Indeed, if y ∗ < y 0 , then for all input αj ≥ y 0 the line with the check g(αj ) = z ∗ in both
j,1 j,3
GDec , GDec will never be executed, since g is injective and its only preimage y ∗ < y 0 . Since this is
the only difference in the programs, these programs are functionally equivalent for the case αj ≥ y 0 ,
j,1
and therefore for all inputs M is functionally equivalent to GDec . The case y ∗ ≥ y 0 can be analyzed
similarly). If by assumption there is an adversary which distinguishes between Hybj,2 and Hybj,3 with
probability at least η and iO is ν-secure, where ν = η o(1) , then the adversary can run the adversary
O(1/η) times, estimate its distinguishing probability, learn the first bit of y ∗ , and continue binary
search similar to the proof of lemma 1.
j,3
∗ j,1 j,1 ∗
z = g(Fj (Kj ; suf j )), and EK is an obfuscation of GEnc . In other words, we switch y back to
Fj (Kj ; suf j ) from random. Indistinguishability holds by security of a punctured PRF Fj at suf j .
• Hybj,5 : the adversary gets (EK{U }, DK j+1,0 ), where DK j+1,0 is an obfuscation of a program
j+1,0
GDec . In other words, we unpuncture the key Kj at suf j , and, since the program now always returns
⊥ when suffixj (m) = suf j , we remove the line with z ∗ -check and instead make the program output
⊥ when m ∈ Ssuf j . indistinguishability holds by iO, since this doesn’t change the functionality (the
reasoning why the key can be unpunctured is the same as in Hybj,1 ).
Note that Hybj,5 = Hybj+1,0 .
n+1,0
Note that in Hybn,5 program GDec outputs ⊥ when s ∈ S0 or m ∈ Ssuf n ∪ . . . ∪ Ssuf t+1 = S1 \ S0 . In
other words, it outputs ⊥ when m ∈ S1 , and thus this program is equivalent to DK{S1 }, which concludes
security proof.
Finally, note that security loss depends only logarithmically on the size of S1 \ S0 , as required by security of
constrained decryption of relaxed ACE.
266
j,1
Program GEnc (m)
Inputs: message m.
Hardwired values: keys Kt , . . . , Kn , K (where Kj {suf j } is punctured at suf j ) of PRFs Ft , . . . , Fn , F ;
circuit CU describing set U . Parameters t, n.
2. For each i = t, . . . , n, i 6= j, set αi ← Fi (Ki ; suffixi (m)); set αj ← Fj (Kj {suf j }; suffixi (m));
3. Set β ← F (K; αn ) ⊕ m;
4. Return (αt , . . . , αn , β).
j,0
Program GDec (c)
Hardwired values: keys Kt , . . . , Kn , K of PRFs Ft , . . . , Fn , F ; circuit CS0 . Parameters t, n. Set of suffixes
suf n , . . . , suf t+1 describing S1 \ S0 .
1. Parse c = (αt , . . . , αn , β);
2. Set m ← F (K; αn ) ⊕ β
3. If CS0 (m) then return ⊥;
4. If m ∈ Ssuf j−1 ∪ Ssuf j−2 ∪ . . . ∪ Ssuf t+2 ∪ Ssuf t+1 then return ⊥;
6. Return m.
j,1
Program GDec (c)
circuit CS0 . Parameters t, n. Set of suffixes suf n , . . . , suf t+1 describing S1 \ S0 , injective owf g, value z ∗ .
1. Parse c = (αt , . . . , αn , β);
2. Set m ← F (K; αn ) ⊕ β
4. If m ∈ Ssuf j−1 ∪ . . . ∪ Ssuf t+1 then return ⊥;
5. For each i = t, . . . , n, i 6= j do: if αi 6= Fi (Ki {suf j }; suffixi (m)) then return ⊥;
6. If suffixj (m) = suf j then: if g(αj ) = z ∗ then return m, else return ⊥;
7. If suffixj (m) 6= suf j then: if αj = Fj (Kj {suf j }; suffixj (m)) then return m, else return ⊥.
j,3
Program GDec (c)
circuit CS0 . Parameters t, n. Set of suffixes suf n , . . . , suf t+1 describing S1 \ S0 , injective owf g, value z ∗ .
1. Parse c = (αt , . . . , αn , β);
2. Set m ← F (K; αn ) ⊕ β
4. If m ∈ Ssuf j−1 ∪ . . . ∪ Ssuf t+1 then return ⊥;
5. For each i = t, . . . , n, i 6= j do: if αi 6= Fi (Ki {suf j }; suffixi (m)) then return ⊥;
6. If suffixj (m) = suf j then: if g(αj ) = z ∗ then return ⊥, else return ⊥;
7. If suffixj (m) 6= suf j then: if αj = Fj (Kj {suf j }; suffixj (m)) then return m, else return ⊥.
8. Return ⊥.
Figure 127: Programs used in the proof of security of constrained decryption of relaxed ACE.
267
Symmetry. Recall that from the definition of symmetry U = Ssuf t is a set of plaintexts ending with the same
suffix of size t, and the challenge plaintext m∗ ends with suf t as well. Let suf ∗n , . . . , suf ∗t denote n, . . . , t-long
suffixes of m∗ (note that suf t = suf ∗t ). Further, as in the proof of security of constrained decpryption, let
suf n , . . . , suf t+1 be such that U \ {m∗ } = Ssuf n ∪ . . . ∪ Ssuf t+1 . (Note that for each i = t + 1, . . . , n suf i
and suf ∗i only differ in the first bit).
We show symmetry of ACE in a sequence of hybrids, for b = 0, 1. Programs can be found on fig. 128.
• Hybb0 : The distribution in this hybrid is (c(0) , c(1) , EK{U }, DK{c(0) , c(1) }), where cb is randomly
chosen and c1−b is Enc(EK, m∗ ).
• Hybb1 : The distribution in this hybrid is (c(0) , c(1) , EK 0 , DK 0 ), where EK 0 , DK 0 are instead ob-
fuscations of programs GEnc0 0
and GPuncture , respectively. Denote c = (αt , . . . , αn , β), and c(0) , c(1)
(1−b)
accordingly (in particular, αn = Fn (Kn ; m∗ )). (fig. 128).
We argue that indistinguishability between Hybb0 and Hybb1 for any b holds by iO. Indeed, since for
all i = t, . . . , n Ssuf ∗i ⊂ U and Ssuf i ⊂ U , GEnc0 outputs ⊥ on any input m ∈ Ssuf ∗i or m ∈ Ssuf i , for
all i = t, . . . , n, anyway and thus each Fi is never computed on suf ∗i , suf i , i = t, . . . , n. Thus we
can puncture each Fi at suf ∗i , suf i , i = t, . . . , n (note that suf t = suf ∗t and thus Ft is only punctured
once). Further, since Fn is injective, and is never run on suf ∗n = m∗ , F is never computed on
(1−b) (1−b) (b)
αn = Fn (Kn ; m∗ ), thus we can puncture K at αn . Finally, since αn is randomly chosen and
(b)
Fn has sparse image, with overwhelming probability αn is outside of the image of Fn and we can
(b)
puncture key K at αn as well.
0 (0) (1)
In GPuncture we can puncture K at αn , αn since before that there is an instruction to output ⊥ if
αn is equal to one of these values. We argue that this instruction doesn’t change the functionality:
(b)
indeed, αn is outside of the image of Fn with high probability and therefore the program would reject
(1−b)
anyway. Next, if α = αn , since Fn is injective, the only way to satisfy the Fn -check is to have
(1−b) ∗
β = F (K; αn ) ⊕ m = β (1−b) . But then, to satisfy other PRF checks, αt , . . . , αn−1 should be
(1−b) (1−b)
equal to αt , . . . , αn−1 , in which case c = c(1−b) and the program outputs ⊥ in the very beginning.
• Hybb2 : The distribution in this hybrid is (c(0) , c(1) , EK 0 , DK 00 ), where EK 0 , DK 00 are obfuscations of
programs GEnc0 00
and GPuncture 00
, respectively. In other words, we instruct the program GPuncture to output
⊥ if m ∈ Ssuf n ∪ Ssuf n−1 ∪ . . . ∪ Ssuf t+2 ∪ Ssuf t+1 . Indistinguishability of this hybrid can be shown
similarly to the proof of the security of constrained decryption. That is, for each suf i , i = t + 1, . . . , n,
we can make this program reject all m ∈ Ssuf i by puncturing the PRF Fi , changing Fi (Ki ; suf i ) to
random, replacing the PRF check with OWF check, and arguing that the program can abort (instead
of outputting m) if OWF check passes, since otherwise OWF can be inverted. (Importantly, note that
indeed the value Fi (Ki ; suf i ), for i = t + 1, . . . , n, isn’t used anywhere else in the distribution: in
particular, it is not required to compute c(0) or c(1) , and moreover program GEnc 0 only uses a punctured
key Ki {suf i }).
Indistinguishability holds by security of punctured PRFs Ft+1 , . . . , Fn , one-wayness of injective OWF,
and security of iO.
• Hybb3 : The distribution in this hybrid is (c(0) , c(1) , EK 0 , DK 000 ), where EK 0 , DK 000 are obfuscations
of programs GEnc0 000
and GPuncture 000
, respectively. In other words, we instruct program GPuncture to output
⊥ when m ∈ Ssuf t . We argue this doesn’t change the functionality. Indeed, the condition “m ∈
Ssuf n ∪ Ssuf n−1 ∪ . . . ∪ Ssuf t+1 ” covers all m ∈ Ssuf t except m∗ . Therefore requiring to output ⊥ when
268
m ∈ Ssuf t is equivalent to additionally ask to output ⊥ when m = m∗ . However, when m = m∗ ,
c = c(1−b) and therefore the program outputs ⊥ in the very beginning.
000
Further, in program GPuncture we puncture all keys Ki , i = t, . . . , n, at suf ∗i . This can be done since
the program never needs to compute any of these values since when m ∈ Ssuf t , the program outputs ⊥.
• Hybb4 : The distribution in this hybrid is (c(0) , c(1) , EK 0 , DK 000 ), where EK 0 , DK 000 are obfuscations
0
of programs GEnc 000
and GPuncture , respectively, and c(1−b) is chosen at random instead of as a result of
(b)
PRFs. Security holds by security of PRFs F, Ft , . . . , Fn punctured at αn , suf ∗t , . . . , suf ∗n , respectively.
Finally, note that the distributions in Hyb04 and Hyb14 are the same. Thus concludes the proof of the symmetry
of ACE.
D Encrypting longer plaintexts

Our main security proof holds for the case when 1-bit plaintexts are used. Here we outline the changes in the
proof when the scheme is used to encrypt long plaintexts from some plaintext space M.
The only change is that in the proof of indistinguishability of explanations of the receiver (lemma 55), instead
of eliminating a single complementary ciphertext µ3 ∗ = ACE.EncEK (1 ⊕ m∗0 , µ1 ∗ , µ2 ∗ , L∗0 ), we need to
eliminate all complementary ciphertexts {ACE.EncEK (m, µ1 ∗ , µ2 ∗ , L∗0 ) : m ∈ M, m 6= m∗0 }. This change
is required both in the proof of deniability and off-the-record deniability.
Concretely, changes are the following:
• In hybrid HybB,1,5 (similarly, in HybB,3,2 ) in program P3 we puncture encryption key EK of the main
ACE at all points {(m, µ1 ∗ , µ2 ∗ , L∗0 ) : m ∈ M, m 6= m∗0 }. Indistinguishability holds by the same
reasoning as in the orginal proof. The description of the program P3 on fig. 99 should be changed
accordingly.
• In hybrid HybB,1,6 (similarly, in HybB,3,1 ) we puncture decryption key DK of the main ACE at the
same set of points p = {(m, µ1 ∗ , µ2 ∗ , L∗0 ) : m ∈ M, m 6= m∗0 }. Indistinguishability holds by security
of constrained decryption of ACE, since the corresponding encryption key EK is already punctured at
these points. The description of the programs Dec, RFake on fig. 101 should be changed accordingly.
Note however that this incurs security loss proportional to |M|, since security loss in constrained
decryption game depends on the size of the punctured set.
Thus the proof can be adapted to the case of longer plaintexts, with additional multiplicative factor of |M| in
security loss. However, the resulting scheme is only statically secure, i.e. both real and fake plaintexts have
to be fixed before the CRS is generated. To achieve adaptive security, one can guess both plaintexts in the
proof and lose another factor of |M|2 .
Thus the scheme can be used for encrypting and denying longer messages, albeit with additional multiplicative
factor of |M|3 in security loss.
269
Program 0 (m)
GEnc
Inputs: message m.
(0) (1)
Hardwired values: punctured keys Kt {suf ∗t , suf t }, Kt+1 {suf ∗t+1 , suf t+1 }, . . . , Kn {suf ∗n , suf n }, K{αn , αn }
of PRFs Ft , . . . , Fn , F ; circuit CU describing set U . Parameters t, n.
2. For each i = t, . . . , n set αi ← Fi (Ki {suf ∗i , suf i }; suffixi (m));
(0) (1)
3. Set β ← F (K{αn , αn }; αn ) ⊕ m;
4. Return (αt , . . . , αn , β).
Program G 0 Puncture (c)
(0) (1)
Hardwired values: keys Kt , . . . , Kn , K{αn , αn } of PRFs Ft , . . . , Fn , F ; circuit CU describing set U .
In addition, strings c(0) and c(1) , hardwired in lexicographic order. Parameters t, n.
(0) (0) (1) (1)
2. Parse c = (αt , . . . , αn , β); c(0) = (αt , . . . , αn , β (0) ); c(1) = (αt , . . . , αn , β (1) );
(0) (1) (0) (1)
3. If αn = αn or αn = αn then return ⊥; (αn and αn are written in lexicographic order)
(0) (1)
4. Set m ← F (K{αn , αn }; αn ) ⊕ β;
6. Return m.
(0) (1)
Hardwired values: keys Kt , . . . , Kn , K{αn , αn } of PRFs Ft , . . . , Fn , F ; circuit CU describing set U .
In addition, strings c(0) and c(1) , hardwired in lexicographic order. Parameters t, n.
(0) (0) (1) (1)
(0) (1) (0) (1)
(0) (1)
4. Set m ← F (K{αn , αn }; αn ) ⊕ β;
5. If m ∈ Ssuf n ∪ Ssuf n−1 ∪ . . . ∪ Ssuf t+2 ∪ Ssuf t+1 then return ⊥;
7. Return m.
(0) (1)
Hardwired values: punctured keys Kt {suf ∗t }, . . . , Kn {suf ∗n }, K{αn , αn } of PRFs Ft , . . . , Fn , F ; circuit
CU describing set U . In addition, strings c(0) and c(1) , hardwired in lexicographic order. Parameters t, n.
(0) (0) (1) (1)
(0) (1) (0) (1)
(0) (1)
4. Set m ← F (K{αn , αn }; αn ) ⊕ β;
5. If m ∈ Ssuf t then return ⊥;
6. For each i = t, . . . , n do: if αi 6= Fi (Ki {suf ∗i }; suffixi (m)) then return ⊥;
7. Return m.
(0) (1)
Figure 128: Programs of constrained keys. Note that everywhere where c(0) , c(1) or αn , αn appear, they
(0) (1)
are written in lexicographic order (in particular, in the GGM-based punctured PRF, key K{α n n , αn }odoesn’t
(0) (1)
depend on the order of puncturing and only depends on lexicographically sorted set αn , αn ). For
∗ ∗
convenience we denote the punctured Kt by Kt {suf 270 t , suf t } (similar to other keys), even though suf t = suf t
and the key is only punctured at one point.

Fully Deniable Interactive Encryption: Ran Canetti Sunoo Park Oxana Poburinnaya July 25, 2020

Uploaded by

Copyright:

Available Formats

Fully Deniable Interactive Encryption: Ran Canetti Sunoo Park Oxana Poburinnaya July 25, 2020

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fully Deniable Interactive Encryption: Ran Canetti Sunoo Park Oxana Poburinnaya July 25, 2020

Uploaded by

Copyright:

Available Formats

Fully Deniable Interactive Encryption

Ran Canetti∗ Sunoo Park† Oxana Poburinnaya‡

July 25, 2020

2 Towards the Scheme: Technical Overview 11

3 Defining Bideniable and Off-the-Record Deniable Encryption 22

4 Deniable Encryption in Oracle-Access model 26

5 Preliminaries: IO, DIO, and ACE 42

6 Construction of interactive deniable encryption 54

8 Proof of bideniability of our encryption protocol 177

9 Proof of off-the-record deniability of our encryption protocol 247

A On Flexible Deniability: Discussion 259

B On removing layers of obfuscation 261

C Construction of relaxed ACE 262

D Encrypting longer plaintexts 269

1.1 Our Contributions

Theorem 1. Assuming subexponentially secure indistinguishability obfuscation and subexponentially secure

1.2 Fully Deniable Interactive Encryption: Definition in a Nutshell

(tr(s, r, m0 ), s, r) ≈c (tr(s, r, m), sm0 , rm0 ) , (1)

1.3 A Very Brief Overview of the Construction

Figure 2: Comparison-based decryption behavior

1.4 Directions for Future Progress

1.5 Variants of Deniable Encryption and Other Related Concepts

1.6 Prior Work on Deniable Encryption

1.7 Organization, and How to Read This Paper

2 Towards the Scheme: Technical Overview

2.1 A First Attempt

Base Protocol programs: first attempt at deniable encryption.

2.2 Levels, Comparison-Based Decryption, and the Final Scheme

Figure 5: Comparison-based decryption behavior

from the transcript to r.

2.3 Outline of security proof in oracle-access model.

2.4 Changes to the construction due to iO.

3 Defining Bideniable and Off-the-Record Deniable Encryption

3.2 Deniability in The Oracle Access Model

4.2 Proof of correctness and security.

Our interactive deniable encryption:

5 Preliminaries: IO, DIO, and ACE

Pr[C 0 (x) = C(x) : C 0 ← iO(1λ , C)] = 1

Pr D(iO(1λ , Cλ0 )) = 1 − Pr D(iO(1λ , Cλ1 )) = 1 ≤ negl(λ).

5.2 Equivalence of iO and diO for programs differing on one point

Pr[Fk (x) = Fk{S} (x) : k ← Sample(1λ ), k{S} ← Puncture(k, S)] = 1.

| Pr [ A(k, Fk (x)) = 1 | x ← X ] − Pr [ A(k, r) = 1 | r ← UI ] | < negl(λ).

5.4 Asymmetrically constrained encryption (ACE) and its relaxed variant

Pr Dec(DK, Enc(EK, m)) = m EK ← GenEK(SK, CS 0 ),  = 1.

Pr Enc(EK, m) = Enc(EK 0 , m) EK ← GenEK(SK, CS ),  = 1.

Pr Dec(DK, c) ∈ S SK ← Setup(1λ ), DK ← GenDK(SK, CS ) = 0

EK{S}, DK{U }, c∗1 , c∗0 , c1 , . . . , ct

in the probability space defined by sampling SK ← Setup(1λ ), EK ← GenEK(SK, ∅), EK{S} ←

6 Construction of interactive deniable encryption

Our Interactive deniable encryption:

6.2 Building blocks and main theorem stating security

Definition 10. A tuple of parametrized, deterministic27 algorithms

(GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags, GenZero[m∗1 ], Transform[l∗ , m∗2 ])

(`∗0 , L∗0 , PP0 ) ≈ (`∗1 , L∗0 , PP1 ),

6.2.3 Main theorem

Definition 11. A tuple of parametrized, deterministic30 algorithms

(GenZero, Increment, Transform, isLess, RetrieveTag, RetrieveTags, GenZero[m∗1 ], Transform[l∗ , m∗2 ])

(`∗0 , L∗0 , PP0 ) ≈ (`∗1 , L∗0 , PP1 ),

7.3 Overview of the proof