Efficient Generic Zero-Knowledge Proofs from Commitments (Extended Abstract)

Abstract

Even though zero-knowledge has existed for more than 30 years, few generic and efficient constructions for zero-knowledge exist. In this paper, we present a new kind of commitment scheme on which we can build a novel and efficient zero-knowledge protocol for circuit satisfiability. Our commitment scheme can be constructed in a black-box manner from any commitment scheme. We can prove knowledge of the AES-key which map a particular plaintext to a particular ciphertext in less than 300 milliseconds with a soundness-error of $2^{-40}$. The communication complexity of our protocol is less then $5 \cdot k \cdot |C|$ where k is the statistical security parameter and |C| is the circuit size.

S. Ranellucci and R. Zakarias—The authors acknowledge support from the Danish National Research Foundation and The National Science Foundation of China (under the grant 61061130540) for the Sino-Danish Center for the Theory of Interactive Computation, within part of this work was performed; and from the CFEM research center, supported by the Danish Strategic Research Council.

S. Ranellucci and R. Zakarias—Supported by the European Research Council Stating Grant 279447.

Appendices

A Universal Composability Framework

The Universal Composability framework was introduced by Canetti in [4] In this framework, protocol security is analysed by comparing an ideal world execution and a real world execution under the supervision of an environment $\mathcal {Z}$, which is represented by a PPT machine and has access to all communication between individual parties. In the ideal world execution, dummy parties (possibly controlled by a PPT simulator) interact directly with the ideal functionality $\mathcal {F}$, which works as a fully secure third party that computes the desired function or primitive. In the real world execution, several PPT parties (possibly corrupted by a real world adversary $\mathcal {A}$) interact with each other by means of a protocol $\pi$ that realizes the ideal functionality. The real world execution is represented by the ensemble $\mathrm {EXEC}_{\pi , \mathcal {A}, \mathcal {Z}}$, while the ideal execution is represented by the $\mathrm {IDEAL}_{\mathcal {F}, \mathcal {S}, \mathcal {Z}}$. The rationale behind this framework lies in showing that the environment $\mathcal {Z}$ is not able to efficiently distinguish between $\mathrm {EXEC}_{\pi , \mathcal {A}, \mathcal {Z}}$ and $\mathrm {IDEAL}_{\mathcal {F}, \mathcal {S}, \mathcal {Z}}$, thus implying that the real world protocol is as secure as the ideal functionality. It is known that a setup assumption is needed for UC realizing oblivious transfer as well as most “interesting” ideal functionalities [6].

1.1 A.1 Ideal Functionalities

B Inequality Protocol

The inequality proof only differs with the equality proof in which tests the verifier does. In the equality protocol, the verifier tests if $m^c_i \oplus m^c_j = \delta$. In the inequality proof, the verifier tests if $m^c_i \oplus m^c_j \oplus c = \delta$. We can see that this protocol is sound and complete by Observation 3. We can show that it is zero-knowledge from Observation 5 and by applying the same reasoning used to prove the zero-knowledge property of the equality proof (Fig. 8).

Fig. 8.

Inequality

C Parallel Equality Proofs

As before, we take $M=({\mathsf {{com}}}(m_{}^{0}),{\mathsf {{com}}}(m_{}^{1}))$ as input to mean that an XOR commitment already happened beforehand. For the set of pairs of indices $I=\{(i_r,j_r)\}_{r=1,...,t}$, we generate the $\delta {}_r$ and send a string $\Delta {} = \delta _1,...,\delta _t$ rather than one bit, to the verifier. Also, the verifier now checks t positions, one for each bit in $\Delta {}$.

By applying the same reasoning used in the equality protocol, we can see that our protocol for parallel equality in Fig. 9 is also an Honest-verifier Zero-Knowledge proof system with soundness-error one-half.

Fig. 9.

Parallel Equality proof

D Parallel Linear Proof

In Fig. 10, we include a protocol for parallel linear zero-knowledge.

Fig. 10.

Parallel linear Zero-knowledge

E Simulation of Mult

The simulation of the and-proof is fairly simple. Basically, the simulation will see which test the verifier would ask for based on the given random tape. The simulator then selects a random permutation, it selects that permutation that the prover would send. The simulator then see’s which equality test would be run based on the choice of test. The simulator uses the random tape and the simulator for the parallel equality to generate a view for each of the equality tests. He then outputs the combined view for all of these things put together. By the zero-knowledge property of the parallel equality test, we can see that the generated view is indistinguishable from the view generated by the transcript of an interaction between an honest prover and an honest verifier (Fig. 11).

Fig. 11.

Multiplication simulator

F Reproducing Our Empirical Studies

We have implemented our protocol. The implementation can be found at http://tinyurl.com/om6vvh6

Software Structure: The software project is written from scratch using only few dependencies on the system like some libstdc functionality. We do this in order to have fine grained control of the performance of our program. The structure is as follows:

• platform Inside the platform directory we have all the OS/HW dependent code

• common Inside common we have library code needed to implement the protocol, including network management in CArena and data-structures in project ds.

• empiricalZK holds two projects: RTZ14 which is the code for protocol described in this paper. IKOS will later be populated with an efficient implementation of the MPC in the HEAD idea which is in its infant stage right now. We wish to publish a comparison between IKOS and RTZ14 (this protocol) in a follow up paper.

All projects are GNU Auto-Make/Conf projects producing a static library and some also an executable. Each project defines a configuration item with version control for maintenance.

Dependencies: The code is written with in C for speed and portability. It includes work by Nayuki Minase published at http://www.nayuki.io/page/fast-sha2-hashes-in-x86-assembly.

The build system on FreeBSD 10, OSX and GNU Linux requires:

• GNU Bash 4.3.11(2)

• Automake 1.14

• Autoconf 2.69

Or on Windows 8/10 a working Community version of Visual Studio Express 2013 or later is required.

Getting the Source: Install git on your system and do

Building from Source Code, FreeBSD, Linux and OSX: On these systems building the source is done by changing directory to where you have checked out the source and locating the build.sh script.

Will build the prover executable in empiricalZK/rtz14/linux/src/prover.

Building from Source Code, Windows 8/10: On Windows we have a test solution that as a bi-product of running the test programs also produces the prover.exe in empiricalZK/rtz14/win64/rtz14/Release/prover.exe.

You can run this executable from a Command Prompt invoking it with no argument to see your options and for running it providing arguments to do a Zero-knowledge proof.

Reproducing Our Results: Our benchmark application is proving knowledge of a particular AES key given a public plaintext and ciphertext. The structure of the circuit we prove to satisfy is depicted in Fig. 12. The circuit includes public constant assignments for the plaintext and the Prover convinces the Verifier that he has knowledge of an Aes-Key encrypting this particular plaintext to a ciphertext built into the circuit. That is, our binary AES is extended with the top-triangle on Fig. 12 which is a small comparison circuit with public constants stipulating the expected ciphertext and comparing with the output of the AES circuit (the larger triangle below it). In the end all the Verifier learns is that the prover has a witness w making the (public) circuit true, thus encrypting the given plaintext to the expected ciphertext.

Our lab computers has the following specifications:

for both Verifier and Prover. On the machine intended for the Prover do

This will start a prover process listening for a Verifier to connect. The circuit in ../test/AES is the following and we prove in this case that we have knowledge of a key (this witness above which is the zero key) encrypting the all zero plaintext (that is 16 zero bytes) to the AES ciphertext under the zero key, namely:

Fig. 12.

A modified binary AES circuit for proving knowledge of a key encrypting a particular plaintext to a particular ciphertext.

To start the Verifier you need the ip address of the Prover, assuming it is xxx.yyy.zzz.www execute the following on the Verifier Machine:

The process uses the -witness argument to distinguish whether to run as Prover or Verifier. This proves with error probability 3 / 4 that the prover knows such a witness. Because of completeness this will always succeed if the Prover inputs the correct witness, otherwise the Verifier only accepts with a $75\,\%$ probability. In a real word application with statistical security parameter s the protocol will be repeated 3s times to reduce the probability that a cheating Prover wins to $2^{-s}$. Our experiment above runs in 3ms on our test machines thus for security parameter $\kappa {}=128$ we expect a real world running time of $9\kappa {} ms \approx {} 2.5$ seconds.