About obfuscating re-encryption: the first construction is not a obfuscator

Question

An intuitive understanding of obfuscated re-encryption:

A third party with a re-encryption program learns no more from the re- encryption program than from interaction with a black-box oracle that provides the same functionality.

I'm reading this paper (Hohenberger et al.) about obfuscating re-encryption. They first adapted the definition of obfuscation to average-case secure obfuscation, let $\mathsf{Obf}$ be the obfuscation algorithm, $\mathbf C=\{\mathbf C_n\}$ be a circuit family (to be obfuscated):

• Preserving functionality: informally, with overwhelming probability $\mathsf{Obf}(C)$ behaves almost identically to $C$ on all inputs.
• Polynomial slowdown: $|\mathsf{Obf}(C)|\leq p(|C|)$ where $p$ is a polynomial.
• Average-Case Secure Virtual Black-Box: For any efficient adversary $\mathcal A$, there exists an efficient simulator $\mathsf{Sim}$ and a negligible function $neg(n)$, such that for every efficient distinguisher $\mathsf D$, for every input length $n$ and for every poly-size auxiliary input $z$: $$\left|\Pr[C\gets\mathbf C_n:\mathsf D^C(\mathcal A(\mathsf{Obf}(C),z),z)=1]-\Pr[C\gets\mathbf C_n:\mathsf D^C(\mathsf{Sim}^C(1^n,z),z)=1]\right|\leq neg(n).$$ The probability is over the selection of a random circuit $C$ from $\mathbf C_n$.

After that, they proposed a re-encryption obfuscator that satisfied the above definition. Let's say construction A:

But this work (by Ateniese, Benson, and Hohenberger) found that construction A does not preserve key private property. Given the re-encryption tuples from Alice to Bob and from Bob to Alice, the adversary can tell if the two re-encryption tuples are matched! For example, given $(Z_1,Z_2,Z_3) = (h^{za_2/a_1},h^{zb_2/b_1},h^z)$ and $(Z_1',Z_2',Z_3') = (g^{z'a_1/a_2},g^{z'b_1/b_2},g^{z'})$, $\mathcal A$ checks if $e(Z_1',Z_1)==e(Z_2',Z_2)==e(Z_3',Z_3)$. This evidence shows that this construction A is not a secure obfuscator in their definition: the adversary gains additional knowledge! And, in their security proof, the simulation is distinguishable since the adversary can do the matching check:

I want to know if my understanding is correct. And if so, why has no one raised any objections to this construction? Ateniese et al. just stated that "even this obfuscation is not key-private". But I think this construction is actually not a qualified obfuscator.

I'm still reading more papers on this topic, and I'd appreciate any guidance.

Answer 1

Given the re-encryption tuples from Alice to Bob and from Bob to Alice, the adversary can tell if the two re-encryption tuples are matched! ... This evidence shows that this construction A is not a secure obfuscator in their definition: the adversary gains additional knowledge!

In the work by Ateniese, Benson, and Hohenberger, they mention that the construction is not key-private where in the security game, the adversary is allowed to get multiple re-encryption tuples (i.e., obfuscated circuits). However, this does not imply that the construction fails to satisfy average-case VBB security, as the two security notions are fundamentally different. Let’s clarify this distinction more precisely.

The (average-case) virtual black-box (VBB) security for an obfuscator $\mathsf{Obf}$ says:

For every efficient adversary $\mathcal{A}$, there exists a simulator $\mathsf{Sim}$ such that (on an average) for a circuit $C$ drawn from a family of circuits, the adversary's output when given $\mathsf{Obf}(C)$ is indistinguishable from the simulator's output given only black-box access to $C$.

In simple terms: you should not be able to learn anything from the code of $\mathsf{Obf}(C)$ that you couldn't learn from just querying $C$ as a black-box.

Now importantly, this only applies to a single obfuscated program, i.e., the adversary gets $\mathsf{Obf}(C)$, not multiple circuits $\mathsf{Obf}(C_1), \mathsf{Obf}(C_2)$, etc., unless the definition is extended to handle multiple obfuscated programs. That is, the fact that two different obfuscated programs, when seen together, reveal relational information (e.g., being inverses) is not covered by the VBB security guarantee.