Non-interactive secure computation(NISC) [IKO+11] allows a receiverRto publish a string containing an encryption of his secret inputx, so that a senderS, holding a possibly very long inputy, can revealf(x, y)
toRby sending him a single message. This should be done while simultaneously protecting the secrecy of
yagainst a maliciousRand preventingSfrom any malicious influence on the output ofR. Insuccinct NISC
(SNISC), we also require that the amount of work performed byR(and thus the communication complexity) is polynomial in the security parameterkand the input/output length off (and is in particular independent of the complexity off).
When the parties are semi-honest there are known solutions (e.g., based on fully homomorphic en- cryption with function privacy [Gen09]). Naor and Nissim [NN01] observe that using the succinct zero- knowledge arguments of Kilian [Kil92] one can enhance the GMW semi-honest-to-malicious compiler to be communication preserving. However, the resulting protocol is not round preserving and hence cannot be used to achieve SNISC.
Using the zkSNARKs, however, we can obtain SNISC against malicious parties in the CRS model. (Though the string published by the receiver R can only be used logarithmically many times; if the re- ceiver wishes to receive more messages, he should publish a new string.) We achieve UC security or non- concurrent security, depending on whether the sender’s input is long or short.
Corollary 10.2. In the CRS model, if zkSNARKs exist, so does SNISC with malicious parties, with non- concurrent security in the case of long sender input, and UC security in the case of short sender input. Proof sketch. We begin by discussing the long sender input case, and describe a protocol that naturally extends the semi-honest FHE-based SNISC protocol to the malicious setting.
The protocol.To jointly compute a functionf:
1. The receiverRsends the verifier-generated reference stringvgrs, an encryptioncof its inputx, and
πR
ZK, a NIZK proof of knowledge of inputx(and randomness for the encryption) attesting thatcis a
valid encryption ofx.
2. The senderS verifies thatπR
ZK is valid and aborts if not. The senderS then homomorphically evalu-
evaluated cipherˆc, together withπS
ZK, a zkSNARK proving knowledge ofy(and randomness for the
evaluation algorithm) attesting thatˆcis a valid (homomorphic) evaluation off(·, y)onc.
3. The receiverRverifies thatπS
ZKis a valid zkSNARK and, if so, outputs the decryption ofcˆor else⊥.
We stress that the amount of work done byR(including his NIZKπR
ZK) is independent off’s complexity.
We next briefly describe how each party is simulated.
Simulating a maliciousR∗. To simulateR∗, we proceed as follows. First, generate the CRS together with a trapdoor for the NIZK of knowledge and then provideR∗ with the CRS to obtain(vgrs, c, πR
ZK). In case
the NIZKπR
ZK doesn’t verify, abort; otherwise, use the trapdoor to extract the inputx, hand it to the trusted
party, and receivef(x, y). To simulate the message sent byS, simulate the evaluation result ˆcusing the underlying plaintextf(x, y); this can be done by the function privacy guarantee. Next, invoke the simulator for the zkSNARK with respect to the statement given by the simulated evaluationˆc.
The validity of the simulation follows from the function privacy guarantee of the FHE and the validity zkSNARK simulator, as well as from the fact that the NIZK in use is a proof of knowledge.
Simulating a malicious S∗. To simulate S∗, we proceed as follows. Generate the CRS together with a trapdoor for the NIZK of knowledge. SimulateR’s message by encrypting an arbitrary string (of the proper length) to create a simulated encryption cand running the NIZK simulator with respect to the statement given byc. Also, simulate thevgrsby employing the generator of the zkSNARK. FeedS∗with the generated message to obtain a proofπR
ZK. Check the validity of π
R
ZK using the CRS and the private verification state
generated withvgrs. If the proof is invalid abort; otherwise, use the zkSNARK extractor to obtain the input
y and hand it to the trusted party. (Note that here is where simulation makes non-black-box use of the adversaryS∗, because the extractor forS∗ guaranteed by the knowledge property of the zkSNARK might need to use the code ofS∗.)
The validity of the simulation follows from the semantic security of the encryption and the validity of the NIZK simulator, as well as from the fact that the zkSNARK is a proof of knowledge.
We note that the FHE-based protocol above can be naturally generalized to yield a simple compiler that transforms any SNISC protocol in a slightly strengthened semi-honest model to a (still non-interactive) protocol that is secure against malicious parties in the CRS model. The strengthening of the semi-honest model is to require security with respect to parties that may choose arbitrary randomness. (In the interactive setting, the GMW compiler itself deals with this issue using “coin tossing into the well”, which can not be done in the non-interactive setting.)
In the case where the input of the sender S is short, S acts instead as follows: he gives a NIZK of knowledgeπ0attesting that he knows his own inputyand then uses a zkSNARG to prove that “there exists
y(as well as randomness for the evaluation algorithm and randomness for the NIZK) for whichcˆis a valid evaluation of f(·, y) on c,and y is the witness for the NIZKπ0”. Now the simulation of a maliciousS∗
can be performed in a black-box manner, by simply invoking the black-box extractor of the NIZK proof of knowledge; a non-black-box use ofS∗is only made within the proof when the (computational) soundness of the zkSNARG is invoked. (In particular, the proof of knowledge property of the zkSNARG is not essential for the short sender input case.)
11
Extractable One-Way Functions and Their Applications
In this section, we consider a notion that is closely related to ECRHs: extractable one-way functions
tence of EOWFs and enhanced trapdoor permutations, there exist anon-interactive(two-message) selective- opening-attack-secure (SOA-secure) commitment scheme and a3-roundconcurrent zero-knowledge (ZK) protocol. Previous works showed that it is impossible to construct the former primitive from standard as- sumptions using black-box security reductions [Pas11] (provided one-to-one one-way functions exist), and that it is impossible to have sublogarithmic-round concurrent zero-knowledge protocols with black-box simulation [CKPR01]. Our constructions circumvent previous impossibility results by relying on the (non- black-box) extractability property of EOWFs.
The rest of this section is organized as follows. In Section 11.1 we formalize two variants of EOWFs:
strong extractable OWFs(sEOWFs) andstrong concurrently-extractable OWFs(scEOWFs). Next, in Sec- tion 11.4, we use sEOWFs to construct a non-interactive SOA-secure commitment scheme; the technical core of our construction is obtaining a new 3-round zero-knowledge argument-of-knowledge (ZKAOK) protocol having the special property that only the last message of the protocol depends on the statement to be proved; we believe this construction is of independent interest, and we present it first separately in Section 11.2. Next, in Section 11.3, we show that when the sEOWF used in our 3-round ZKAOK protocol is replaced with a scEOWF, the protocol is also concurrent ZK, yielding a 3-round concurrent ZK protocol. Finally, in Section 11.5 we give candidate constructions of sEOWFs and scEOWFs, based on the (original) Knowledge-of-Exponent Assumption (KEA) of [Dam92].