1 Introduction

Program obfuscation is the process of transforming a computer program into an “unintelligible” one while preserving its functionality. Barak et al. [BGI+12] formulated several notions for program obfuscation, and demonstrated that the strongest form of obfuscation, called virtual black-box (\(\mathsf {VBB}\)) obfuscation, is impossible in general. The recent work of Garg et al. [GGH+13b] presents an obfuscation mechanism for general programs that achieves the notion of indistinguishability obfuscation based on assumptions on multilinear maps [GGH13a]. Indistinguishability obfuscation, or \(\mathsf {IO}\), is a weaker form of obfuscation than \(\mathsf {VBB}\); nevertheless, it results in best possible obfuscation [GR07].

The feasibility of general purpose obfuscation, in principle, allows the creation of software that can provably safeguard secret information, e.g., cryptographic keys, proprietary algorithms, and so on. A typical software, however, can be quite complex with millions of lines of executable code [IB]. Once installed, it may go through frequent updates, e.g., when new features are added or security vulnerabilities are discovered. If cryptographic obfuscation is used to protect the software, it must be possible to quickly update the obfuscated software when new updates become available. In particular, if the original program is large, the obfuscating it from scratch for every new update would be prohibitive. Furthermore, in various client-server settings, where the obfuscated software resides on a networked machine, transmitting the entire (updated) software would be a bottleneck. Ideally, the effort to update the obfuscated program should only be proportional to the changes made to the original unobfuscated program.

These issues are not unique to program obfuscation and analogous problems have been considered in several other settings. Bellare, Goldreich and Goldwasser [BGG94] introduced and developed the notion of incremental cryptography, first in the context of hashing and digital signatures. The idea is that, once we have signed a document D, signing new versions of D should be rather quick. For example, if we only flip a single bit of D, we should be able to update the signature in time polynomial in \(\log |D|\) (instead of |D|) and the security parameter \(\lambda \). Incrementality is an attractive feature to have for many cryptographic primitive such as encryption, signatures, hash functions, and so on [BGG95, Mic97, Fis97a, BM97, BKY01, MPRS12].

If we want to obfuscate large programs that are frequently updated, then it is crucial to have incremental program obfuscation. Although, current program obfuscation methods are prohibitively slow for application to large programs. However as it becomes more efficient, it is clear that incrementality will be essential for deployment of obfuscation of large programs. This line of investigation is particularly important because of its relevance to the deployment (as opposed to security) of obfuscated software.

1.1 Our Contributions

In this work, we initiate the study of incremental program obfuscation. Here we ask what is the right security definition for incremental program obfuscation and if it can be realized. In this work, we show that enhancing obfuscation with incrementality must come at the some degradation in security. In contrast on the positive side, we realize the best possible incremental obfuscation. More specifically, our incremental obfuscation method hides as much about the original program as any other incremental obfuscation of a given size. Our results are generic in the sense that starting with a general purpose obfuscation method for circuit, Turing Machines or RAM programs, we obtain general purpose incremental obfuscation for the same class of programs. Next we provide more details.

Modeling incremental obfuscation. We model an incremental obfuscation method by an obfuscation procedure and an \(\mathsf {Update}\) procedure. In this setting, a large program P is obfuscated and placed on a remote machine in the obfuscated form \(\widetilde{P}\). \(\mathsf {Update}\) can query any bit of the obfuscated program \(\widetilde{P}\). The input to \(\mathsf {Update}\) is a set S of indices, indicating which bits of P should be “updated.” For every index \(i\in S\), there is an associated update operation \(f_i:\{0,1\}\rightarrow \{0,1\}\) to be performed on the ith bit of P; the set of these operations is denoted by \(F_S=\{f_i\}_{i\in S}\). The output of \(\mathsf {Update}\) consists of a set \(\widetilde{S}\) indicating the bits of \(\widetilde{P}\) to be updated; for every \(i\in \widetilde{S}\) there is an associated bit \(b_i\) indicating the updated value.

The incrementality of an obfuscation scheme, denoted \(\varDelta \), is defined to be the running time of \(\mathsf {Update}\) in the worst case with respect to singleton sets S. This is a robust measure since it tells us how bad \(\mathsf {Update}\) can be when we just want to update one bit.Footnote 1

An important observation is that the \(\mathsf {Update}\) cannot be a public algorithm, since otherwise, one can “tamper” with the \(\widetilde{P}\) and potentially recover the entire P. Therefore, \(\mathsf {Update}\) must require a secret key, generated at the time of obfuscation of P, to be able to make updates.

In this work, we require that the size of the updated obfuscated program should be the same as the fresh obfuscation of the new (updated) program. Further strengthening this requirement: we require that an updated obfuscation of a program should look computationally indistinguishable from a freshly generated obfuscation of the new program. We actually achieve statistical indistinguishability, and refer to this property as pristine updates. These requirements are crucial for various applications.

Lower bound for incremental \(\mathsf {VBB}\) and \(\mathsf {VGB}\) obfuscation. We show that incrementality significantly interferes with the security an obfuscation method can offer. More specifically, we show that for the family of point functions, every incremental \(\mathsf {VBB}\) obfuscation scheme must have incrementality \(\varDelta \in \varOmega (n/\mathrm{log}\,n)\) where n is the size of the point function program. In fact, our result holds also for the weaker notion of virtual grey box (\(\mathsf {VGB}\)) obfuscation, introduced by Bitanksy and Canetti [BC10]. \(\mathsf {VGB}\) obfuscation, like \(\mathsf {VBB}\), is a simulation-based notion of security but it allows the simulator to be unbounded; it only requires that the number of queries made by the simulator to the black-box program should be polynomial. This further strengthens our result.

Our lower bound proceeds by proving that every incremental \(\mathsf {VGB}\) (and hence \(\mathsf {VBB}\)) scheme must “leak” the Hamming distance between the obfuscated and updated programs. Therefore, no generic compiler can preserve obfuscation quality and provide low incrementality at the same time.

Interestingly, our negative result holds even if only one update is made to the obfuscated point function. This is somewhat surprising since point-functions are inherently related to deterministic encryption [BS16] for which incremental schemes are known for single updates [MPRS12].

Positive results for indistinguishability obfuscation. Our lower bound motivates us to look more deeply into the definitions for incremental indistinguishability obfuscation, or \(\mathsf {IIO}\). We aim to obtain high flexibility in addition to as strong security as possible.

With this goal, we consider an obfuscated program \(\widetilde{P}\) which is continually updated over time, by applying the \(\mathsf {Update}\) algorithm to the previous obfuscation. This results in a sequence of obfuscated programs \(\widetilde{P}, \widetilde{P}^1,\ldots ,\widetilde{P}^t\) where \(\widetilde{P}^i\) is obtained from \(\widetilde{P}^{i-1}\) using \(\mathsf {Update}\). Since the adversary can view the entire sequence of obfuscated programs, this suggests the following natural definition: for every pair of programs \((P_0,P_1)\) and every sequence of increments (or updates) \(I=(S_1,\ldots ,S_t)\) of arbitrary polynomial size sets \(S_i\) and for arbitrary polynomial t, the distributions \(X_0:=(\widetilde{P}_0, \widetilde{P}^1_0,\ldots ,\widetilde{P}^t_0)\) and \(X_1:=(\widetilde{P}_1, \widetilde{P}^1_0,\ldots ,\widetilde{P}^t_1)\) should be computationally indistinguishable provided that \(P_0^i\) and \(P_1^i\) are functionally equivalent for every i where \(P_b^i\) is the program corresponding to \(\widetilde{P}_b^i\) for every \(b\in \{0,1\}\).

We use this definition as the default definition of \(\mathsf {IIO}\). We present an \(\mathsf {IIO}\) scheme for the class of all circuits with incrementality \(\mathsf {poly}(\lambda ,\log |P|)\), assuming the existence of \(\mathsf {IO}\) for the same class.

Increment-privacy and “best possible” incremental obfuscation. The \(\mathsf {IIO}\) definition does not necessarily hide the sequence I of increments. Indeed, by looking at the sequence of updated programs, an adversary might be able to recover which bits were updated at each time step. For many application this could be a serious issue. For example, if \(\widetilde{P}\) is updated to fix a security vulnerability in P, by looking at which bits were updated, a hacker might be able to discover the vulnerability; it can then exploit other machines where the program is still awaiting update.

Even more importantly, since \(\mathsf {IIO}\) may leak the sequence I, it is unlikely to achieve our desired “best possible” incremental obfuscation. We therefore consider a strengthened definition which hides the sequence I, and call it increment-private \(\mathsf {IIO}\). More specifically, we consider two sequences \(I_0,I_1\) where \(I_0\) is applied to \(\widetilde{P}_0\) and \(I_1\) to \(\widetilde{P}_1\). As before, we require that the resulting obfuscation sequences should look indistinguishable provided that the underlying programs are functionally equivalent at every time step.

With the goal of realizing obfuscation satisfying this security notion, we show a transformation which converts any \(\mathsf {IIO}\) scheme into increment-private \(\mathsf {IIO}\) scheme without affecting its incrementality too much. Our transformation is obtained by combining \(\mathsf {IIO}\) with oblivious RAM (ORAM) programs [GO96].

Finally, in an effort to better understand what is the strongest possible incremental obfuscation, we define the notion of best possible incremental obfuscation, or \(\mathsf {IBPO}\). For example, our lower bound for \(\mathsf {VGB}\)/\(\mathsf {VBB}\) obfuscations demonstrates that any incremental scheme must leak the size of incremental updates that take place. It is important to understand if this is all that is leaked. Our \(\mathsf {IBPO}\) notion essentially captures all the information that can leak by an incremental obfuscation. Interestingly, we are able to show that increment-private \(\mathsf {IIO}\) and \(\mathsf {IBPO}\) are equivalent! That is, hiding the sequence suffices for best possible obfuscation. This is further evidence that increment-private \(\mathsf {IIO}\) is the right notion to target.

In all of our constructions we work with the sequential and non-adaptive model of updates — i.e., the updates are not adversarially chosen based on the previously provided obfuscations. In most settings for software updates, the updates are not adversarial since they come from the software provider. The non-adaptive definition suffices for such applications. However, the adaptive definition might be desirable in other settings, for example if the adversary can influence the choice of updates, e.g., through insider attacks. We do not consider this notion in this work. Our results, however, easily extend to non-sequential setting which will be discussed towards the end.

Other applications. Besides being interesting in its own right, incremental obfuscation can be seen as a natural tool to enhance applications of obfuscation with incrementality properties. For example, one can very easily enhance the functional encryption scheme of Garg et al. [GGH+13b] in a way such that secret keys have incrementality properties. In functional encryption an encrypter can encrypt a message m in such a way that a secret key \(sk_C\), parameterized by the circuit C, can be used to learn C(m). Using our incremental obfuscation we can realize incremental functional encryption, where given a secret key for \(sk_C\) one can quickly provide new secret keys for incremental changes in C.

1.2 An Overview of Our Approach

In this section we provide an overview of our constructions. We begin with a systematic exploration, and show how to achieve the basic \(\mathsf {IIO}\) definition first. We then show how to compile this construction with ORAM to obtain increment-privacy without sacrificing incrementality. For concreteness, we view the program P as a boolean circuit C.

A common approach for obfuscating a general circuit C relies on the Naor-Yung “two-key paradigm” [NY90]: C is encrypted twice to get ciphertexts \((e_1,e_2)\) which are then “hardwired” into a low-depth circuit for which candidate obfuscation is known.

Suppose that we are given \(\mathsf {IO}\) for the class of all circuits. We will follow the two-key paradigm to obtain \(\mathsf {IIO}\). Specifically, we will obfuscate a special circuit \(C^*\) using \(\mathsf {IO}\) which will internally evaluate C. However, we cannot hardwire either C or the value \((e_1,e_2)\) in \(C^*\) since even if the values \((e_1,e_2)\) support incrementality, the \(\mathsf {IO}\) may not.

One option is to provide \(e=(e_1,e_2)\) as an explicit input to \(C^*\). \(C^*\) can obtain C by decrypting, say \(e_1\), and evaluate it as required. If \(e_1,e_2\) are bitwise encryptions of C, the scheme is also incremental: changing any bit only requires changing the corresponding ciphertexts in e.

In order to make sure that the scheme is secure, \(C^*\) must only accept “authorized” values of e. This can be accomplished, for example, by signing e entirely after every update. \(C^*\) will verify the signature on the updated e before performing the computation. This is indeed a promising approach, however, observe that now the signature must also be incremental since it would be a part of the obfuscation. Unfortunately, this is a big problem since incremental signatures are usually not injective. Consequently, there can exist multiples messages corresponding to the same signature; the existence of such messages is not quite compatible with \(\mathsf {IO}\) techniques.

Nevertheless, it is a promising approach and it is possible to make it work based on the existence of (public-coin) differing-inputs obfuscation (\(\mathsf {pc\text {-}dIO}\)) [ABG+13, BCP14, IPS15]. Our goal is to obtain a feasibility result based on the existence of \(\mathsf {IO}\) alone, since \(\mathsf {pc\text {-}dIO}\), due to its extractability flavor, is viewed as a very strong assumption [GGHW14, BP15b].

SSB hash and Merkle trees. A powerful technique to avoid the \(\mathsf {pc\text {-}dIO}\) in many settings is the somewhere statistically binding (SSB) hash technique based on Merkle trees. It was introduced by Hubaceck and Wichs [HW15], and is very similar in spirit to the positional accumulators of Koppula, Lewko, and Waters [KLW15].

At a high level, the approach considers hash functions which can be generated to be statistically binding at a chosen location. These functions are collisions-resistant, and functions generated for different locations are computationally indistinguishable. Such functions can be constructed from a variety of assumptions, including \(\mathsf {IO}\) [HW15, KLW15, OPWW15].

Coming back to our construction, we will use the SSB hash functions based on Merkle trees presented in [HW15]. This hash has incrementality property, and consists of two values (hT) where T is the Merkle tree and h is the root of T. Unfortunately, the SSB hash technique cannot be applied in a black-box manner to all settings. It has to be properly adapted to every setting.

We show how to apply this technique in our setting. More specifically, we take the following high level steps:

  1. 1.

    We encrypt the circuit twice, bit-by-bit, as before to obtain \(e=(e_1,e_2)\). We then apply a quickly updatable SSB Hash to e to obtain (hT). The value h is then “signed.”

  2. 2.

    In fact, ordinary signatures are too rigid for our needs. Instead, we use non-interactive zero-knowledge (NIZK) proofs to give proofs that h does not have some special structure.

  3. 3.

    The full obfuscation will include \(\mathsf {IO}\) of a circuit \(C^*\) which has a secret-key \(sk_1\) hardwired for decrypting \(e_1\) and evaluating the resulting circuit on inputs of interest if all NIZK proofs verify.

  4. 4.

    As new updates arrive, values ehT are easily updated, as well as the proofs since they only depend on h and not eT.

  5. 5.

    We then rely on the combined power of SSB-hash functions and NIZK proofs to design a sequence of hybrids such that the signatures exist only for the specified sequence in question. We further use NIZK proofs, SSB hash, and the power of \(\mathsf {IO}\) to slowly reach a point in hybrid experiments where there is exactly one value \(e^*\) that will be accepted by the obfuscated program. At this point, we will able to encrypt the circuits from the other sequence—again, this step is performed one-by-one for each location in the sequence.

We note that executing this strategy is rather involved, and we heavily rely on manipulations via NIZK proofs to complete the security proof.

Increment-privacy via ORAM. To amplify security to increment-private \(\mathsf {IIO}\), we rely on two techniques: ORAM programs and the two-key paradigm [NY90]. In more detail, to obfuscate a circuit C, we first apply a statistically-secure ORAM scheme to C twice, to obtain two independent encodings of C, say \(C_1^*,C_2^*\). Next we generate a circuit P that has \((C_1^*,C_2^*)\), and secret information to decode one of them hardcoded in it. The program P, on input x, decodes one of the encoded circuits and outputs the evaluation of the decoded circuit on input x. Having defined P, we now obfuscate P using any \(\mathsf {IIO}\) scheme (which only satisfies the weaker definition). The resulting obfuscation is our increment-private \(\mathsf {IIO}\).

At a high level, this works because incremental changes in C can be reduced to corresponding changes in the ORAM encodings of C, and hence the program P. However, since P is encoded using our \(\mathsf {IIO}\) scheme, this preserves incrementality up to logarithmic factors. At the same time, the use of ORAM ensures the privacy of incremental updates.

We remark that, although the underlying ideas behind this transformation are simple, the proof is not as simple as one would hope for. In particular, to be able to successfully rely on the security of \(\mathsf {IIO}\), the obfuscated program needs a little more “guidance” to perform its task so that the hybrids will go through.

1.3 Related Work

Patchable Obfuscation. An interesting variant of \(\mathsf {IIO}\)–called Patachable Obfuscation (PO)—was considered in [AJS17]. In PO, one aims to release a “short patch” which can update a previously obfuscated program. There are several fundamental differences between these two works. A crucial difference between \(\mathsf {IIO}\) and PO is that in PO, the “patch” is allowed to take linear time (i.e., proportional to the size of the obfuscated program) even if the actual change is only a single bit in the underlying program. Indeed this is the case with the constructions of [AJS17]. In contrast, \(\mathsf {IIO}\) requires that the time to update the obfuscated program must only depend on the time to update the plain, unobfuscated program. Our constructions achieve this form of efficiency. On the flip side, PO can maintain a short concise description of the patch even if the final change will be large; \(\mathsf {IIO}\) does not require concise description and depends on the final change.

The primary reason for this difference is the fundamental difference in how the two works formulate the updates: while our work views them as a small set of bit positions that need to be updated, [AJS17] views them as a small program that updates the bits as it processes the entire obfuscated code. Due this fundamental difference in problem formulation, the two works employ completely different methods. Our \(\mathsf {IIO}\) constructions are obtained by relying only on standard, polynomially-hard assumptions but achieve only non-adaptive security. In contrast, the results of [AJS17] require the underlying primitives to be sub-exponentially secure but achieve adaptive security.

Finally, the stringent requirement on running time of updates in our work sheds light on the lower bounds for other notions of obfuscations such as \(\mathsf {VBB}\)/\(\mathsf {VGB}\)-obfuscation. We additionally develop the notion of best possible incremental obfuscation and develop generic tools using ORAM to achieve this notion. [AJS17] do not consider these issues or rely on ORAM techniques in any way. On the flip side, the method in [AJS17] can expand the input length of the obfuscated program which is not considered in our work.

Other related work. The concept of incremental cryptography was put forward by Bellare, Goldreich, and Goldwasser [BGG94], as a different type of efficiency measure for cryptographic schemes. They considered the case of hashing and signing, and presented discrete-logarithm based constructions for incremental collision-resistant hash functions and signatures, that support block replacement operation. Soon after, Bellare et al. [BGG95] also developed constructions for block insertion and deletion, and further issues such as tamper-proof updates, privacy of updates, and incrementality in symmetric encryption were also considered.

Subsequently, Fischlin [Fis97a] presented an incremental signature schemes supporting insertion/deletion of blocks, and tamper-proof updates, and proved a \(\varOmega (\sqrt{n})\) lower bound in [Fis97b] on the signature size of schemes that support substitution and replacement operations (the bound can be improved to \(\varOmega (n)\) in certain special cases). The case of hashing was revisited by Bellare and Micciancio [BM97] who provided new constructions for the same based on discrete logarithms and lattices. Buonanno, Katz, and Yung [BKY01] considered the issue of incrementality in symmetric unforgeable encryption and suggested three modes of operations for AES achieving this notion.

Mironov, Pandey, Reingold, and Segev [MPRS12] study incrementality in the context of deterministic public-key encryption. They prove a similar lower bound on the incrementality of such schemes, and present constructions with optimal incrementality.

The task of constructing cryptographic primitives in the complexity class \(\mathrm {NC}^0\) can be viewed as a dual of incremental cryptography where the focus is on output locality instead of input locality. Applebaum, Ishai, and Kushilevitz [AIK06] resolved this question in the affirmative for public-key encryption, and argue impossibility of the same for constant input locality [AIK06, Sect. 1.1].

Barak et al. [BGI+12] formulated the notion of program obfuscation and proved strong negative results for \(\mathsf {VBB}\) obfuscation. The connection between zero-knowledge and code obfuscation was first observed and studied by Hada [Had00]. \(\mathsf {VBB}\) obfuscation for special classes of functions such as point functions were first considered by Wee [Wee05] (and Canetti [Can97]); subsequently, constructions for more functions were achieved such as proxy re-encryption, encrypted signatures, hyperplanes, conjunctions, and so on [LPS04, HRSV07, Had10, CRV10, BR13]. Goldwasser and Kalai extended the negative results for \(\mathsf {VBB}\) obfuscation in the presence of auxiliary inputs [GK05] which were further extended by Bitansky et al. [BCC+14].

The notion of best possible obfuscation was put forward by Goldwasser and Rothblum [GR07], who also prove its equivalence to indistinguishability obfuscation (for efficient obfuscators). Bitansky and Canetti [BC10] formulated the notion of virtual grey box (\(\mathsf {VGB}\)) obfuscation which is a simulation based notion; it was further explored in [BCKP14].

The first positive result for indistinguishability obfuscation was first achieved in the breakthrough work of [GGH+13b], and further improved in [BGK+14]. In the idealized “generic encodings” model \(\mathsf {VBB}\)-obfuscation for all circuits were presented in [CV13, BR14, BGK+14, AB15]. These results often involve a “bootstrapping step” which was improved by Applebaum [App14]. Further complexity-theoretic results appear in recent works of Barak et. al. [BBC+14] and Komargodski et al. [KMN+14]. Obfuscation in alternative models such as the hardware token model were considered in [GIS+10, BCG+11].

Sahai and Waters [SW14] developed powerful techniques for using indistinguishability obfuscation to construct several (old and new) cryptographic primitives. Since then, \(\mathsf {IO}\) has been successfully applied to achieve several new results, e.g., [HSW14, BZ14, MO14, PPS15, CLP15, HW15, BP15a, BPW16, AS16]. The equivalence of \(\mathsf {IO}\) and functional encryption [BSW11, O’N10] was recently established by Ananth and Jain [AJ15] and Bitanksy and Vaikuntanathan [BV15].

Differing input obfuscation (diO) was studied by Ananth et. al. [ABG+13] and Boyle et al. [BCP14], and subsequently used to construct obfuscation for Turing machines. After various implausibility results [GGHW14, BP15b], Ishai, Pandey, and Sahai put forward the improved notion of public-coin differing-inputs obfuscation and recovered several original applications of diO. Indistinguishability obfuscation for bounded-input Turing machines and RAM programs were presented in [BGL+15, CHJV15] and for bounded-space programs in [KLW15].

The notion of oblivious RAM programs was put forward by Goldreich and Ostrovsky [Gol87, Ost90, GO96]. Several improved constructions and variations of ORAM programs are now known [SCSL11, SvDS+13, LO13, CLP14, BCP16].

2 Definitions and Preliminaries

In this section we recall the definitions of some standard cryptographic schemes which will be used in our constructions. For concreteness, we adopt the family of polynomial-sized circuits are model of computation for describing programs. Our definitions, constructions, and results apply to Turing machines and RAM programs as well. We will bring up these models when appropriate.

From here on, unless specified otherwise, \(\lambda \) always denotes the security parameter. We assume familiarity with standard cryptographic primitives, specifically public-key encryption (PKE), non-interactive zero-knowledge proofs (NIZK, recalled in Sect. 2.4), perfectly binding commitments, and computational indistinguishability.

2.1 Indistinguishability Obfuscators

Definition 1

(Indistinguishability Obfuscator ( \(\mathsf {IO}\mathbf{)).}\) A uniform PPT machine \(\mathcal {O}\) is called an indistinguishability obfuscator for a circuit class \(\{\mathcal {C}_\lambda \}\) if the following conditions are satisfied:

  • Correctness: For all security parameters \(\lambda \in \mathbb {N}\), for all \(C \in \mathcal {C}_\lambda \), for all inputs x, we have that

    $$ \Pr [\widetilde{C}(x)=C(x) : \widetilde{C} \leftarrow \mathcal {O}(\lambda ,C)] = 1. $$
  • Indistinguishability: For any (not necessarily uniform) PPT distinguisher D, there exists a negligible function \(\alpha \) such that the following holds: For all security parameters \(\lambda \in \mathbb {N}\), for all pairs of circuits \(C_0, C_1 \in \mathcal {C}_\lambda \), we have that if \(C_0(x) = C_1(x)\) for all inputs x, then

2.2 Somewhere Statistically Binding Hash

We recall the definition of somewhere statistically binding (SSB) hash from [HW15, OPWW15].

Definition 2

(SSB Hash). A somewhere statistically binding (SSB) hash consists of PPT algorithms \((\mathsf {Gen},H)\) and a polynomial \(\ell (\cdot ,\cdot )\) denoting the output length.

  • \(hk \leftarrow \mathsf {Gen}(1^\lambda ,1^s, L,i)\): Takes as input a security parameter \(\lambda \), a block-length s, an input-length \(L \le 2^\lambda \) and an index \(i \in [L]\) (in binary) and outputs a public hashing key hk. We let \(\varSigma = \{0,1\}^s\) denote the block alphabet. The output size is \(\ell = \ell (\lambda ,s)\) and is independent of the input-length L.

  • \(H_{hk}: \varSigma ^L \rightarrow \{0,1\}^\ell \): A deterministic poly-time algorithm that takes as input \(x = (x[0],\ldots , x[L-1]) \in \varSigma ^L\) and outputs \(H_{hk}(x)\in \{0,1\}^\ell \).

We require the following properties:

  • Index Hiding: We consider the following game between an attacker \(\mathcal {A}\) and a challenger:

  • The attacker \(\mathcal {A}(1^\lambda )\) chooses parameters \(1^s,L\) and two indices \(i_0,i_1 \in [L]\).

  • The challenger chooses a bit \(b \leftarrow \{0,1\}\) and sets \(hk \leftarrow \mathsf {Gen}(1^\lambda ,1^s, L,i)\).

  • The attacker \(\mathcal {A}\) gets hk and outputs a bit \(b'\). We require that for any PPT attacker \(\mathcal {A}\) we have that \(|\Pr [b = b']-\frac{1}{2}|\le \textsf {negl}(\lambda )\) in the above game.

  • Somewhere Statistically Binding: We say that hk is statistically binding for an index \(i \in [L]\) if there do not exist any values \(x,x' \in \varSigma ^L\) where \(x[i] \ne x'[i]\) such that \(H_{hk}(x) = H_{hk}(x')\). We require that for any parameters sL and any integer \(i \in [L]\) we have:

    $$\Pr [hk~\text {is statistically binding for index } i \!:\! hk\leftarrow \mathsf {Gen}(1^\lambda ,1^s,L,i)]\ge 1 {-} \textsf {negl}(\lambda ).$$

    We say the hash is perfectly binding if the above probability is 1.

Merkle SSB Hash. For concreteness, we work with a specific instantiation of SSB Hash based on Merkle trees (and fully homomorphic encryption) given in [HW15]. The has values from this construction have the form (hT) where T is the Merkle tree and h is the root of T. This construction has the incrementality or “quick update” property: small changes to the underlying value only require \(\mathsf {poly}(\lambda ,\log n)\) changes to (hT) where n is the length of the string. Constructions with same properties can be based on a variety of assumptions including \(\mathsf {IO}\) alone [OPWW15, KLW15].

2.3 Oblivious RAM

We review the notion of ORAM programs from [Gol87, Ost90, GO96]. Constructions of ORAM are provided by the same papers as well. ORAM can be thought of as a compiler that encodes the memory into a special format such that the sequence of read and write operations into this memory do not reveal the actual access pattern. We recall basic definitions here and refer the reader to [GO96] for more details.

Syntax. A Oblivious RAM scheme consists of two procedures \((\mathsf {OData}, \mathsf {OAccess})\) with syntax:

  • \((D^*,s) \leftarrow \mathsf {OData}(1^\lambda ,D)\): Given a security parameter \(\lambda \) and memory \(D \in \{0,1\}^m\) as input, \(\mathsf {OData}\) outputs the encoded memory \(D^*\) and the encoding key \(s\).

  • \(d \leftarrow \mathsf {OAccess}^{D^*}(1^\lambda ,s, \ell , v)\): \(\mathsf {OAccess}\) takes as input the security parameter \(\lambda \) and the encoding key \(s\). Additionally, it takes as input a location \(\ell \in [m]\) and a value \(v \in \{\bot ,0,1\}\). If \(v = \bot \) then this procedure outputs d, the value stored at location \(\ell \) in D. If \(v \in \{0,1\}\) the the procedure writes the value v to location \(\ell \) in D. \(\mathsf {OAccess}\) has oracle access (read and write) to \(D^*\) and changes made to it are preserved from one execution of \(\mathsf {OAccess}\) to another.

Efficiency. We require that the run-time of \(\mathsf {OData}\) should be \(m\cdot \mathsf {polylog}(m)\cdot \mathsf {poly}(\lambda )\), and the run-time of \(\mathsf {OAccess}\) should be \(\mathsf {poly}(\lambda )\cdot \mathsf {polylog}(m)\).

Correctness. Let \(\ell _1,\ldots ,\ell _t\) be locations accessed on memory D of size \(m\) and let \(v_1,\ldots , v_t\in \{0,1,\bot \}\). Then we require that on sequential executions of \(d_i= \mathsf {OAccess}^{D^*}(1^\lambda ,s, \ell _i, v_i)\) we have that for each \(i \in \{1,\ldots t\}\) such that \(v_i \ne \bot \) output \(d_i\) the correct and the latest value stored in location \(\ell _i\) of D.

Security. For security, we require that for any sequence of access locations \(\ell _1,\ldots ,\ell _t\) and \(\ell _1',\ldots ,\ell _t'\), in \(D\in \{0,1\}^m\), we have that:

$$\textsf {MemAccess} \approx \textsf {MemAccess}'$$

where \(\textsf {MemAccess}\) and \(\textsf {MemAccess}'\) correspond to the access pattern on \(D^*\) during the sequential execution of the \(\mathsf {OAccess}^{D^*}\) on input locations \(\ell _1,\ldots , \ell _t\) and \(\ell _1',\ldots ,\ell _t'\) respectively and \(\approx \) denotes computational indistinguishability.

2.4 Non-interactive Zero-Knowledge Proofs

We recall the definitions of non-interactive zero-knowledge proofs, taken verbatim from [GOS06].

Let R be an efficiently computable binary relation. For pairs \((x,w)\in R\) we call x the statement and w the witness. Let L be the language consisting of statements in R.

A non-interactive proof system [BFM88, FLS99, GOS06] for a relation R consists of a common reference string generation algorithm K, a prover P and a verifier V. We require that they all be probabilistic polynomial time algorithms, i.e., we are looking at efficient prover proofs. The common reference string generation algorithm produces a common reference string \(\sigma \) of length \(\varOmega (\lambda )\). The prover takes as input \((\sigma ,x,w)\) and produces a proof \(\pi \). The verifier takes as input \((\sigma ,x,\pi )\) and outputs 1 if the proof is acceptable and 0 otherwise. We call (KPV) a non-interactive proof system for R if it has the completeness and statistical-soundness properties described below.

Perfect completeness. A proof system is complete if an honest prover with a valid witness can convince an honest verifier. Formally we require that for all \((x,w) \in R\), for all \(\sigma \leftarrow K(1^\lambda )\) and \(\pi \leftarrow P(\sigma ,x,w)\) we have that \(V(\sigma ,x,\pi )=1.\)

Statistical soundness. A proof system is sound if it is infeasible to convince an honest verifier when the statement is false. For all (even unbounded) adversaries \(\mathcal {A}\) we have

Computational zero-knowledge [FLS99]. A proof system is computational zero-knowledge if the proofs do not reveal any information about the witnesses to a bounded adversary. We say a non-interactive proof (KPV) is computational zero-knowledge if there exists a polynomial time simulator \(\mathcal {S}= (\mathcal {S}_1,\mathcal {S}_2)\), such that for all non-uniform polynomial time adversaries \(\mathcal {A}\) with oracle access to the prover or the simulator for queries \((x,w) \in R\). Simulator is not provided with the witness w.

3 Modeling Incremental Obfuscation

In this section, we provide the definitions for incremental program obfuscation. As noted before, for concreteness, we describe our definitions for circuits. The definitions for Turing machines (TM) and RAM programs are obtained by simply replacing circuits with TM/RAMs. We start by providing indistinguishability-based definitions. Let us first set up some notation.

There are four operations we can perform on a bit b: \(\mathsf {set}(b)=1,\mathsf {reset}(b)=0,\mathsf {flip}(b)=1-b\) and \(\mathsf {id}(b)=b\); denote by \(\mathsf {OP}=\{\mathsf {set},\mathsf {reset},\mathsf {flip},\mathsf {id}\}\) the set of these operations. An incremental change to a string x of length n consists of specifying an (ordered) subset \(S\subseteq [n]\) of indices of x along with an (ordered) set of corresponding changes \(F_S=\{f_i\}_{i\in S}\) (where \(f_i\in \mathsf {OP}\), \(\forall i\in S\)). When we want to be explicit about \(F_S\), we denote the incremental change by \((S,F_S)\).

For a string x, \(F_S(x)\) denotes the string \(x'\) such that \(x'[i]=f_i(x[i])\) for every \(i\in S\) and \(x'[i]=x[i]\) otherwise. A sequence I of many updates is an ordered sequence of updates \(I=\left( (S_1,F_{S_1}),\ldots ,(S_t,F_{S_t})\right) \) When dealing with a sequence, we write \(F_I(x)\) to denote the sequence of strings \((x^1,\ldots ,x^t)\) where \(x^j\) is defined recursively as \(x^j:=F_{S_j}(x^{j-1})\) for all \(j\in [t]\) and \(x^0=x\).

If C is a circuit, represented as a binary string, I is a sequence of t updates to C, and x is an input string, we write \(F_I(C)(x)\) to denote the sequence \((C^1(x),\ldots ,C^t(x))\) where \((C^1,\ldots ,C^t)\mathop {=}\limits ^{\mathrm {def}}F_I(C)\).

3.1 Incremental Indistinguishability Obfuscation

As discussed earlier, our first definition, called \(\mathsf {IIO}\), simply requires that for every sequence of updates I, if I produces two functionally equivalent circuit sequences, then the updated sequence of obfuscated circuits corresponding to I should look indistinguishable. This is the weaker definition.

Definition 3

(Incremental Indistinguishability Obfuscator ( \(\mathsf {IIO}\) )). A pair of uniform PPT machines \((\mathcal {O},\mathsf {Update})\) is called an incremental indistinguishability obfuscator for a circuit class \(\{\mathcal {C}_\lambda \}\) if the following conditions are satisfied:

  • Syntax: \(\mathcal {O}\) takes as input a security parameter \(\lambda \) and a circuit \(C \in \mathcal {C}_\lambda \); it outputs an obfuscated circuit \(\widetilde{C}\) and a secret key sk (for making updates). \(\mathsf {Update}\) takes as input the secret-key sk, an incremental change \((S,F_S)\), and oracle access to \(\widetilde{C}\); it outputs an incremental change \((\widetilde{S},F_{\widetilde{S}})\) for the circuit \(\widetilde{C}\).

  • Correctness: For all security parameters \(\lambda \in \mathbb {N}\), for all \(C^0 \in \mathcal {C}_\lambda \), for all \(t\in \mathbb {N}\), for all sequences of incremental changes \(I=(S_1,\ldots ,S_t)\) defining the circuit sequence \(F_I(C)=(C^1,\ldots ,C^t)\), and for all inputs x, we have that

    where \(\mathsf {Update}^{\widetilde{C}^{0}}(sk,I)\) denotes the (recursively computed) sequence \((\widetilde{C}^1,\ldots ,\widetilde{C}^t)\) as follows: for every \(j\in [t]\) define \((\widetilde{S}_j,F_{\widetilde{S}_j}) \leftarrow \mathsf {Update}^{\widetilde{C}^{j-1}}(sk,S_j)\) and then \(\widetilde{C}^{j}=F_{{\widetilde{S}_j}}\left( \widetilde{C}^{j-1}\right) \).

  • Incrementality: There is a fixed polynomial \(\mathsf {poly}(\cdot ,\cdot )\), independent of the class \(\mathcal {C}_\lambda \), such that the running time of \(\mathsf {Update}^{\widetilde{C}}\big (sk,\big (\{i\},F_{\{i\}}\big )\big )\) over all possible values of \(\big (\lambda , \widetilde{C}, \big (\{i\},F_{\{i\}}\big ), sk\big )\) is at most \(\varDelta (\lambda )=\mathsf {poly}(\lambda , \lg |\widetilde{C}|)\). The incrementality of the scheme is defined to be \(\varDelta (\lambda )\).

  • Indistinguishability: For any (not necessarily uniform) PPT distinguisher D, there exists a negligible function \(\alpha \) such that the following holds: For all security parameters \(\lambda \in \mathbb {N}\), for all pairs of circuits \(C_0, C_1 \in \mathcal {C}_\lambda \), for every polynomial t and for every sequence I of t updates we have that if \(C_0(x) = C_1(x)\) and \(F_{I}(C_0)(x) = F_I(C_1)(x)\) for all inputs x, then

    where distribution \(\mathsf {Expt}(\lambda ,C_0,C_1,I,b)\) outputs as follows: sample \((\widetilde{C}_b,sk)\leftarrow \mathcal {O}(\lambda ,C_b)\), sample sequence \((\widetilde{C}^1_b,\ldots ,\widetilde{C}^t_b)\leftarrow \mathsf {Update}^{\widetilde{C}_{b}}(sk,I)\), and output \((I,C_0,C_1,\widetilde{C}_b,\widetilde{C}^{1}_b,\ldots ,\widetilde{C}^t_b)\).

The above definition does not necessarily hide the sequence I from the adversary. Our next definition, called increment-private \(\mathsf {IIO}\) hides the sequence of updates as well. Informally, it states that if update sequences \(I_0,I_1\) produce functionally equivalent circuit sequences, then the sequence of updated obfuscations hides whether \(I_0\) or \(I_1\) was used for making updates.

Definition 4

(Increment-private \(\mathsf {IIO}\mathbf{).}\) A pair of uniform PPT machines \((\mathcal {O},\mathsf {Update})\) is called a sequence hiding incremental indistinguishability obfuscator for a circuit class \(\{\mathcal {C}_\lambda \}\) if it satisfies the syntax, correctness and incrementality properties (as in Definition 3) and the following sequence-hiding indistinguishability property:

  • Increment-private indistinguishability: For any (not necessarily uniform) PPT distinguisher D, there exists a negligible function \(\alpha \) such that the following holds: For all security parameters \(\lambda \in \mathbb {N}\), for all pairs of circuits \(C_0, C_1 \in \mathcal {C}_\lambda \), for every polynomial t and for all pairs of update sequences \(I_0,I_1\) of length t we have that if \(C_0(x) = C_1(x)\) and \(F_{I_0}(C_0)(x) = F_{I_1}(C_1)(x)\) for all inputs x, then

    where distribution \(\mathsf {Expt}(\lambda ,C_0,C_1,I_0,I_1,b)\) outputs as follows: sample \((\widetilde{C}_b,sk)\leftarrow \mathcal {O}(\lambda ,C_b)\), sample sequence \((\widetilde{C}^1_b,\ldots ,\widetilde{C}^t_b)\leftarrow \mathsf {Update}^{\widetilde{C}_{b}}(sk,I_b)\), and output \((I_0,I_1,C_0,C_1,\widetilde{C}_b,\widetilde{C}^{1}_b,\ldots ,\widetilde{C}^t_b)\).

Finally, we define the following pristine updates property which is desirable but not implied by above definitions: updated obfuscation of a circuit should be statistically close to its fresh obfuscation.

Definition 5

(Pristine updates). An incremental indistinguishability obfuscator \((\mathcal {O},\mathsf {Update})\) for a circuit class \(\{\mathcal {C}_\lambda \}\) has pristine updates if there exists a negligible function \(\alpha \) such that \(\forall \lambda \in \mathbb {N}\), \(\forall C \in \mathcal {C}_\lambda \), and \(\forall (S,F_S)\), the statistical distance between distributions \(\{\widetilde{C}: (\widetilde{C},sk)\leftarrow \mathcal {O}(\lambda ,C)\}\) and \(\{\widetilde{C}': (\widetilde{C},sk)\leftarrow \mathcal {O}(\lambda ,C), (\widetilde{S},F_{\widetilde{S}})\leftarrow \mathsf {Update}^{\widetilde{C}}(sk,(S,F_S)), \widetilde{C}'=F_{\widetilde{S}}(\widetilde{C})\) is at most \(\alpha (\lambda )\).

3.2 Incremental \(\mathsf {VGB}\) and \(\mathsf {VBB}\) Obfuscation

The simulation based definitions are defined analogously, but require the existence of a simulator.

Definition 6

(Incremental \(\mathsf {VGB}\)/\(\mathsf {VBB}\) Obfuscator). A pair of uniform PPT machines \((\mathcal {O},\mathsf {Update})\) is called an incremental \(\mathsf {VGB}\) obfuscator for a circuit class \(\{\mathcal {C}_\lambda \}\) if it satisfies the syntax, correctness and incrementality properties (as in Definition 3) and the following VGB security property:

For any (not necessarily uniform) PPT (single bit) adversary A, there exists a simulator \(\mathcal {S}\), a polynomial q, and a negligible function \(\alpha \), such that the following holds: For all security parameters \(\lambda \in \mathbb {N}\), for all circuits \(C \in \mathcal {C}_\lambda \), for every polynomial t and for every sequence I of t updates, we have that,

where \((\widetilde{C},sk)\leftarrow \mathcal {O}(\lambda ,C)\), \((\widetilde{C}^1,\ldots ,\widetilde{C}^t)\leftarrow \mathsf {Update}^{\widetilde{C}}(sk,I)\), and notation \(C[q(\lambda )]\) (resp., \(F_I(C)[q(\lambda )]\)) represents at most q oracle calls to C (resp., every circuit in \((C,F_I(C))\)).

If \(\mathcal {S}\) is polynomial time in \(\lambda \), we say that \((\mathcal {O},\mathsf {Update})\) is incremental \(\mathsf {VBB}\) obfuscator for \(\{\mathcal {C}_\lambda \}\).

4 Our Construction

In this section, we present our basic construction which satisfies \(\mathsf {IIO}\) notion. Let:

  • (GED) be a PKE scheme for bits with ciphertext length \(\ell _e\),

  • \((\mathsf {Gen},H)\) be an SSB hash with alphabet \(\varSigma =\{0,1\}^{\ell _e}\) and output length \(\ell \),

  • \(\mathcal {O}\) be an \(\mathsf {IO}\) scheme for all circuits,

  • (KPV) be a NIZK proof system for NP

  • \(\mathsf {com}\) be a non-interactive perfectly binding string commitment scheme

The component algorithms of our \(\mathsf {IIO}\) scheme \((\mathsf {Inc}\mathcal {O},\mathsf {Update})\) are described in Figs. 1, 2 and 3.

Fig. 1.
figure 1

Description of \(\mathsf {Inc}\mathcal {O}\)

Fig. 2.
figure 2

Description of \(P_{hk,\sigma ,c_1,c_2,c_3,sk_1}\)

Fig. 3.
figure 3

Description of \(\mathsf {Update}\).

Theorem 1

Scheme \((\mathsf {Inc}\mathcal {O},\mathsf {Update})\) is an \(\mathsf {IIO}\) scheme for all circuits.

Proof

It is easy to verify the correctness and incrementality of this scheme. It is also easy to see that the scheme satisfies the pristine updates property.

We show that it satisfies the indistinguishability property. Fix any two circuits \((C_0,C_1)\), and any sequence I of any polynomial many incremental updates, say t updates. We need to show that \(\mathsf {Expt}(\lambda ,C_0,C_1,I,0)\equiv _c\mathsf {Expt}(\lambda ,C_0,C_1,I,0)\).

 

\(\mathcal {H}_1\)::

Same as \(\mathsf {Expt}(\lambda ,C_0,C_1,I,0)\). For convenience, let us define \(C_0^0=C_0\) and \(C_1^0=C_1\).

Recall that the output of this experiment is \((I,C^0_0,C^0_1,\widetilde{C}_0^0,\widetilde{C}_0^1,\ldots ,\widetilde{C}_0^t)\) where \(\widetilde{C}_0^i\) is of the form \((e^i,h^i,T^i,r^i,\pi _{h^i},\widetilde{P}_{hk,\sigma ,c_1,c_2,c_3,sk_1})\) and \(e^i=(e^i_{1},e^i_{2})\) represents two (bitwise) encryptions of \(C_0^i\) under keys \(pk_1\) and \(pk_2\) respectively.

\(\mathcal {H}_{1.5}\)::

Same as \(\mathcal {H}_{1}\) except that the CRS \(\sigma \) and all NIZK proofs are obtained from the simulator, i.e., values \((\sigma ,\pi _{h^1},\ldots ,\pi _{h^t})\) are sampled using the simulator. The distinguishing advantage from \(\mathcal {H}_{1}\) is at most \(t\delta _{\mathrm {nizk}}\).

\(\mathcal {H}_2\)::

This hybrid tests \(|r+t|\le \ell \) (i.e., \(r+t\le 2^\ell -1\)), and if so, it sets for \(t_1=r\) and \(t_2=r+t\), instead of \(0^\ell \Vert 1^\ell \), and continues as \(\mathcal {H}_2\). If the test fails, it aborts. The advantage in distinguishing \(\mathcal {H}_2\) and \(\mathcal {H}_3\) is at most \(\delta _{\mathsf {com}}+t2^{-\ell }\) where \(\delta _\mathsf {com}\) is the distinguishing advantage for \(\mathsf {com}\). This is because of the following: value \(r+t>2^\ell \) for a randomly chosen r if and only if \(r\in [2^\ell -t,2^\ell ]\) which happens with probability \(t2^{-\ell }\); if the test succeeds, the hybrids differ only in commitment \(c_3\).

This hybrid ensures that there are no valid proofs other than the \(t+1\) proofs that are given as part of the obfuscation and the updates.

\(\mathcal {H}_{2.5}\)::

Same as \(\mathcal {H}_{2}\) except that the CRS \(\sigma \) and all NIZK proofs \((\pi _{h^1},\ldots ,\pi _{h^t})\) are now generated normally using the appropriate witness (instead of being simulated). Note that the hybrid indeed does have the appropriate witnesses to complete this step normally, and the distinguishing advantage from \(\mathcal {H}_{2}\) is at most \(t\delta _{\mathrm {nizk}}\).

\(\mathcal {H}_3\)::

This hybrid is identical to \(\mathcal {H}_{2.5}\) except that it generates the components \(\{e^i_2\}\) by (bitwise) encrypting the sequence of circuits corresponding \(C_1\), namely \(\{C^i_1\}\) (instead of \(\{C^i_0\}\)) for every \(i\in [t]\). That is, for ever \(i\in [t]\), it computes \(\widetilde{C}_0^i\) to be of the form \((e^i,h^i,T^i,\pi _{h^i},\widetilde{P}_{hk,\sigma ,c_1,c_2,c_3,sk_1})\) as before where \(e^i=(e^i_{1},e^i_{2})\) and \(e^i_{1}\) is a bitwise encryption of \(C^i_0\) under \(pk_1\) obtained via updates but (also obtained via updates). The advantage in distinguishing \(\mathcal {H}_{2.5}\) and \(\mathcal {H}_{3}\) is at most \(t\cdot |C_0|\cdot \delta _\mathrm {pke}\) where \(\delta _{\mathrm {pke}}\) denotes the advantage in breaking the security of PKE scheme. This claim is straightforward.

\(\mathcal {H}_4\)::

Identical to \(\mathcal {H}_3\) except that instead of obfuscating circuit \(P_{hk,\sigma ,c_1,c_2,c_3,sk_1}\), it obfuscates the following circuit \(P2_{hk,\sigma ,c_1,c_2,c_3,sk_2}\) Footnote 2, padded to the size Q: Circuit \(P2_{hk,\sigma ,c_1,c_2,c_3,sk_2}(e,v,\pi ,x)\) :

1.:

Compute \((h,T)=H_{hk}(e)\) and verify that \(V(\sigma ,(h,v,c_1,c_2,c_3),\pi ) = 1\).

Output \(\bot \) if verification fails.

2.:

Otherwise, parse e as \((e_1,e_2)\), , and output C(x).

Let \(\delta _4\) denote the distinguishing advantage of any polynomial time distinguisher between \(\mathcal {H}_{4}\) and \(\mathcal {H}_3\). From lemma 1, \(\delta _4\le 4t^2|C_0|\cdot \left( \delta _{\mathrm {ssb}}+\delta _{\mathrm {nizk}}+\delta _{\mathsf {com}}+\delta _{\mathsf {IO}}\right) \) where quantities \(\delta _{\mathrm {ssb}}, \delta _{\mathrm {nizk}}\), and \(\delta _{\mathsf {IO}}\) denote the distinguishing advantage for SSB hash, NIZK proofs, and \(\mathsf {IO}\) respectively.

\(\mathcal {H}_{5}\)::

Same as \(\mathcal {H}_4\) except that it generates ciphertexts (instead of \(C^i_0\)) \(\forall i\in [t]\). That is, for every \(i\in [t]\), it computes \(\widetilde{C}_0^i\) to be of the form \((e^i,h^i,T^i,\pi _{h^i},\widetilde{P2}_{hk,\sigma ,c_1,c_2,c_3,sk_2})\) where \(e^i=(e^i_{1},e^i_{2})\) and \(e^i_{1},e^i_2\) are (bitwise) encryptions of \(C^i_1\) under \(pk_1,pk_2\) respectively. Note that these encryptions are actually obtained via updates.

The distinguishing advantage between \(\mathcal {H}_5\) and \(\mathcal {H}_4\) is at most \(t|C_0|\delta _{\mathrm {pke}}\). This is straightforward.

\(\mathcal {H}_{6}\)::

Same as \(\mathcal {H}_{5}\) except that it obfuscates circuit \(P_{hk,\sigma ,c_1,c_2,c_3,sk_1}\) (which uses \(sk_1\) and decrypts from \(e_1\), see Fig. 2) instead of \(P2_{hk,\sigma ,c_1,c_2,c_3,sk_2}\).

Let \(\delta _6\) denote the distinguishing advantage between \(\mathcal {H}_{6}\) and \(\mathcal {H}_5\). We claim that \(\delta _6\le 4t^2|C_0|\cdot \left( \delta _{\mathrm {ssb}}+\delta _{\mathrm {nizk}}+\delta _{\mathsf {com}}+\delta _{\mathsf {IO}}\right) \). The proof is identical to that of lemma 1 and omitted.

\(\mathcal {H}_{7}\)::

Same as \(\mathcal {H}_6\) but now \(c_3\) is switched back to a commitment of \(0^\ell \Vert 1^\ell \) instead of \(t_1 \Vert t_2\). Recall that \(t_1=r,t_2=r+t\).

The distinguishing advantage between \(\mathcal {H}_7\) and \(\mathcal {H}_6\) is at most \(\delta _\mathsf {com}+t2^{-\ell }\) (as argued in \(\mathcal {H}_2\)).

 

Observe that \(\mathcal {H}_7\) is the same as experiment \(\mathsf {Expt}(\lambda ,C_0,C_1,I,1)\). The total distinguishing advantage is thus bounded by \(O\big (t^2\cdot |C_0|\cdot \big (\delta _{\mathrm {pke}}+\delta _{\mathrm {nizk}}\) \(+\delta _{\mathrm {ssb}}+\delta _\mathsf {com}+2^{-\ell }\big )\big )\) which is negligible.

Lemma 1

\(\delta _4\le 4t^2|C_0|\cdot \left( \delta _{\mathrm {ssb}}+\delta _{\mathrm {nizk}}+\delta _{\mathsf {com}}+\delta _{\mathsf {IO}}\right) \).

Proof

The lemma is proven by focusing on one of the t locations in the sequence at a time, and use the properties of SSB hash, to slowly reach a point where there is a unique value of e corresponding to the hash value at this location. All values prior to this location will use \(sk_2\) and \(e_2\), whereas those after it will use \(sk_1,e_1\).

More precisely, we describe t hybrids \(\mathcal {G}_1,\ldots ,\mathcal {G}_t\) where hybrid \(\mathcal {G}_j\) will use \(sk_2\) on inputs with value v if \(r\le v<r+j\), and \(sk_1\) if \(r+j\le v\le r+t\). Note that v is always in the range \([r,r+t]\) in this hybrid. To prove that \(\mathcal {G}_{j-1}\) and \(\mathcal {G}_{j}\) are indistinguishable, we will design another \(4+2|C_0|\) hybrids where we will first ensure the uniqueness of \((j,h^j)\) and then perform SSB hash translation to move to \(\mathcal {G}_j\).

Formally, define \(\mathcal {G}_0\) to be the same as \(\mathcal {H}_3\), and for \(j\in [t]\) define hybrid \(\mathcal {G}_j\) as follows: it is identical to \(\mathcal {G}_{j-1}\) except that it obfuscates the circuit \(P_{hk,\sigma ,c_1,c_2,c_3,r,sk_1,sk_2,j}\) described in Fig. 4 (instead of \(P_{hk,\sigma ,c_1,c_2,c_3,r,sk_1,sk_2,j-1}\)).Footnote 3

Note that r was chosen uniformly in step 6 of the construction and the size of \(P_{hk,\sigma ,c_1,c_2,c_3,r,sk_1,sk_2,j}\) is padded to the value Q before obfuscation.

Let \(\varepsilon _j\) denote the distinguishing advantage between \(\mathcal {G}_{j}\) and \(\mathcal {G}_{j-1}\). Observe that \(\mathcal {G}_t\) is the same as \(\mathcal {H}_4\) and \(\delta _4\le \sum _j\varepsilon _j\). We now prove that \(\varepsilon _j\le 4t|C_0|\cdot \left( \delta _{\mathrm {ssb}}+\delta _{\mathrm {nizk}}+\delta _{\mathsf {com}}+\delta _{\mathsf {IO}}\right) \).

Consider the following hybrids:

 

\(\mathcal {G}_{j:1}\)::

Same as \(\mathcal {G}_{j-1}\) except that the CRS \(\sigma \) and all NIZK proofs are obtained from the simulator, i.e., values \((\sigma ,\pi _{h^1},\ldots ,\pi _{h^t})\) are sampled using the simulator. The distinguishing advantage from \(\mathcal {G}_{j-1}\) is at most \(t\delta _{\mathrm {nizk}}\).

\(\mathcal {G}_{j:2}\)::

Same as \(\mathcal {G}_{j:1}\) except that commitments \(c_1\) and \(c_2\) are changed as follows. Let \(e^j\) denote the encryptions corresponding to the j-th update in the sequence, and let \(h^j=H_{hk}(e^j)\). Then, \(c_1\) is set to be a commitment to \(h^j\) and \(c_2\) a commitment to \(r+j\): \(c_1=\mathsf {com}(h^j;\omega _1),c_2=\mathsf {com}(r+j;\omega _2)\). The distinguishing advantage from \(\mathcal {G}_{j:1}\) is at most \(\delta _{\mathsf {com}}\).

\(\mathcal {G}_{j:3}\)::

Same as \(\mathcal {G}_{j:2}\) except that the CRS \(\sigma \) and all NIZK proofs \((\pi _{h^1},\ldots ,\pi _{h^t})\) are now generated normally using the appropriate witness (instead of being simulated). Note that the hybrid indeed does have the appropriate witnesses to complete this step normally, and the distinguishing advantage from \(\mathcal {G}_{j:2}\) is at most \(t\delta _{\mathrm {nizk}}\).

 

Fig. 4.
figure 4

Description of \(P_{hk,\sigma ,c_1,c_2,c_3,sk_1,j}\)

At this point, for location j, there exists only one value of \(h^j\) that can produce convincing proofs (from the soundness of NIZK). Next, we will use the SSB hash to reach a point where only the string \(e^j\) will be accepted by the obfuscated circuit as the valid input corresponding to hash \(h^j\). We do this in a series of \(2|C_0|\) hybrids corresponding to the \(2|C_0|\) encryptions occurring in \(e^j=(e^j_1,e^j_2)\).

Formally, for every \(m=1,\ldots ,2|C_0|\), we define two hybrids \(\mathcal {G}^{m:1}_{j:3}, \mathcal {G}^{m:2}_{j:3}\) below. Let \(e_m^*\) denote the string which identical to \(e^j\) in the first m blocks, each of length \(\ell _e\), and 0 everywhere else. For convention, let \(\mathcal {G}^{0:2}_{j:3}\) be the same as \(\mathcal {G}_{j:3}\). Then:

 

\(\mathcal {G}^{m:1}_{j:3}\)::

Same as \(\mathcal {G}^{m-1:2}_{j:3}\) except that it makes hk to be binding at m, i.e., \(hk\leftarrow \mathsf {Gen}(1^\lambda ,1^{\ell _e},|e|,m)\).

\(\mathcal {G}^{m:2}_{j:3}\)::

Let us recall that we started with hybrid \(\mathcal {G}_{j-1}\) which obfuscates the circuit \(P_{hk,\sigma ,c_1,c_2,c_3,sk_1,sk_2,j-1}\). This hybrid proceeds just like \(\mathcal {G}^{m:1}_{j:3}\) except that it obfuscates the circuit \(P^{m,e_m^*}_{hk,\sigma ,c_1,c_2,c_3,sk_1,sk_2,j-1}\) described below.

Circuit \(P^{m,e_m^*}_{hk,\sigma ,c_1,c_2,c_3,sk_1,sk_2,j-1}(e,v,\pi ,x)\) :

1.:

If the first m blocks of e and \(e_m^*\) are not the same, output \(\bot \).

2.:

Otherwise output \(P_{hk,\sigma ,c_1,c_2,c_3,sk_1,sk_2,j-1}(e,v,\pi ,x)\) (see Fig. 4).

 

The distinguishing advantage between \(\mathcal {G}^{m-1:2}_{j:3}\) and \(\mathcal {G}^{m:1}_{j:3}\) is at most \(\delta _{\mathrm {ssb}}\), and between \(\mathcal {G}^{m:1}_{j:3}\) and \(\mathcal {G}^{m:2}_{j:3}\) is at most \(\delta _{\mathrm {\mathsf {IO}}}\).

When \(m=2|C_0|\), the circuit \(P^{m,e_m^*}_{hk,\sigma ,c_1,c_2,c_3,sk_1,sk_2,j}\) accepts only \(e^*_{2|C_0|}=e^j\) as the input for location j in the sequence and all other inputs are rejected. We can now safely change this program to use \(sk_2\) to decrypt \(e^j_2\) at location j (instead of \(e^j_1\)). More precisely, we consider the hybrid:  

\(\mathcal {G}_{j:4}\) :

Same as \(\mathcal {G}^{2|C_0|:2}_{j:3}\) except that it obfuscates a circuit which, in location j, decrypts from \(e^j_2\). More precisely, it obfuscates the following circuit:

Circuit \(P^{e^j}_{hk,\sigma ,c_1,c_2,c_3,sk_1,sk_2,j-1}(e,v,\pi ,x)\) :

1.:

If \(e\ne e^j\), output \(\bot \).

2.:

Otherwise output \(P_{hk,\sigma ,c_1,c_2,c_3,sk_1,\underline{sk_2,j}}(e,v,\pi ,x)\) (see Fig. 4).

 

The distinguishing advantage from previous hybrid is at most \(\delta _\mathsf {IO}\).

Our goal is now to get rid of the first condition, so that we switch back to only obfuscating \(P_{hk,\sigma ,c_1,c_2,c_3,sk_1,sk_2,j}\). This is performed by simply reversing the steps in m hybrids. Furthermore, we also reverse the changes made in the commitment in a sequence of 3 hybrids by considering the reverse of hybrids \(\mathcal {G}_{j:3},\mathcal {G}_{j:2},\mathcal {G}_{j:1}\). The resulting hybrid would essentially be identical to \(\mathcal {G}_j\). We omit these details.

The total distinguishing advantage between \(\mathcal {G}_{j}\) and \(\mathcal {G}_{j-1}\) is bounded by the sum of all advantages, which is at most \(4t|C_0|\left( \delta _\mathsf {com}+ \delta _\mathrm {nizk} + \delta _\mathrm {ssb} + \delta _\mathsf {IO}\right) \). This completes the proof.

Size Q: The value of Q is defined to be the size of the program \(P^{e^j}_{hk,\sigma ,c_1,c_2,c_3,sk_1,sk_2,j-1}\) described above (for any value of j, say \(j=1\)).

Construction for Turing machines and RAM programs. As mentioned earlier, our constructions are quite independent of the underlying model of computation. For example, to obtain construction for the class of bounded-input Turing machines, we use the same construction as in Fig. 1 except that the obfuscator \(\mathcal {O}\) for circuits in (step 7) will now be an obfuscator for the class of bounded-input Turing machines since the program in Fig. 2 will now be a bounded-input Turing machine. Likewise, we also obtain constructions for RAM programs and unbounded-input Turing machines assuming the existence of \(\mathsf {IO}\) for the same. This gives us the following theorem.

Theorem 2

If there exists indistinguishability obfuscation for a class of programs \(\mathcal {P}=\{P_\lambda \}\) modeled as either boolean circuits, or (bounded/unbounded input) Turing machines, or RAM programs, then there exists incremental indistinguishability obfuscation (\(\mathsf {IIO}\), Definition 3) for \(\mathcal {P}\).

5 Amplifying Security to Increment-Private \(\mathsf {IIO}\)

In this section, we present our (black-box) transformation which transform an \(\mathsf {IIO}\) scheme (Definition 3) into an increment-private \(\mathsf {IIO}\) scheme (Definition 4). As before, for concreteness, we present our transformation for circuits, but it works for Turing machines and RAM programs as well. Our transformation preserves the pristine updates property as well (Definition 5).

As discussed in the overview, the construction consists of applying the ORAM encoding on the given circuit twice. These encodings are then hardwired into a program, along with the secret information for decoding only one of the two ORAM encodings. This is essentially the two-key paradigm [NY90] implemented with ORAM. The resulting program is then obfuscated using the given \(\mathsf {IIO}\) scheme. In addition to the encodings and secret information, the program is also provided with a bit b as well as some more information which tells the program which ORAM encoding to pick for evaluation. This is helpful in designing the hybrid experiments.

Our construction. Let \((\mathcal {O},\mathsf {Update})\) be an \(\mathsf {IIO}\) scheme for the class of all circuits. Let \((\mathsf {OData}, \mathsf {OAccess})\) be an oblivious RAM scheme as described in Sect. 2.3. Our new scheme consists of algorithms \((\mathcal {O}',\mathsf {Update}')\) described in Fig. 5.Footnote 4

Fig. 5.
figure 5

Description of \(\mathcal {O}'\) and \(\mathsf {Update}'\).

Theorem 3

Scheme \((\mathcal {O}',\mathsf {Update}')\) is increment-private \(\mathsf {IIO}\) for all circuits (Definition 4).

Proof

The correctness and the pristine updates property of our construction follows directly from the correctness and the pristine updates property of the underlying \(\mathsf {IIO}\) scheme. We argue the increment-private indistinguishability property of our construction.

We have to show that for any (not necessarily uniform) PPT distinguisher D, there exists a negligible function \(\alpha \) such that the following holds: For all security parameters \(\lambda \in \mathbb {N}\), for all pairs of circuits \(C_0, C_1 \in \mathcal {C}_\lambda \), for every polynomial t and for all pairs of update sequences \(I_0,I_1\) of length t we have that if \(C_0(x) = C_1(x)\) and \(F_{I_0}(C_0)(x) = F_{I_1}(C_1)(x)\) for all inputs x, then

where distribution \(\mathsf {Expt}(\lambda ,C_0,C_1,I_0,I_1,b)\) outputs as follows: (1) Sample \((C^*_1,s_1) \leftarrow \mathsf {OData}(1^\lambda ,C_b)\) and \((C^*_2,s_2) \leftarrow \mathsf {OData}(1^\lambda ,C_b)\). (2) Sample \((\widetilde{C},sk)\leftarrow \mathcal {O}(\lambda ,P_{C^*_1,C^*_2,1,s_1})\) and the sequence \((\widetilde{C}^1,\ldots ,\widetilde{C}^t)\leftarrow \mathsf {Update}^{\widetilde{C}_{}}(sk,J)\), and output \((I_0,I_1,C_0,C_1,\widetilde{C},\widetilde{C}^{1},\ldots ,\widetilde{C}^t)\). Here \(J = (S_{1},\ldots , S_{t})\) is obtained from \(I_b = (S_{b,1}',\ldots S_{b,t}')\) as follows (also described in Fig. 5). For each \(j \in \{1,\ldots t\}\), set \(S'_b = S_{b,j}'\) and proceed as follows.

  1. 1.

    \(F_{S'_b}\) be the changes corresponding to \(S'_b\). For each \(i \in S'_b\) proceed as follows:

    1. (a)

      Let \(d_i := \mathsf {OAccess}^{C^*_1}(1^\lambda ,s,i,\bot )\) and execute \(\mathsf {OAccess}^{C^*_1}(1^\lambda ,s,i,f_i(d_i))\).

    2. (b)

      Similarly, let \(d_i' := \mathsf {OAccess}^{C^*_2}(1^\lambda ,s,i,\bot )\) and execute \(\mathsf {OAccess}^{C^*_2}(1^\lambda ,s,i,f_i(d_i'))\).

  2. 2.

    Let S be the set of locations where \(P_{C^*_1, C^*_2, 1,s_1}\) is touched as \(C^*_1\) and \(C^*_2\) are processed as aboveFootnote 5 and \(F_S\) be the corresponding changes.

  3. 3.

    Output \({\mathsf {Update}}^{\widetilde{C}}(uk, S)\) as \(S_j\).

To prove the claim, consider the following sequence of hybrids:  

\(\mathcal {H}_1\)::

This hybrid corresponds to the output of the experiment \(\mathsf {Expt}(\lambda ,C_0,C_1,I_0,I_1,0)\) as above.

\(\mathcal {H}_2\)::

In this hybrid we change Step 5 in the experiment above. In particular we instead of changing stored value to \(f_i(d_i)\) we always set it to zero. More formally, the procedure is changed as follows.

(a):

\(F_{S'_b}\) be the changes corresponding to \(S'_b\). For each \(i \in S'_0\) proceed as follows:

i,:

Let \(d_i := \mathsf {OAccess}^{C^*_1}(1^\lambda ,s,i,\bot )\) and execute \( \mathsf {OAccess}^{C^*_1}(1^\lambda ,s,i,\) \(f_i(d_i))\).

ii.:

Similarly, let \(d_i' := \mathsf {OAccess}^{C^*_2}(1^\lambda ,s,i,\bot )\) and execute ).

(b):

Let S be the set of locations where \(P_{C^*_1, C^*_2, 1,s_1}\) is touched as \(C^*_1\) and \(C^*_2\) are processed as above and \(F_S\) be the corresponding changes.

(c):

Output \({\mathsf {Update}}^{\widetilde{C}}(uk, S)\) as \(S_j\).

Indistinguishability follows from the security of the \(\mathsf {IIO}\) scheme. Here we use the property that any changes made to \(C^*_2\) do not affect the functionality of the program \(P_{C_1^*,C_2^*, 1, s_1}\).

\(\mathcal {H}_3\)::

In this hybrid we again change Step 5 in the experiment above. In particular, we make changes to \(C_2^*\) at locations \(S'_1\) instead of \(S'_0\). As in \(\mathcal {H}_1\) we still set these locations to zero when the change is made. More formally:

(a):

\(F_{S'_b}\) be the changes corresponding to \(S'_b\). For each \(i \in S'_0\) proceed as follows:

i.:

Let \(d_i := \mathsf {OAccess}^{C^*_1}(1^\lambda ,s,i,\bot )\) and execute \( \mathsf {OAccess}^{C^*_1}(1^\lambda ,s,i,\) \(f_i(d_i))\).

ii.:

Similarly, let and execute .

(b):

Let S be the set of locations where \(P_{C^*_1, C^*_2, 1,s_1}\) is touched as \(C^*_1\) and \(C^*_2\) are processed as above and \(F_S\) be the corresponding changes.

(c):

Output \({\mathsf {Update}}^{\widetilde{C}}(uk, S)\) as \(S_j\).

Indistinguishability follows from the security of the oblivious RAM scheme (as in Sect. 2.3).

\(\mathcal {H}_4\)::

In this hybrid we change how \(C_2^*\) is generated and the changes that are made while the increments are performed. More formally:

We generate \((C^*_2,s_2)\) by executing . Additionally the increments are not set using \(I_1\) instead of \(I_0\) as follows:

(a):

\(F_{S'_b}\) be the changes corresponding to \(S'_b\). For each \(i \in S'_0\) and \(k \in S_1'\) proceed as follows:

i.:

Let \(d_i := \mathsf {OAccess}^{C^*_1}(1^\lambda ,s,i,\bot )\) and execute \( \mathsf {OAccess}^{C^*_1}(1^\lambda ,s,i,f_i(d_i))\).

ii.:

Similarly, let \({d_k'} := \mathsf {OAccess}^{C^*_2}(1^\lambda ,s,{k},\bot )\) and execute .

(b):

Let S be the set of locations where \(P_{C^*_1, C^*_2, 1,s_1}\) is touched as \(C^*_1\) and \(C^*_2\) are processed as above and \(F_S\) be the corresponding changes.

(c):

Output \({\mathsf {Update}}^{\widetilde{C}}(uk, S)\) as \(S_j\).

Indistinguishability follows from the security of the \(\mathsf {IIO}\) scheme. Here we use the property that any changes made to \(C^*_2\) do not affect the functionality of the program \(P_{C_1^*,C_2^*, 1, s_1}\).

\(\mathcal {H}_5\)::

In this hybrid instead of outputting an obfuscation of \(P_{C^*_1,C^*_2,1,s_1}\) we output and obfuscation of .

Indistinguishability follows from the security of the \(\mathsf {IIO}\) scheme. Here we use the property that for all x we have that \(C_0(x) = C_1(x)\) and \(F_{I_0}(C_0)(x) = F_{I_1}(C_1)(x)\). This in particular implies that \(P_{C_1^*,C_2^*,1,s_1}(x) = P_{C_1^*,C_2^*,2,s_2}(x)\) and \(F_{J}(P_{C_1^*,C_2^*,1,s_1})(x) = F_{J}(P_{C_1^*,C_2^*,2,s_2})(x)\) where \(J = (S_1,\ldots S_t)\) as obtained in the previous hybrid.

 

Observe that at this point we can reverse the hybrids presented above and obtain the distribution \(\mathsf {Expt}(\lambda ,C_0,C_1,I_0,I_1,1)\). This proves our claim.

As before, this transformation is not specific to circuits. In particular, if \((\mathcal {O},\mathsf {Update})\) is a scheme for Turing machines or RAM programs, then \((\mathcal {O}',\mathsf {Update}')\) is increment-private \(\mathsf {IIO}\) for the same model. Thus, our transformation, together with Theorem 2, gives the following result.

Theorem 4

If there exists indistinguishability obfuscation for a class of programs \(\mathcal {P}=\{P_\lambda \}\) modeled as either boolean circuits, or (bounded/unbounded input) Turing machines, or RAM programs, then there exists increment-private indistinguishability obfuscation (Definition 4) for \(\mathcal {P}\).

6 The Lower Bound

Point functions. Let \(\mathcal {I}_n=\{I_x\}_{x\in \{0,1\}^n}\) denote the family of point functions for points in \(\{0,1\}^n\) where n is a (potentially large) polynomial in \(\lambda \). Function \(I_x\) takes as input \(y\in \{0,1\}^n\) and outputs 1 if \(y=x\) and 0 otherwise.

\(\mathsf {VBB}\) obfuscation schemes for \(\mathcal {I}_n\) are known to exist [Wee05, Can97, BS16] under standard assumptions such as variants of one-way permutation or DDH. We show that even for a family as simple as \(\mathcal {I}_n\), incremental \(\mathsf {VBB}\) obfuscation (corresponding to our efficiency requirements) does not exist. In fact, we rule this out even for \(\mathsf {VGB}\) obfuscation, which is weaker than \(\mathsf {VBB}\); this strengthens our result.

More specifically, we show that the update algorithm of every incremental VGB obfuscation for \(\mathcal {I}_n\) must change \(\varOmega (n/\mathrm{log}\,n)\) bits for a large fraction of functions \(I_x\in \mathcal {I}_n\) even if only one bit changes in x.

Theorem 5

Every \(\mathsf {VGB}\) obfuscation scheme for \(\mathcal {I}_n\) must have incrementality \(\varDelta \in \varOmega (n/\mathrm{log}\,n)\).

Proof

Let \((\mathcal {O},\mathsf {Update})\) be a \(\mathsf {VGB}\) obfuscation scheme for \(\mathcal {I}_n\) with incrementality \(\varDelta \). Let \(\lambda \) be the security parameter so that \(n=n(\lambda )\ge \lambda \) is a polynomial determining the length of points in \(\mathcal {I}_n\), and \(\varDelta \) is a function of \(\lambda \).

The proof proceeds by showing that incrementality “leaks” Hamming distance between updated obfuscations, which, by definition, cannot be leaked by \(\mathsf {VGB}\) obfuscation. Formally, define the following two distributions:

  • \(\mathcal {D}_1:\) Obtain obfuscations for programs \(I_x\) and \(I_{x'}\) for a random x by obfuscating \(I_x\) and updating it for \(I_{x'}\) where \(x,x'\) differ in only one position, say first. I.e., sample \(x\leftarrow \{0,1\}^n\), \(\widetilde{I}_x \leftarrow \mathcal {O}(I_x)\), \(\widetilde{I}_{x'}\leftarrow \mathsf {Update}^{\widetilde{I}_x}(1^\lambda ,uk,\{1,{\mathsf {flip}}\})\), and output \((\widetilde{I_x},\widetilde{I}_{x'})\).

  • \(\mathcal {D}_2:\) Return obfuscations of two random points \(y_1,y_2\) through update. I.e., sample \(y_1,y_2\) uniformly, and obtain \(\widetilde{I}_{y_1}\leftarrow \mathcal {O}(I_{y_1})\). Let \(\delta \) denote the set of locations where \(y_1,y_2\) differ corresponding to the function \(\mathsf {flip}\). Then, obtain \(\widetilde{I}_{y_2}\leftarrow \mathsf {Update}^{\widetilde{I}_{y_1}}(1^\lambda ,\delta )\).

Next, define the following adversarial algorithm:

  • Algorithm A: on input two strings \((\widetilde{I}_1,\widetilde{I}_2)\), A outputs 1 if the Hamming distance between \(\widetilde{I}_1,\widetilde{I}_2\) is at most \(\varDelta \); otherwise A outputs 0.

By definition of \(\mathsf {VGB}\) security, there exists a simulator S, a polynomial q, and a negligible function \(\alpha \) such that S can simulate the output of A (on any two obfuscated circuits) by making at most q queries to the corresponding circuits. Note that this simulator S cannot distinguish the two cases above as it is only give oracle access to the programs.

Let us consider the output of A on input \((\widetilde{I}_x,\widetilde{I}_{x'})\) sampled from \(\mathcal {D}_1\). Due to the incrementality of the scheme, these inputs differ in at most \(\varDelta \) locations, and hence A outputs 1 with probability 1.

Next, consider the output of A on input \((\widetilde{I}_{y_1},\widetilde{I}_{y_2})\) sampled from \(\mathcal {D}_2\). We note that for any choice of randomness of the obfuscator the Hamming distance between \(\widetilde{I}_{y_1}, \widetilde{I}_{y_2}\) cannot be less than than the \(\varOmega (n/\mathrm{log}\,n)\). More formally, for a choice of random coins, the obfuscator is an injective function from \(2^n\) points to an obfuscation of m bits were \(m=n^c\) for constant c. Then we claim that the two obfuscations (for random \(y_1\) and \(y_2\)) differ by at least \(\varOmega (n/\mathrm{log}\,n)\) bits. If this was not the case then we could encode the two random points \(x_1, x_2\) in o(2n) bits which is impossible. In particular, we could perform the encoding by giving \(x_1\) and the update of obfuscation from \(x_1\) to \(x_2\). If the hamming distance between the obfuscations of \(x_1\) and \(x_2\) is \(t = o(n/\mathrm{log}\,n)\) then we have that this change can be encoded in \(\log \left( {\begin{array}{c}m\\ t\end{array}}\right) \) which is at most \(\log ((n^c)^t)< c.o(n/\log n).\log n < o(n)\). Therefore, we conclude that \(\varDelta \in \varOmega (n/\mathrm{log}\,n)\).

7 Best Possible Incremental Obfuscation

Our lower bound on the incrementality of \(\mathsf {VGB}\)/\(\mathsf {VBB}\) obfuscations demonstrates that any incremental scheme must leak the size of incremental updates that take place. An interesting question is if this is all that is leaked. In particular, we investigate the possibility of realizing weaker simulation-based notions which allow for leakage of the size of the incremental updates.

However, a notion along these lines leaves a lot unexplained. For example, it is not clear if such an effort would yield a meaningful notion for general programs. Motivated by such issues and inspired by the notion of “best possible obfuscation” [GR07] for the single use setting, we define the notion of “best possible incremental obfuscation” or \(\mathsf {IBPO}\).

Definition 7

(Incremental Best Possible Obfuscator \(\mathbf{(}\mathsf {IBPO}{} \mathbf{).}\) A pair of uniform PPT machines \((\mathcal {O},\mathsf {Update})\) is called an incremental BPO obfuscator for a circuit class \(\{\mathcal {C}_\lambda \}\) if it satisfies the syntax, correctness and incrementality properties (as in Definition 3) and the following best possible obfuscation property:

For any (not necessarily uniform) PPT adversaries A, there exists a simulator \(\mathcal {S}\) and a negligible function \(\alpha \), such that the following holds: For all security parameters \(\lambda \in \mathbb {N}\), for all pairs of circuits \(C_1, C_2 \in \mathcal {C}_\lambda \) (with \(|C_1| = |C_2|\)), for every polynomial t and for all pairs of update sequences \(I_0,I_1\) (with \(S_{0,i} = S_{1,i}\) for each \(i \in \{1,\ldots , t\}\)) of length t we have that if \(C_0(x) = C_1(x)\) and \(F_{I_0}(C_0)(x) = F_{I_1}(C_1)(x)\) for all inputs x, then

where \((\widetilde{C}_0,sk)\leftarrow \mathcal {O}(\lambda ,C_0)\), and \((\widetilde{C}^1_0,\ldots ,\widetilde{C}^t_0)\leftarrow \mathsf {Update}^{\widetilde{C}_{0}}(sk,I_0)\).

Informally, this definition guarantees that any information that can be efficiently obtained from the obfuscation \(\widetilde{C}_0\) along with the obfuscation increments \(\widetilde{C}^1_0,\ldots ,\widetilde{C}^t_0\), can also be extracted efficiently (i.e., simulated) from any equivalent circuit of a similar size \(C_1\) and corresponding equivalent updates \(I_1\) of similar size. We now prove the following theorem.

Theorem 6

\((\mathcal {O},\mathsf {Update})\) is incremental BPO obfuscator for a circuit class \(\{\mathcal {C}_\lambda \}\) if and only if it is increment-private \(\mathsf {IIO}\) obfuscator for \(\{\mathcal {C}_\lambda \}\).

Proof Sketch:

We need to prove that an \(\mathsf {IBPO}\) scheme is also a increment-private \(\mathsf {IIO}\) scheme and the other way around. We start with the first direction.

By the definition of best possible obfuscation we have that the distributions \(A(\widetilde{C}_0,\widetilde{C}^1_0,\ldots ,\widetilde{C}^t_0)\) and \(\mathcal {S}(C_1, I_1)\) are close. Similarly the distributions \(A(\widetilde{C}_1,\widetilde{C}^1_1,\ldots ,\widetilde{C}^t_1)\) and \(\mathcal {S}(C_1, I_1)\) are close. In the above expressions for \(b \in \{0,1\}\), \((\widetilde{C}_b,sk_b)\leftarrow \mathcal {O}(\lambda ,C_b)\), and \((\widetilde{C}^1_b,\ldots ,\widetilde{C}^t_b)\leftarrow \mathsf {Update}^{\widetilde{C}_{b}}(sk_b,I_b)\). These two facts together imply that the distributions \(A(\widetilde{C}_0,\widetilde{C}^1_0,\ldots ,\widetilde{C}^t_0)\) and \(A(\widetilde{C}_1,\widetilde{C}^1_1,\ldots ,\widetilde{C}^t_1)\) are close, implying that \((\mathcal {O},\mathsf {Update})\) is a increment-private incremental indistinguishability obfuscator.

Next we sketch the argument for the other direction. Our simulator \(\mathcal {S}\) on input \(C_1, I_1\) computes \((\widetilde{C}_1,sk_1)\leftarrow \mathcal {O}(\lambda ,C_1)\), and \((\widetilde{C}^1_1,\ldots ,\widetilde{C}^t_1)\leftarrow \mathsf {Update}^{\widetilde{C}_{1}}(sk_1,I_1)\) and outputs \((\widetilde{C}_1,\widetilde{C}^1_1,\ldots ,\widetilde{C}^t_1)\). The indistinguishability of this from obfuscation of \(C_0\) and obfuscation increments for \(I_0\) follows directly from the security of increment-private incremental indistinguishability.    \(\square \)

8 Extensions and Future Work

We discuss three possible extensions of our results: non-sequential model of updates, adaptive updates, and new types of update operations and other refinements.

Non-sequential updates. In our current model, an update at time step i is applied to the obfuscation at time step \(i-1\). A more flexible approach would be to allow the update to any obfuscation that is previously present in the history. This results in a “tree like” structure for updates instead of the “line” for sequential updates. This model is interesting for situations where the copies of software reside on several remote machines and may be updated at different times.

Our constructions can be easily adapted for this setting as well. Specifically, in our basic \(\mathsf {IIO}\) construction, instead of choosing r at random, let it be an encryption of a random value. The update algorithm will simply encrypt a fresh value each time (instead of adding 1 to the previous value). All other operations are performed as before.

The key observation is that, since the values are now encrypted, sequential values look indistinguishable from random. Therefore, in the security proof, we will first change the random values to sequential, and then proceed exactly as before. Note that the the obfuscated program does not need to know the values in the encryption, and hence does not need the secret key. Only the update algorithm needs the secret key. The proof now additionally uses the semantic security of encryption (along with NIZK proofs as before) to switch to sequential values.

Adaptive updates. As mentioned earlier, our constructions do not achieve adaptive security where future updates are chosen adversarially based on previous obfuscations. We leave this as an interesting open problem.

More general updates, and other refinements. We did not consider updates which may increase the size of the underlying programs. In many settings, the size of the program would likely increase after updates. Likewise, we also did not explore other refinements such as tamper-proof security (where the obfuscation to be updated may not be “correct” due to tampering by the adversary). It would be interesting to explore these directions in future.