1 Introduction

The concept of zero-knowledge is fundamental to theoretical computer science. Introduced in the seminal work of Goldwasser, Micali, and Rackoff [62], a zero-knowledge proof system enables a prover to convince a verifier that some statement is true without revealing anything more than the truth of the statement. Traditionally, zero-knowledge proof systems for \(\mathsf {NP}\) are interactive, and in fact, interaction is essential for realizing zero-knowledge (for \(\mathsf {NP}\)) in the standard model [61].

Non-interactive zero-knowledge. Nonetheless, Blum, Feldman, and Micali [16] showed that meaningful notions of zero-knowledge are still realizable in the non-interactive setting, where the proof consists of just a single message from the prover to the verifier. In the last three decades, a beautiful line of works has established the existence of NIZK proof (and argument) systems for all of \(\mathsf {NP}\) in the random oracle model [45, 81] or the common reference string (CRS) model [40, 44, 65, 66, 86], where the prover and the verifier are assumed to have access to a common string chosen by a trusted third party. Today, we have NIZK candidates in the CRS model from several classes of cryptographic assumptions:Footnote 1 (doubly-enhanced) trapdoor permutations [40, 44, 65], pairings [66], and indistinguishability obfuscation [86]. Notably absent from this list are constructions from lattice assumptions [6, 83]. While some partial progress has been made in the case of specific languages [7, 79], the general case of constructing NIZK proofs (or even arguments) for all of \(\mathsf {NP}\) from standard lattice assumptions remains a longstanding open problem.

NIZKs in a preprocessing model. In this work, we make progress on this problem by giving the first multi-theorem NIZK argument for \(\mathsf {NP}\) from standard lattice assumptions in the preprocessing model. In the NIZK with preprocessing model [42], there is an initial (trusted) setup phase that generates a proving key \(k_P\) and a verification key \(k_V\). The proving key is needed to construct proofs while the verification key is needed to check proofs. In addition, the setup phase is run before any statements are proven (and thus, must be statement-independent). In the multi-theorem setting, we require that soundness holds against a prover who has oracle access to the verifier (but does not see \(k_V\)), and that zero-knowledge holds against a verifier who has oracle access to the prover (but does not see \(k_P\)). The NIZK with preprocessing model generalizes the more traditional settings under which NIZKs have been studied. For instance, the case where \(k_P\) is public (but \(k_V\) is secret) corresponds to designated-verifier NIZKs [34, 36, 39], while the case where both \(k_P\) and \(k_V\) are public corresponds to the traditional CRS setting, where the CRS is taken to be the pair \((k_P, k_V)\).

Why study the preprocessing model? While the preprocessing model is weaker than the more traditional CRS model, constructing multi-theorem NIZK arguments (and proofs) in this model does not appear to be any easier than constructing them in the CRS model. Existing constructions of NIZKs in the preprocessing model from weaker assumptions such as one-way functions [38, 42, 69, 75] or oblivious transfer [73] are only secure in the single-theorem setting. As we discuss in greater detail in Remark 4.7, the constructions from [38, 42, 75] only provide single-theorem zero-knowledge, while the constructions in [69, 73] only provide single-theorem soundness. Even in the designated-verifier setting [34, 36, 39] (where only the holder of a verification key can verify the proofs), the existing constructions of NIZKs for \(\mathsf {NP}\) based on linearly-homomorphic encryption suffer from the so-called “verifier-rejection” problem where soundness holds only against a logarithmically-bounded number of statements. Thus, the only candidates of multi-theorem NIZKs where soundness and zero-knowledge hold for an unbounded number of theorems are the constructions in the CRS model, which all rely on trapdoor permutations, pairings, or obfuscation. Thus, it remains an interesting problem to realize multi-theorem NIZKs from lattice assumptions even in the preprocessing model.

Moreover, as we show in Sect. 6.1, multi-theorem NIZKs in the preprocessing model suffice to instantiate many of the classic applications of NIZKs for boosting the security of multiparty computation (MPC) protocols. Thus, our new constructions of reusable NIZK arguments from standard lattice assumptions imply new constructions of round-optimal, near-optimal-communication MPC protocols purely from lattice assumptions. Our work also implies a succinct version of the classic Goldreich-Micali-Wigderson compiler [59, 60] for boosting semi-honest security to malicious security, again purely from standard lattice assumptions. Furthermore, studying NIZKs in the preprocessing model may also serve as a stepping stone towards realizing NIZKs in the CRS model from standard lattice assumptions. For example, the starting point of the first multi-theorem NIZK construction by Feige, Lapidot, and Shamir [44] was a NIZK proof for graph Hamiltonicity in the preprocessing model.

1.1 Multi-Theorem Preprocessing NIZKs from Lattices

The focus of this work is on constructing NIZKs in the preprocessing model (which we will often refer to as a “preprocessing NIZK”) from standard lattice assumptions. As we discuss in Sect. 1.2 and in Remark 4.7, this is the first candidate of reusable (i.e., multi-theorem) NIZK arguments from a standard lattice assumption. Below, we provide a high-level overview of our main construction.

Homomorphic signatures. A homomorphic signature scheme [5, 18, 19, 63] enables computations on signed data. Specifically, a user can sign a message x using her private signing key to obtain a signature \(\sigma \). Later on, she can delegate the pair \((x, \sigma )\) to an untrusted data processor. The data processor can then compute an arbitrary function g on the signed data to obtain a value \(y = g(x)\) along with a signature \(\sigma _{g, y}\). The computed signature \(\sigma _{g, y}\) should certify that the value y corresponds to a correct evaluation of the function g on the original input x. In a context-hiding homomorphic signature scheme [18, 22], the computed signature \(\sigma _{g, y}\) also hides the input message x. Namely, the pair \((y, \sigma _{g, y})\) reveals no information about x other than what could be inferred from the output \(y = g(x)\). Gorbunov et al.  [63] gave the first construction of a context-hiding homomorphic signature scheme for general Boolean circuits (with bounded depth) from standard lattice assumptions.

From homomorphic signatures to zero-knowledge. The notion of context-hiding in a homomorphic signature scheme already bears a strong resemblance to zero-knowledge. Namely, a context-hiding homomorphic signature scheme allows a user (e.g., a prover) to certify the result of a computation (e.g., the output of an \(\mathsf {NP}\) relation) without revealing any additional information about the input (e.g., the \(\mathsf {NP}\) witness) to the computation. Consider the following scenario. Suppose the prover has a statement-witness pair (x, w) for some \(\mathsf {NP}\) relation \(\mathcal {R}\) and wants to convince the verifier that \(\mathcal {R}(x, w) = 1\) without revealing w. For sake of argument, suppose the prover has obtained a signature \(\sigma _w\) on the witness w (but does not have the signing key for the signature scheme), and the verifier holds the verification key for the signature scheme. In this case, the prover can construct a zero-knowledge proof for x by evaluating the relation \(\mathcal {R}_x(w) \mathrel {\mathop :}=\mathcal {R}(x, w)\) on \((w, \sigma _w)\). If \(\mathcal {R}(x, w) = 1\), then this yields a new signature \(\sigma _{\mathcal {R}, x}\) on the bit 1. The proof for x is just the signature \(\sigma _{\mathcal {R}, x}\). Context-hiding of the homomorphic signature scheme says that the signature \(\sigma _{\mathcal {R}, x}\) reveals no information about the input to the computation (the witness w) other than what is revealed by the output of the computation (namely, that \(\mathcal {R}(x, w) = 1\)). This is precisely the zero-knowledge property. Soundness of the proof system follows by unforgeability of the homomorphic signature scheme (if there is no w such that \(\mathcal {R}_x(w) = 1\), the prover would not be able to produce a signature on the value 1 that verifies according to the function \(\mathcal {R}_x\)).

While this basic observation suggests a connection between homomorphic signatures and zero-knowledge, it does not directly give a NIZK argument. A key problem is that to construct the proof, the prover must already possess a signature on its witness w. But since the prover does not have the signing key (if it did, then the proof system is no longer sound), it is unclear how the prover obtains this signature on w without interacting with the verifier (who could hold the signing key). This is the case even in the preprocessing model, because we require that the preprocessing be statement-independent (and in fact, reusable for arbitrarily many adaptively-chosen statements).

Preprocessing NIZKs from homomorphic signatures. Nonetheless, the basic observation shows that if we knew ahead of time which witness w the prover would use to construct its proofs, then the setup algorithm can simply give the prover a homomorphic signature \(\sigma _w\) on w. To support this, we add a layer of indirection. Instead of proving that it knows a witness w where \(\mathcal {R}(x, w) = 1\), the prover instead demonstrates that it has an encryption \(\mathsf {ct}_w\) of w (under some key \(\mathsf {sk}\)), and that it knows some secret key \(\mathsf {sk}\) such that \(\mathsf {ct}\) decrypts to a valid witness w where \(\mathcal {R}(x, w) = 1\).Footnote 2 A proof of the statement x then consists of the encrypted witness \(\mathsf {ct}_w\) and a proof \(\pi _{\mathcal {R}, x, \mathsf {ct}_w}\) that \(\mathsf {ct}_w\) is an encryption of a satisfying witness (under some key). First, if the encryption scheme is semantically-secure and the proof is zero-knowledge, then the resulting construction satisfies (computational) zero-knowledge. Moreover, the witness the prover uses to construct \(\pi _{\mathcal {R}, x, \mathsf {ct}_w}\) is always the same: the secret key \(\mathsf {sk}\). Notably, the witness is statement-independent and can be reused to prove arbitrarily many statements (provided the encryption scheme is CPA-secure).

This means we can combine context-hiding homomorphic signatures (for general circuits) with any CPA-secure symmetric encryption scheme to obtain NIZKs in the preprocessing model as follows:

  • Setup: The setup algorithm generates a secret key \(\mathsf {sk}\) for the encryption scheme as well as parameters for a homomorphic signature scheme. Both the proving and verification keys include the public parameters for the signature scheme. The proving key \(k_P\) additionally contains the secret key \(\mathsf {sk}\) and a signature \(\sigma _\mathsf {sk}\) on \(\mathsf {sk}\).

  • Prove: To generate a proof that an \(\mathsf {NP}\) statement x is true, the prover takes a witness w where \(\mathcal {R}(x, w) = 1\) and encrypts w under \(\mathsf {sk}\) to obtain a ciphertext \(\mathsf {ct}_w\). Next, we define the witness-checking function \(\mathsf {CheckWitness}[\mathcal {R}, x, \mathsf {ct}_w]\) (parameterized by \(\mathcal {R}\), x, and \(\mathsf {ct}_w\)) that takes as input a secret key \(\mathsf {sk}\) and outputs 1 if \(\mathcal {R}(x, \mathsf {Decrypt}(\mathsf {sk}, \mathsf {ct}_w)) = 1\), and 0 otherwise. The prover homomorphically evaluates \(\mathsf {CheckWitness}[\mathcal {R}, x, \mathsf {ct}_w]\) on \((\mathsf {sk}, \sigma _\mathsf {sk})\) to obtain a new signature \(\sigma ^*\) on the value 1. The proof consists of the ciphertext \(\mathsf {ct}_w\) and the signature \(\sigma ^*\).

  • Verify: Given a statement x for an \(\mathsf {NP}\) relation \(\mathcal {R}\) and a proof \(\pi = (\mathsf {ct}, \sigma ^*)\), the verifier checks that \(\sigma ^*\) is a valid signature on the bit 1 according to the function \(\mathsf {CheckWitness}[\mathcal {R}, x, \mathsf {ct}]\). Notice that the description on the function only depends on the relation \(\mathcal {R}\), the statement x, and the ciphertext \(\mathsf {ct}\), all of which are known to the verifier.

Since the homomorphic signature scheme is context-hiding, the signature \(\sigma ^*\) hides the input to \(\mathsf {CheckWitness}[\mathcal {R}, x, \mathsf {ct}_w]\), which in this case, is the secret key \(\mathsf {sk}\). By CPA-security of the encryption scheme, the ciphertext hides the witness w, so the scheme provides zero-knowledge. Soundness again follows from unforgeability of the signature scheme. Thus, by combining a lattice-based homomorphic signature scheme for general circuits [63] with any lattice-based CPA-secure symmetric encryption scheme, we obtain a (multi-theorem) preprocessing NIZK from lattices. In fact, the verification key in our construction only consists of the public parameters for the homomorphic signature scheme, and thus, can be made public. This means that in our construction, only the proving key needs to be kept secret, so we can equivalently view our construction as a multi-theorem “designated-prover” NIZK. We discuss this in greater detail in Remark 4.6.

An appealing property of our preprocessing NIZKs is that the proofs are short: the length of a NIZK argument for an \(\mathsf {NP}\) relation \(\mathcal {R}\) is \(\left| w \right| + \mathsf {poly}(\lambda , d)\) bits, where \(\left| w \right| \) is the length of a witness for \(\mathcal {R}\) and d is the depth of the circuit computing \(\mathcal {R}\). The proof size in NIZK constructions from trapdoor permutations or pairings [40, 44, 65, 66] typically scale with the size of the circuit computing \(\mathcal {R}\) and multiplicatively with the security parameter. Previously, Gentry et al.  [56] gave a generic approach using fully homomorphic encryption (FHE) to reduce the proof size in any NIZK construction. The advantage of our approach is that we naturally satisfy this succinctness property, and the entire construction can be based only on lattice assumptions (without needing to mix assumptions). We discuss this in greater detail in the full version of this paper [74]. We also give the complete description of our preprocessing NIZK and security analysis in Sect. 4.

Blind homomorphic signatures for efficient preprocessing. A limitation of preprocessing NIZKs is we require a trusted setup to generate the proving and verification keys. One solution is to have the prover and verifier run a (malicious-secure) two-party computation protocol (e.g., [76]) to generate the proving and verification keys. However, generic MPC protocols are often costly and require making non-black-box use of the underlying homomorphic signature scheme.

In this work, we describe a conceptually simpler and more efficient way of implementing the preprocessing without relying on general MPC. We do so by introducing a new cryptographic notion called blind homomorphic signatures. First, we observe that we can view the two-party computation of the setup phase as essentially implementing a “blind signing” protocol where the verifier holds the signing key for the homomorphic signature scheme and the prover holds the secret key \(\mathsf {sk}\). At the end of the blind signing protocol, the prover should learn \(\sigma _\mathsf {sk}\) while the verifier should not learn anything about \(\mathsf {sk}\). This is precisely the properties guaranteed by a blind signature protocol [35, 47]. In this work, we introduce the notion of a blind homomorphic signature scheme which combines the blind signing protocol of traditional blind signature schemes while retaining the ability to homomorphically operate on ciphertexts. Since the notion of a blind homomorphic signatures is inherently a two-party functionality, we formalize it in the model of universal composability [24]. We provide the formal definition of the ideal blind homomorphic signature functionality in Sect. 5.

In Sect. 5.1, we show how to securely realize our ideal blind homomorphic signature functionality in the presence of malicious adversaries by combining homomorphic signatures with any UC-secure oblivious transfer (OT) protocol [27]. Note that security against malicious adversaries is critical for our primary application of leveraging blind homomorphic signatures to implement the setup algorithm of our preprocessing NIZK candidate. At a high-level, we show how to construct a blind homomorphic signature scheme from any “bitwise” homomorphic signature scheme—namely, a homomorphic signature scheme where the signature on an \(\ell \)-bit message consists of \(\ell \) signatures, one for each bit of the message. Moreover, we assume that the signature on each bit position only depends on the value of that particular bit (and not the value of any of the other bits of the message); of course, the \(\ell \) signatures can still be generated using common or correlated randomness. Given a bitwise homomorphic signature scheme, we can implement the blind signing protocol (on \(\ell \)-bit messages) using \(\ell \) independent 1-out-of-2 OTs. Specifically, the signer plays the role of the sender in the OT protocol and for each index \(i \in [\ell ]\), the signer signs both the bit 0 as well as the bit 1. Then, to obtain a signature on an \(\ell \)-bit message, the receiver requests the signatures corresponding to the bits of its message.

While the high-level schema is simple, there are a few additional details that we have to handle to achieve robustness against a malicious signer. For instance, a malicious signer can craft the parameters of the homomorphic signature scheme so that when an evaluator computes on a signature, the resulting signatures no longer provide context-hiding. Alternatively, a malicious signer might mount a “selective-failure” attack during the blind-signing protocol to learn information about the receiver’s message. We discuss how to address these problems by giving strong definitions of malicious context-hiding for homomorphic signatures in Sect. 3, and give the full construction of blind homomorphic signatures from oblivious transfer in Sect. 5.1. In particular, we show that the Gorbunov et al.  [63] homomorphic signature construction satisfies our stronger security notions, and so coupled with the UC-secure lattice-based OT protocol of Peikert et al.  [80], we obtain a UC-secure blind homomorphic signature scheme from standard lattice assumptions. Moreover, the blind signing protocol is a two-round protocol, and only makes black-box use of the underlying homomorphic signature scheme.

UC-secure preprocessing NIZKs. Finally, we show that using our UC-secure blind homomorphic signature candidate, we can in fact realize the stronger notion of UC-secure NIZK arguments in a preprocessing model from standard lattice assumptions. This means that our NIZKs can be arbitrarily composed with other cryptographic protocols. Our new candidates are thus suitable to instantiate many of the classic applications of NIZKs for boosting the security of general MPC protocols. As we show in Sect. 6, combining our preprocessing UC-NIZKs with existing lattice-based semi-malicious MPC protocols such as [78] yields malicious-secure protocols purely from standard lattice assumptions (in a reusable preprocessing model). We also show that our constructions imply a succinct version of the classic GMW [59, 60] protocol compiler (where the total communication overhead of the compiled protocol depends only on the depth, rather than the size of the computation).

Towards NIZKs in the CRS model. In this paper, we construct the first multi-theorem preprocessing NIZK arguments from standard lattice assumptions. However, our techniques do not directly generalize to the CRS setting. While it is possible to obtain a publicly-verifiable preprocessing NIZK (i.e., make the verification key \(k_V\) public), our construction critically relies on the prover state being hidden. This is because the prover state contains the secret key the prover uses to encrypt its witness in the proofs, so publishing this compromises zero-knowledge. Nonetheless, we believe that having a better understanding of NIZKs in the preprocessing model provides a useful stepping stone towards the goal of building NIZKs from lattices in the CRS model, and we leave this as an exciting open problem.

Preprocessing NIZKs from other assumptions? Our work gives the first construction of a multi-theorem preprocessing NIZK from standard lattice assumptions. It is an interesting challenge to obtain multi-theorem preprocessing NIZKs from other assumptions that are currently not known to imply NIZKs in the CRS model. For instance, a natural target would be to construct multi-theorem NIZKs in the preprocessing model from the decisional Diffie-Hellman (DDH) assumption.

1.2 Additional Related Work

In this section, we survey some additional related work on NIZK constructions, blind signatures, and homomorphic signatures.

Other NIZK proof systems. In the CRS model, there are several NIZK constructions based on specific number-theoretic assumptions such as quadratic residuosity [15, 16, 41]. These candidates are also secure in the bounded-theorem setting where the CRS can only be used for an a priori bounded number of proofs. Exceeding this bound compromises soundness or zero-knowledge. In the preprocessing model, Kalai and Raz [70] gave a single-theorem succinct NIZK proof system for the class \(\mathsf {LOGSNP}\) from polylogarithmic private information retrieval (PIR) and exponentially-hard OT. In this work, we focus on constructing multi-theorem NIZKs, where an arbitrary number of proofs can be constructed after an initial setup phase.

NIZKs have also been constructed for specific algebraic languages in both the publicly-verifiable setting [64, 67] as well as the designated-verifier setting [33]. In the specific case of lattice-based constructions, there are several works on building hash-proof systems, (also known as smooth projective hash functions [37]) [14, 71, 91], which are designated-verifier NIZK proofs for a specific language (typically, this is the language of ciphertexts associated with a particular message). In the random oracle model, there are also constructions of lattice-based NIZK arguments from \(\varSigma \)-protocols [77, 90]. Recently, there has also been work on instantiating the random oracle in \(\varSigma \)-protocols with lattice-based correlation-intractable hash functions [26]. However, realizing the necessary correlation-intractable hash functions from lattices requires making the non-standard assumption that Regev’s encryption scheme [83] is exponentially KDM-secure against all polynomial-time adversaries. In our work, we focus on NIZK constructions for general \(\mathsf {NP}\) languages in the plain model (without random oracles) from the standard LWE assumption (i.e., polynomial hardness of LWE with a subexponential approximation factor).

Very recently, Rothblum et al.  [84] showed that a NIZK proof system for a decisional variant of the bounded distance decoding (\(\mathsf {BDD}\)) problem suffices for building NIZK proof system for \(\mathsf {NP}\).

Blind signatures. The notion of blind signatures was first introduced by Chaum [35]. There are many constructions of blind signatures from a wide range of assumptions in the random oracle model [1, 12, 13, 17, 21, 82, 85, 88], the CRS model [2,3,4, 23, 47, 49, 57, 72], as well as the standard model [50,51,52, 68].

Homomorphic signatures. There are many constructions of linearly homomorphic signatures [5, 8,9,10, 18,19,20, 31, 43, 48, 53, 89]. Beyond linear homomorphisms, a number of works [11, 19, 32] have constructed homomorphic signatures for polynomial functions from lattices or multilinear maps. For general circuits, Gorbunov et al.  [63] gave the first homomorphic signature scheme from lattices, and Fiore et al.  [46] gave the first “multi-key” homomorphic signature scheme from lattices (where homomorphic operations can be performed on signatures signed under different keys).

2 Preliminaries

We begin by introducing some basic notation. For an integer \(n \ge 1\), we write [n] to denote the set of integers \(\{ 1, \ldots , n \}\). For a positive integer \(q > 1\), we write \(\mathbb {Z}_{q}\) to denote the ring of integers modulo q. For a finite set S, we write to denote that x is sampled uniformly at random from S. For a distribution \(\mathcal {D}\), we write \(x \leftarrow \mathcal {D}\) to denote that x is sampled from \(\mathcal {D}\). Throughout this work, we use \(\lambda \) to denote a security parameter. We typically use bold uppercase letters (e.g., \(\mathbf {A}\), \(\mathbf {B}\)) to denote matrices and bold lowercase letters (e.g., \(\mathbf {u}\), \(\mathbf {v}\)) to denote vectors.

We say that a function f is negligible in \(\lambda \), denoted \(\mathsf {negl}(\lambda )\), if \(f(\lambda ) = o(1 / \lambda ^c)\) for all constants \(c \in \mathbb {N}\). We say that an event happens with negligible probability if the probability of the event occurring is bounded by a negligible function, and we say that an event happens with overwhelming probability if its complement occurs with negligible probability. We say an algorithm is efficient if it runs in probabilistic polynomial time in the length of its input. We write \(\mathsf {poly}(\lambda )\) to denote a quantity whose value is upper-bounded by a fixed polynomial in \(\lambda \). We say that two families of distributions \(\mathcal {D}_1 = \{ \mathcal {D}_{1,\lambda } \}_{\lambda \in \mathbb {N}}\) and \(\mathcal {D}_2 = \{ \mathcal {D}_{2,\lambda } \}_{\lambda \in \mathbb {N}}\) are computationally indistinguishable if no efficient algorithm can distinguish samples from either \(\mathcal {D}_1\) or \(\mathcal {D}_2\), except with negligible probability. We denote this by writing \(\mathcal {D}_1 {\mathop {\approx }\limits ^{c}}\mathcal {D}_2\). We write \(\mathcal {D}_1 {\mathop {\approx }\limits ^{s}}\mathcal {D}_2\) to denote that \(\mathcal {D}_1\) and \(\mathcal {D}_2\) are statistically indistinguishable (i.e., the statistical distance between \(\mathcal {D}_1\) and \(\mathcal {D}_2\) is bounded by a negligible function). In the full version of this paper [74], we provide additional preliminaries in on CPA-secure encryption as well as lattice-based cryptography.

3 Homomorphic Signatures

A homomorphic signature scheme enables computations on signed data. Given a function C (modeled as a Boolean circuit) and a signature \(\sigma _x\) that certifies a message x, one can homomorphic derive a signature \(\sigma _{C(x)}\) that certifies the value C(x) with respect to the function C. The two main security notions that we are interested in are unforgeability and context-hiding. We first provide a high-level description of the properties:

  • Unforgeability: We say a signature scheme is unforgeable if an adversary who has a signature \(\sigma _x\) on a message x cannot produce a valid signature on any message \(y \ne C(x)\) that verifies with respect to the function C.

  • Context-hiding: Context-hiding says that when one evaluates a function C on a message-signature pair \((x, \sigma _x)\), the resulting signature \(\sigma _{C(x)}\) on C(x) should not reveal any information about the original message x other than the circuit C and the value C(x). In our definition, the homomorphic signature scheme contains an explicit “hide” function that implements this transformation.

Syntax and notation. Our construction of blind homomorphic signatures from standard homomorphic signatures (Sect. 5.1) will impose some additional structural requirements on the underlying scheme. Suppose the message space for the homomorphic signature scheme consists of \(\ell \)-tuples of elements over a set \(\mathcal {X}\) (e.g., the case where \(\mathcal {X}= \{0,1\}\) corresponds to the setting where the message space consists of \(\ell \)-bit strings). Then, we require that the public parameters of the scheme can be split into a vector of public keys . In addition, a (fresh) signature on a vector \(\varvec{x}\in \mathcal {X}^\ell \) can also be written as a tuple of \(\ell \) signatures \(\varvec{\sigma }= (\sigma _1, \ldots , \sigma _\ell )\) where \(\sigma _i\) can be verified with respect to the verification key \(\mathsf {vk}\) and the \(i^{\mathrm {th}}\) public key \(\mathsf {pk}_i\) for all \(i \in [\ell ]\). In our description below, we often use vector notation to simplify the presentation.

Definition 3.1

(Homomorphic Signatures [19, 63]). A homomorphic signature scheme with message space \(\mathcal {X}\), message length \(\ell \in \mathbb {N}\), and function class \(\mathcal {C}= \{ \mathcal {C}_\lambda \}_{\lambda \in \mathbb {N}}\), where each \(\mathcal {C}_\lambda \) is a collection of functions from \(\mathcal {X}^\ell \) to \(\mathcal {X}\), is defined by a tuple of algorithms \(\varPi _{\mathsf {HS}}= (\mathsf {PrmsGen}, \mathsf {KeyGen}, \mathsf {Sign}, \mathsf {PrmsEval}, \mathsf {SigEval}, \mathsf {Hide}, \mathsf {Verify}, \mathsf {VerifyFresh}, \mathsf {VerifyHide})\) with the following properties:

  • : On input the security parameter \(\lambda \) and message length \(\ell \), the parameter-generation algorithm returns a set of \(\ell \) public keys .

  • \(\mathsf {KeyGen}(1^\lambda ) \rightarrow (\mathsf {vk}, \mathsf {sk})\): On input the security parameter \(\lambda \), the key-generation algorithm returns a verification key \(\mathsf {vk}\), and a signing key \(\mathsf {sk}\).

  • \(\mathsf {Sign}(\mathsf {pk}_i, \mathsf {sk}, x_i) \rightarrow \sigma _i\): On input a public key \(\mathsf {pk}_i\), a signing key \(\mathsf {sk}\), and a message \(x_i \in \mathcal {X}\), the signing algorithm returns a signature \(\sigma _i\).

    Vector variant: For , and \(\varvec{x}= (x_1, \ldots , x_\ell ) \in \mathcal {X}^\ell \), we write to denote component-wise signing of each message. Namely, outputs signatures \(\varvec{\sigma }= (\sigma _1, \ldots , \sigma _\ell )\) where \(\sigma _i \leftarrow \mathsf {Sign}(\mathsf {pk}_i, \mathsf {sk}, x_i)\) for all \(i \in [\ell ]\).

  • : On input a function \(C :\mathcal {X}^\ell \rightarrow \mathcal {X}\) and a collection of public keys , the parameter-evaluation algorithm returns an evaluated public key \(\mathsf {pk}_C\).

    Vector variant: For a circuit \(C :\mathcal {X}^\ell \rightarrow \mathcal {X}^{k}\), we write to denote component-wise parameter evaluation. Namely, let \(C_1, \ldots , C_k\) be functions such that \(C(x_1, \ldots , x_\ell ) = \big ( C_1(x_1, \ldots , x_\ell ), \ldots , C_{k}(x_1, \ldots , x_\ell ) \big )\). Then, evaluates for \(i \in [k]\), and outputs \(\mathsf {pk}_C = (\mathsf {pk}_{C_1}, \ldots , \mathsf {pk}_{C_{k}})\).

  • : On input a function \(C :\mathcal {X}^\ell \rightarrow \mathcal {X}\), public keys , messages \(\varvec{x}\in \mathcal {X}^\ell \), and signatures \(\varvec{\sigma }= (\sigma _1, \ldots , \sigma _\ell )\), the signature-evaluation algorithm returns an evaluated signature \(\sigma \).

    Vector variant: We can define a vector variant of \(\mathsf {SigEval}\) analogously to that of \(\mathsf {PrmsEval}\).

  • \(\mathsf {Hide}(\mathsf {vk}, x, \sigma ) \rightarrow \sigma ^*\): On input a verification key \(\mathsf {vk}\), a message \(x \in \mathcal {X}\), and a signature \(\sigma \), the hide algorithm returns a signature \(\sigma ^*\).

    Vector variant: For \(\varvec{x}= (x_1, \ldots , x_k)\) and \(\varvec{\sigma }= (\sigma _1, \ldots , \sigma _k)\), we write \(\mathsf {Hide}(\mathsf {vk}, \varvec{x}, \varvec{\sigma })\) to denote component-wise evaluation of the hide algorithm. Namely, \(\mathsf {Hide}(\mathsf {vk}, \varvec{x}, \varvec{\sigma })\) returns \((\sigma ^*_1, \ldots , \sigma ^*_k)\) where \(\sigma ^*_i \leftarrow \mathsf {Hide}(\mathsf {vk}, x_i, \sigma _i)\) for all \(i \in [k]\).

  • \(\mathsf {Verify}(\mathsf {pk}, \mathsf {vk}, x, \sigma ) \rightarrow \{0,1\}\): On input a public key \(\mathsf {pk}\), a verification key \(\mathsf {vk}\), a message \(x \in \mathcal {X}\), and a signature \(\sigma \), the verification algorithm either accepts (returns 1) or rejects (returns 0).

    Vector variant: For a collection of public keys , messages \(\varvec{x}= (x_1, \ldots , x_{k})\), and signatures \(\varvec{\sigma }= (\sigma _1, \ldots , \sigma _{k})\), we write to denote applying the verification algorithm to each signature component-wise. In other words, accepts if and only if \(\mathsf {Verify}(\mathsf {pk}_i', \mathsf {vk}, x_i, \sigma _i)\) accepts for all \(i \in [k]\).

  • \(\mathsf {VerifyFresh}(\mathsf {pk}, \mathsf {vk}, x, \sigma ) \rightarrow \{0,1\}\): On input a public key \(\mathsf {pk}\), a verification key \(\mathsf {vk}\), a message \(x \in \mathcal {X}\), and a signature \(\sigma \), the fresh verification algorithm either accepts (returns 1) or rejects (returns 0).

    Vector variant: We can define a vector variant of \(\mathsf {VerifyFresh}\) analogously to that of \(\mathsf {Verify}\).

  • \(\mathsf {VerifyHide}(\mathsf {pk}, \mathsf {vk}, x, \sigma ^*) \rightarrow \{0,1\}\): On input a public key \(\mathsf {pk}\), a verification key \(\mathsf {vk}\), a message \(x \in \mathcal {X}\), and a signature \(\sigma ^*\), the hide verification algorithm either accepts (returns 1) or rejects (returns 0).

    Vector variant: We can define a vector variant of \(\mathsf {VerifyHide}\) analogously to that of \(\mathsf {Verify}\).

Correctness. We now state the correctness requirements for a homomorphic signature scheme. Our definitions are adapted from the corresponding ones in [63]. Our homomorphic signature syntax has three different verification algorithms. The standard verification algorithm \(\mathsf {Verify}\) can be used to verify fresh signatures (output by \(\mathsf {Sign}\)) as well as homomorphically-evaluated signatures (output by \(\mathsf {SigEval}\)). The hide verification algorithm \(\mathsf {VerifyHide}\) is used for verifying signatures output by the context-hiding transformation \(\mathsf {Hide}\), which may be structurally different from the signatures output by \(\mathsf {Sign}\) or \(\mathsf {SigEval}\). Finally, we have a special verification algorithm \(\mathsf {VerifyFresh}\) that can be used to verify signatures output by \(\mathsf {Sign}\) (before any homomorphic evaluation has taken place). While \(\mathsf {Verify}\) subsumes \(\mathsf {VerifyFresh}\), having a separate \(\mathsf {VerifyFresh}\) algorithm is useful for formulating a strong version of evaluation correctness. Due to space limitations, we defer the formal correctness definitions to the full version of this paper [74].

Unforgeability. Intuitively, a homomorphic signature scheme is unforgeable if no efficient adversary who only possesses signatures \(\sigma _1, \ldots , \sigma _\ell \) on messages \(x_1, \ldots , x_\ell \) can produce a signature \(\sigma _y\) that is valid with respect to a function C where \(y \ne C(x_1, \ldots , x_\ell )\). We give the formal definition in the full version.

Context-hiding. The second security requirement on a homomorphic signature scheme is context-hiding, which roughly says that if a user evaluates a function C on a message-signature pair \((\varvec{x}, \varvec{\sigma })\) to obtain a signature \(\sigma _{C(\varvec{x})}\), and then runs the hide algorithm on \(\sigma _{C(\varvec{x})}\), the resulting signature \(\sigma _{C(\varvec{x})}^*\) does not contain any information about \(\varvec{x}\) other than what is revealed by C and \(C(\varvec{x})\). We define this formally in the full version.

Compactness. The final property that we require from a homomorphic signature scheme is compactness. Roughly speaking, compactness requires that given a message-signature pair \((\varvec{x}, \varvec{\sigma })\), the size of the signature obtained from homomorphically evaluating a function C on \(\varvec{\sigma }\) depends only on the size of the output message \(\left| C(\varvec{x}) \right| \) (and the security parameter) and is independent of the size of the original message \(\left| \varvec{x} \right| \).

Structural properties of homomorphic signatures. Definition 3.1 specifies a bitwise homomorphic signature scheme where the signature on an \(\ell \)-bit message \(x = x_1 \cdots x_\ell \) consists of \(\ell \) separate signatures \(\sigma = (\sigma _1, \ldots , \sigma _\ell )\) with respect to \(\ell \) public keys , one for each bit of the message. As discussed in Sect. 1.1, this property is essentially to our construction of blind homomorphic signatures from homomorphic signatures and oblivious transfer. In addition to a bitwise homomorphic signature scheme, we also require a decomposable homomorphic signature scheme for our full construction. In a decomposable homomorphic signature scheme, a signature \(\sigma \) of a message x can be decomposed into a message-independent \(\sigma ^{\mathsf {pk}}\) that contains no information about x, and a message-dependent component \(\sigma ^{\mathsf {m}}\). In the full version of this paper [74], we use this decomposability property to show that the homomorphic signature construction of Gorbunov et al.  [63] simultaneously satisfies full unforgeability and context-hiding (against malicious signers).

4 Preprocessing NIZKs from Homomorphic Signatures

In this section, we begin by formally defining the notion of a non-interactive zero-knowledge argument in the preprocessing model (i.e., “preprocessing NIZKs”). This notion was first introduced by De Santis et al.  [42], who also gave the first candidate construction of a preprocessing NIZK from one-way functions. Multiple works have since proposed additional candidates of preprocessing NIZKs from one-way functions [38, 69, 75] or oblivious transfer [73]. However, all of these constructions are single-theorem: the proving or verification key cannot be reused for multiple theorems without compromising either soundness or zero-knowledge. We provide a more detailed discussion of existing preprocessing NIZK constructions in Remark 4.7.

Definition 4.1

(NIZK Arguments in the Preprocessing Model). Let \(\mathcal {R}\) be an \(\mathsf {NP}\) relation, and let \(\mathcal {L}\) be its corresponding language. A non-interactive zero-knowledge (NIZK) argument for \(\mathcal {L}\) in the preprocessing model consists of a tuple of three algorithms \(\varPi _{\mathsf {PPNIZK}}= (\mathsf {Setup}, \mathsf {Prove}, \mathsf {Verify})\) with the following properties:

  • \(\mathsf {Setup}(1^\lambda ) \rightarrow (k_P, k_V)\): On input the security parameter \(\lambda \), the setup algorithm (implemented in a “preprocessing” step) outputs a proving key \(k_P\) and a verification key \(k_V\).

  • \(\mathsf {Prove}(k_P, x, w) \rightarrow \pi \): On input the proving key \(k_P\), a statement x, and a witness w, the prover’s algorithm outputs a proof \(\pi \).

  • \(\mathsf {Verify}(k_V, x, \pi ) \rightarrow \{0,1\}\): On input the verification key \(k_V\), a statement x, and a proof \(\pi \), the verifier either accepts (with output 1) or rejects (with output 0).

Moreover, \(\varPi _{\mathsf {PPNIZK}}\) should satisfy the following properties:

  • Completeness: For all x, w where \(\mathcal {R}(x, w) = 1\), if we take \((k_P, k_V) \leftarrow \mathsf {Setup}(1^\lambda )\);

    $$ \Pr [ \pi \leftarrow \mathsf {Prove}(k_P, x, w) : \mathsf {Verify}(k_V, x, \pi ) = 1 ] = 1. $$

  • Soundness: For all efficient adversaries \(\mathcal {A}\), if we take \((k_P, k_V) \leftarrow \mathsf {Setup}(1^\lambda )\), then

    $$ \Pr [ (x, \pi ) \leftarrow \mathcal {A}^{\mathsf {Verify}(k_V, \cdot , \cdot )}(k_P) : x \notin \mathcal {L}\wedge \mathsf {Verify}(k_V, x, \pi ) = 1] = \mathsf {negl}(\lambda ). $$

  • Zero-Knowledge: For all efficient adversaries \(\mathcal {A}\), there exists an efficient simulator \(\mathcal {S}= (\mathcal {S}_1, \mathcal {S}_2)\) such that if we take \((k_P, k_V) \leftarrow \mathsf {Setup}(1^\lambda )\) and \(\tau _V \leftarrow \mathcal {S}_1(1^\lambda , k_V)\), we have that

    $$ \left| \Pr [ \mathcal {A}^{\mathcal {O}_0(k_P, \cdot , \cdot )}(k_V) = 1] - \Pr [ \mathcal {A}^{\mathcal {O}_1(k_V, \tau _V, \cdot , \cdot )}(k_V) = 1] \right| = \mathsf {negl}(\lambda ), $$

    where the oracle \(\mathcal {O}_0(k_P, x, w)\) outputs \(\mathsf {Prove}(k_P, x, w)\) if \(\mathcal {R}(x, w) = 1\) and \(\bot \) otherwise, and the oracle \(\mathcal {O}_1(k_V, \tau _V, x, w)\) outputs \(\mathcal {S}_2(k_V, \tau _V, x)\) if \(\mathcal {R}(x, w) = 1\) and \(\bot \) otherwise.

Remark 4.2

(Comparison to NIZKs in the CRS Model). Our zero-knowledge definition in Definition 4.1 does not allow the simulator to choose the verification state \(k_V\). We can also consider a slightly weaker notion of zero-knowledge where the simulator also chooses the verification state:

  • Zero-Knowledge: For all efficient adversaries \(\mathcal {A}\), there exists an efficient simulator \(\mathcal {S}= (\mathcal {S}_1, \mathcal {S}_2)\) such that if we take \((k_P, k_V) \leftarrow \mathsf {Setup}(1^\lambda )\) and \((\tilde{k}_V, \tilde{\tau }_V) \leftarrow \mathcal {S}_1(1^\lambda )\), we have that

    $$ \left| \Pr [ \mathcal {A}^{\mathsf {Prove}(k_P, \cdot , \cdot )}(k_V) = 1] - \Pr [ \mathcal {A}^{\mathcal {O}(\tilde{k}_V, \tilde{\tau }_V, \cdot , \cdot )}(\tilde{k}_V) = 1] \right| = \mathsf {negl}(\lambda ), $$

    where the oracle \(\mathcal {O}(\tilde{k}_V, \tilde{\tau }_V, x, w)\) outputs \(\mathcal {S}_2(\tilde{k}_V, \tilde{\tau }_V, x)\) if \(\mathcal {R}(x, w) = 1\) and \(\bot \) otherwise.

We note that this definition of zero-knowledge captures the standard notion of NIZK arguments in the common reference string (CRS) model. Specifically, in the CRS model, the \(\mathsf {Setup}\) algorithm outputs a single CRS \(\sigma \). The proving and verification keys are both defined to be \(\sigma \).

Preprocessing NIZKs from homomorphic signatures. As described in Sect. 1.1, we can combine a homomorphic signature scheme (for general circuits) with any CPA-secure symmetric encryption scheme to obtain a preprocessing NIZK for general \(\mathsf {NP}\) languages. We give our construction and security analysis below. Combining the lattice-based construction of homomorphic signatures of [63] with any lattice-based CPA-secure encryption [6, 58], we obtain the first multi-theorem preprocessing NIZK from standard lattice assumptions (Corollary 4.5). In Remark 4.6, we note that a variant of Construction 4.3 also gives a publicly-verifiable preprocessing NIZK.

Construction 4.3

(Preprocessing NIZKs from Homomorphic Signatures). Fix a security parameter \(\lambda \), and define the following quantities:

  • Let \(\mathcal {R}:\{0,1\}^n \times \{0,1\}^m \rightarrow \{0,1\}\) be an \(\mathsf {NP}\) relation and \(\mathcal {L}\) be its corresponding language.

  • Let \(\varPi _{\mathsf {SE}}= (\mathsf {SE.KeyGen}, \mathsf {SE.Encrypt}, \mathsf {SE.Decrypt})\) be a symmetric encryption scheme with message space \(\{0,1\}^m\) and secret-key space \(\{0,1\}^\rho \).

  • For a message \(x \in \{0,1\}^n\) and ciphertext \(\mathsf {ct}\) from the ciphertext space of \(\varPi _{\mathsf {SE}}\), define the function \(f_{x,\mathsf {ct}}(k_{\mathsf {SE}}) \mathrel {\mathop :}=\mathcal {R}(x, \mathsf {SE.Decrypt}(k_{\mathsf {SE}}, \mathsf {ct}))\).

  • Let \(\varPi _{\mathsf {HS}}\) = (\(\mathsf {PrmsGen}, \mathsf {KeyGen}, \mathsf {Sign}, \mathsf {PrmsEval}, \mathsf {SigEval}, \mathsf {Hide}, \mathsf {Verify}\), \(\mathsf {VerifyFresh}\), \(\mathsf {VerifyHide}\)) be a homomorphic signature scheme with message space \(\{0,1\}\), message length \(\rho \), and function class \(\mathcal {C}\) that includes all functions of the form \(f_{x,\mathsf {ct}}\).Footnote 3

We construct a preprocessing NIZK argument \(\varPi _{\mathsf {NIZK}}= (\mathsf {Setup}, \mathsf {Prove}, \mathsf {Verify})\) as follows:

  • \(\mathsf {Setup}(1^\lambda ) \rightarrow (k_P, k_V)\): First, generate a secret key \(k_{\mathsf {SE}}\leftarrow \mathsf {SE.KeyGen}(1^\lambda )\). Next, generate and a signing-verification key-pair \((\mathsf {vk}_{\mathsf {HS}}, \mathsf {sk}_{\mathsf {HS}}) \leftarrow \mathsf {KeyGen}(1^\lambda )\). Next, sign the symmetric key and output

  • \(\mathsf {Prove}(k_P, x, w) \rightarrow \pi \): If \(\mathcal {R}(x, w) = 0\), output \(\bot \). Otherwise, parse . Let \(\mathsf {ct}\leftarrow \mathsf {SE.Encrypt}(k_{\mathsf {SE}}, w)\), and \(C_{x, \mathsf {ct}}\) be the circuit that computes the function \(f_{x, \mathsf {ct}}\) defined above. Compute the signature and then \(\sigma ^*_{x,\mathsf {ct}} \leftarrow \mathsf {Hide}(\mathsf {vk}_{\mathsf {HS}}, 1, \sigma _{x,\mathsf {ct}}')\). It outputs the proof \(\pi = (\mathsf {ct}, \sigma ^*_{x,\mathsf {ct}})\).

  • \(\mathsf {Verify}(k_V, x, \pi ) \rightarrow \{0,1\}\): Parse and \(\pi = (\mathsf {ct}, \sigma _{x, \mathsf {ct}}^*)\). Let \(C_{x, \mathsf {ct}}\) be the circuit that computes \(f_{x, \mathsf {ct}}\) defined above. Then, compute , and output \(\mathsf {VerifyHide}(\mathsf {pk}_{x, \mathsf {ct}}, \mathsf {vk}_{\mathsf {HS}}, 1, \sigma _{x,\mathsf {ct}}^*)\).

Theorem 4.4

(Preprocessing NIZKs from Homomorphic Signatures). Let \(\lambda \) be a security parameter and \(\mathcal {R}\) be an \(\mathsf {NP}\) relation (and let \(\mathcal {L}\) be its corresponding language). Let \(\varPi _{\mathsf {NIZK}}\) be the NIZK argument in the preprocessing model from Construction 4.3 (instantiated with a symmetric encryption scheme \(\varPi _{\mathsf {SE}}\) and a homomorphic signature scheme \(\varPi _{\mathsf {HS}}\)). If \(\varPi _{\mathsf {SE}}\) is CPA-secure and \(\varPi _{\mathsf {HS}}\) satisfies evaluation correctness, hiding correctness, selective unforgeability, and context-hiding, then \(\varPi _{\mathsf {NIZK}}\) is a NIZK argument for \(\mathcal {R}\) in the preprocessing model.

We give the proof of Theorem 4.4 in the full version [74]. Combining Construction 4.3 with a lattice-based homomorphic signature scheme [63] and any LWE-based CPA-secure encryption scheme [6, 58], we have the following corollary.

Corollary 4.5

(Preprocessing NIZKs from Lattices). Under the LWE assumption, there exists a multi-theorem preprocessing NIZK for \(\mathsf {NP}\).

Remark 4.6

(Publicly-Verifiable Preprocessing NIZK). Observe that the verification algorithm in Construction 4.3 does not depend on the signing key \(\mathsf {sk}_\mathsf {HS}\) of the signature scheme. Thus, we can consider a variant of Construction 4.3 where the verification key does not contain \(\mathsf {sk}_\mathsf {HS}\), and thus, the verification state can be made public. This does not compromise soundness because the prover’s state already includes the other components of the verification key. However, this publicly-verifiable version of the scheme does not satisfy zero-knowledge according to the strong notion of zero-knowledge in Definition 4.1. This is because without the signing key, the simulator is no longer able to simulate the signatures in the simulated proofs. However, if we consider the weaker notion of zero-knowledge from Remark 4.2 where the simulator chooses the verification key for the preprocessing NIZK, then the publicly-verifiable version of the scheme is provably secure. Notably, when the simulator constructs the verification key, it also chooses (and stores) the signing key for the homomorphic signature scheme. This enables the simulator to simulate signatures when generating the proofs. The resulting construction is a publicly-verifiable preprocessing NIZK (i.e., a “designated-prover” NIZK).

Remark 4.7

(Preprocessing NIZKs from Weaker Assumptions). By definition, any NIZK argument (or proof) system in the CRS model is also a preprocessing NIZK (according to the notion of zero-knowledge from Remark 4.2). In the CRS model (and without random oracles), there are several main families of assumptions known to imply NIZKs: number-theoretic conjectures such as quadratic residuosity [15, 16, 41],Footnote 4 trapdoor permutations [40, 44, 65], pairings [66], or indistinguishability obfuscation [86]. In the designated-verifier setting, constructions are also known from additively homomorphic encryption [34, 36, 39]. A number of works have also studied NIZKs in the preprocessing model, and several constructions have been proposed from one-way functions [38, 42, 69, 75] and oblivious transfer [73]. Since lattice-based assumptions imply one-way functions [6, 83], oblivious transfer [80], and homomorphic encryption [55, 83], one might think that we can already construct NIZKs in the preprocessing model from standard lattice assumptions. To our knowledge, this is not the case:

  • The NIZK constructions of [38, 42, 75] are single-theorem NIZKs, and in particular, zero-knowledge does not hold if the prover uses the same proving key to prove multiple statements. In these constructions, the proving key contains secret values, and each proof reveals a subset of the prover’s secret values. As a result, the verifier can combine multiple proofs together to learn additional information about each statement than it could have learned had it only seen a single proof. Thus, the constructions in [38, 42, 75] do not directly give a multi-theorem NIZK.

    A natural question to ask is whether we can use the transformation by Feige et al.  [44] who showed how to generically boost a NIZK (in the CRS model) with single-theorem zero-knowledge to obtain a NIZK with multi-theorem zero-knowledge. The answer turns out to be negative: the [44] transformation critically relies on the fact that the prover algorithm is publicly computable, or equivalently, that the prover algorithm does not depend on any secrets.Footnote 5 This is the case in the CRS model, since the prover algorithm depends only on the CRS, but in the preprocessing model, the prover’s algorithm can depend on a (secret) proving key \(k_P\). In the case of [38, 42, 75], the proving key must be kept private for zero-knowledge. Consequently, the preprocessing NIZKs of [38, 42, 75] do not give a general multi-theorem NIZK in the preprocessing model.

  • The (preprocessing) NIZK constructions based on oblivious transfer [73], the “MPC-in-the-head” paradigm [69], and the ones based on homomorphic encryption [34, 36, 39] are designated-verifier, and in particular, are vulnerable to the “verifier rejection” problem. Specifically, soundness is compromised if the prover can learn the verifier’s response to multiple adaptively-chosen statements and proofs. For instance, in the case of [73], an oblivious transfer protocol is used to hide the verifier’s challenge bits; namely, the verifier’s challenge message is fixed during the preprocessing, which means the verifier uses the same challenge to verify every proof. A prover that has access to a proof-verification oracle is able to reconstruct the verifier’s challenge bit-by-bit and compromise soundness of the resulting NIZK construction. A similar approach is taken in the preprocessing NIZK construction of [69].

From the above discussion, the only candidates of general multi-theorem NIZKs in the preprocessing model are the same as those in the CRS model. Thus, this work provides the first candidate construction of a multi-theorem NIZK in the preprocessing model from standard lattice assumptions. It remains an open problem to construct multi-theorem NIZKs from standard lattice assumptions in the standard CRS model.

In the full version of this paper [74], we highlight several additional properties of our multi-theorem preprocessing NIZK. We also describe another approach for instantiating our construction using context-hiding homomorphic MACs [28,29,30, 54]. While existing homomorphic MAC constructions from one-way functions do not suffice for our constructions (they are not context-hiding), they do provide another potential avenue towards realizing multi-theorem preprocessing NIZKs from weaker assumptions.

5 Blind Homomorphic Signatures

One limitation of preprocessing NIZKs is that we require a trusted setup to generate the proving and verification keys. One solution is to have the prover and the verifier run a (malicious-secure) two-party computation protocol (e.g., [76]) to generate the proving and verification keys. However, generic MPC protocols are often costly and require making non-black-box use of the underlying homomorphic signature scheme. In this section, we describe how this step can be efficiently implemented using a new primitive called blind homomorphic signatures. We formalize our notion in the model of universal composability [24]. This has the additional advantage of allowing us to realize the stronger notion of a preprocessing universally-composable NIZK (UC-NIZK) from standard lattice assumptions. We give our UC-NIZK construction and then describe several applications to boosting the security of MPC in Sect. 6. We refer to the full version for a review of the UC model.

We now define the ideal blind homomorphic signature functionality \(\mathcal {F}_{\textsc {bhs}}\). Our definition builds upon existing definitions of the ideal signature functionality \(\mathcal {F}_{\textsc {sig}}\) by Canetti [25] and the ideal blind signature functionality \(\mathcal {F}_{\textsc {blsig}}\) by Fischlin [47]. To simplify the presentation, we define the functionality in the two-party setting, where there is a special signing party (denoted \(\mathbf {S}\)) and a single receiver who obtains the signature (denoted \(\mathbf {R}\)). While this is a simpler model than the multi-party setting considered in [25, 47], it suffices for the applications we describe in this work.

Ideal signature functionalities. The \(\mathcal {F}_{\textsc {sig}}\) functionality from [25] essentially provides a “registry service” where a distinguished party (the signer) is able to register message-signature pairs. Moreover, any party that possesses the verification key can check whether a particular message-signature pair is registered (and thus, constitutes a valid signature). The ideal functionality does not impose any restriction on the structure of the verification key or the legitimate signatures, and allows the adversary to choose those values. In a blind signature scheme, the signing process is replaced by an interactive protocol between the signer and the receiver, and the security requirement is that the signer does not learn the message being signed. To model this, the \(\mathcal {F}_{\textsc {blsig}}\) functionality from [47] asks the adversary to provide the description of a stateless algorithm \(\mathsf {IdealSign}\) in addition to the verification key to the ideal functionality \(\mathcal {F}_{\textsc {blsig}}\). For blind signing requests involving an honest receiver, the ideal functionality uses \(\mathsf {IdealSign}\) to generate the signatures. The message that is signed (i.e., the input to \(\mathsf {IdealSign}\)) is not disclosed to either the signer or the adversary. This captures the intuitive requirement that the signer does not learn the message that is signed in a blind signature scheme. Conversely, if a corrupt user makes a blind signing request, then the ideal functionality asks the adversary to supply the signature that could result from such a request.

Capturing homomorphic operations. In a homomorphic signature scheme, a user possessing a signature \(\sigma \) on a message x should be able to compute a function g on \(\sigma \) to obtain a new signature \(\sigma ^*\) on the message g(x). In turn, the verification algorithm checks that \(\sigma ^*\) is a valid signature on the value g(x) and importantly, that it is a valid signature with respect to the function g. Namely, the signature is bound not only to the computed value g(x) but also to the function g.Footnote 6 To extend the ideal signature functionality to support homomorphic operations on signatures, we begin by modifying the ideal functionality to maintain a mapping between function-message pairs and signatures (rather than a mapping between messages and signatures). In this case, a fresh signature \(\sigma \) (say, output by the blind signing protocol) on a message x would be viewed as a signature on the function-message pair \((f_{\mathsf {id}}, x)\), where \(f_{\mathsf {id}}\) here denotes the identity function. Then, if a user subsequently computes a function g on \(\sigma \), the resulting signature \(\sigma ^*\) should be viewed as a signature on the new pair \((g \circ f_{\mathsf {id}}, g(x)) = (g, g(x))\). In other words, in a homomorphic signature scheme, signatures are bound to a function-message pair, rather than a single message.

Next, we introduce an additional signature-evaluation operation to the ideal functionality. There are several properties we desire from our ideal functionality:

  • The ideal signature functionality allows the adversary to decide the structure of the signatures, so it is only natural that the adversary also decides the structure of the signatures output by the signature evaluation procedure.

  • Signature evaluation should be compatible with the blind signing process. Specifically, the receiver should be able to compute on a signature it obtained from the blind signing functionality, and moreover, the computation (if requested by an honest receiver) should not reveal to the adversary on which signature or message the computation was performed.

  • The computed signature should also hide the input message. In particular, if the receiver obtains a blind signature on a message x and later computes a signature \(\sigma ^*\) on g(x), the signature \(\sigma ^*\) should not reveal the original (blind) message x.

To satisfy these properties, the ideal functionality asks the adversary to additionally provide the description of a stateless signature evaluation algorithm \(\mathsf {IdealEval}\) (in addition to \(\mathsf {IdealSign}\)). The ideal functionality uses \(\mathsf {IdealEval}\) to generate the signatures when responding to evaluation queries. We capture the third property (that the computed signatures hide the input message to the computation) by setting the inputs to \(\mathsf {IdealEval}\) to only include the function g that is computed and the output value of the computation g(x). The input message x is not provided to \(\mathsf {IdealEval}\).

Under our definition, the signature evaluation functionality takes as input a function-message pair \((f_{\mathsf {id}}, x)\), a signature \(\sigma \) on \((f_{\mathsf {id}}, x)\) (under the verification key \(\mathsf {vk}\) of the signature scheme), and a description of a function g (to compute on x). The output is a new signature \(\sigma ^*\) on the pair (g, g(x)). That is, \(\sigma ^*\) is a signature on the value g(x) with respect to the function g. When the evaluator is honest, the signature on (g, g(x)) is determined by \(\mathsf {IdealEval}(g, g(x))\) (without going through the adversary). As discussed above, \(\mathsf {IdealEval}\) only takes as input the function g and the value g(x), and not the input; this means that the computed signature \(\sigma ^*\) hides all information about x other than what is revealed by g(x). When the evaluator is corrupt, the adversary chooses the signature on (g, g(x)), subject to basic consistency requirements.Footnote 7 Once an evaluated signature is generated, the functionality registers the new signature \(\sigma ^*\) on the pair (g, g(x)). Our definition implicitly requires that homomorphic evaluation be non-interactive. Neither the adversary nor the signer is notified or participates in the protocol.

Preventing selective failures. In our definition, the functionalities \(\mathsf {IdealSign}\) and \(\mathsf {IdealEval}\) must either output \(\bot \) on all inputs, or output \(\bot \) on none of the inputs. This captures the property that a malicious signer cannot mount a selective failure attack against an honest receiver, where the function of whether the receiver obtains a signature or not in the blind signing protocol varies depending on its input message. In the case of the blind signing protocol, we do allow a malicious signer to cause the protocol to fail, but this failure event must be independent of the receiver’s message. We capture this in the ideal functionality by allowing a corrupt signer to dictate whether a blind signing execution completes successfully or not. However, the corrupt signer must decide whether a given protocol invocation succeeds or fails independently of the receiver’s message.

Simplifications and generalizations. In defining our ideal blind homomorphic signature functionality, we impose several restrictions to simplify the description and analysis. We describe these briefly here, and note how we could extend the functionality to provide additional generality. Note that all of the applications we consider (Sect. 6) only require the basic version of the functionality (Fig. 1), and not its generalized variants.

  • One-time signatures. The ideal blind homomorphic signature functionality supports blind signing of a single message. Namely, the ideal blind signing functionality only responds to the first signing request from the receiver and ignores all subsequent requests. Moreover, the ideal functionality only supports signature evaluation requests after a signature has been successfully issued by the ideal signing functionality. We capture this via a \(\mathsf {ready}\) flag that is only set at the conclusion of a successful signing operation. We can relax this single-signature restriction, but at the cost of complicating the analysis.

  • Single-hop evaluation. Our second restriction on the ideal blind homomorphic signature functionality is we only consider “single-hop” homomorphic operations: that is, we only allow homomorphic operations on fresh signatures. In the ideal functionality, we capture this by having the signature evaluation functionality ignore all requests to compute on function-message pairs (f, x) where \(f \ne f_{\mathsf {id}}\) is not the identity function. A more general definition would also consider “multi-hop” evaluation where a party can perform arbitrarily many sequential operations on a signature. The reason we present our definition in the simpler single-hop setting is because existing constructions of homomorphic signatures [63] (which we leverage in our construction) do not support the multi-hop analog of our definition. This is because under our definition, the ideal evaluation functionality essentially combines the homomorphic evaluation with the context-hiding transformation in standard homomorphic signature schemes. The current homomorphic signature candidate [63] does not support homomorphic computation after performing context-hiding, and so, cannot be used to realize the more general “multi-hop” version of our functionality. For this reason, we give our definition in the single-hop setting.

We give the formal specification of the ideal blind homomorphic signature functionality \(\mathcal {F}_{\textsc {bhs}}\) in Fig. 1.

Fig. 1.
figure 1figure 1

The \(\mathcal {F}_{\textsc {bhs}}\) functionality. The description continues on the next page.

Full size image

5.1 Constructing Blind Homomorphic Signatures

In Fig. 2, we give the formal description of our blind homomorphic signature protocol \(\varPi _\textsc {bhs}\) in the \(\mathcal {F}_{\textsc {ot}}^{\ell ,s}\)-hybrid model.Footnote 8 Here, we provide a brief overview of the construction. As discussed in Sect. 1.1, our construction combines homomorphic signatures with any UC-secure oblivious transfer protocol [27]. The key-generation, signature-verification, and signature-evaluation operations in \(\varPi _\textsc {bhs}\) just correspond to running the underlying \(\varPi _{\mathsf {HS}}\) algorithms.

The blind signing protocol is interactive and relies on OT. Since we use a bitwise homomorphic signature scheme, a signature on an \(\ell \)-bit message consists of \(\ell \) signatures, one for each bit of the message. In the first step of the blind signing protocol, the signer constructs two signatures (one for the bit 0 and one for the bit 1) for each bit position of the message. The receiver then requests the signatures corresponding to the bits of its message using the OT protocol. Intuitively, the OT protocol ensures that the signer does not learn which set of signatures the receiver requested and the receiver only learns a single signature for each bit position. However, this basic scheme is vulnerable to a “selective-failure” attack where the signer strategically generates invalid signatures for certain bit positions of the message \(\varvec{x}\). As a result, whether the receiver obtains a valid signature on its entire message becomes correlated with its message itself. To prevent this selective-failure attack, we use the standard technique of having the receiver first split its message \(\varvec{x}\) into a number of random shares \(\varvec{w}_1, \ldots , \varvec{w}_t\) where \(\varvec{x}= \bigoplus _{i \in [t]} \varvec{w}_i\). Instead of asking for a signature on \(\varvec{x}\) directly, it instead asks for a signature on the shares \(\varvec{w}_1, \ldots , \varvec{w}_t\). Since the signatures on the shares \(\varvec{w}_1, \ldots , \varvec{w}_t\) are homomorphic, the receiver can still compute a signature on the original message \(\varvec{x}\) and hence, correctness of signing is preserved. Moreover, as we show in the proof of Theorem 5.1, unless the malicious signer correctly guesses all of the shares of \(\varvec{w}_1, \ldots , \varvec{w}_t\) the receiver chose, the probability that the receiver aborts (due to receiving an invalid signature) is independent of \(\varvec{x}\) no matter how the malicious signer generates the signatures. We formally summarize the security properties of \(\varPi _\textsc {bhs}\) in the following theorem, but defer its proof to the full version [74].

Theorem 5.1

(Blind Homomorphic Signatures). Fix a security parameter \(\lambda \). Define parameters \(\ell \), t, and s as in \(\varPi _\textsc {bhs}\) (Fig. 2) where \(t = \omega (\log \lambda )\). Let \(\mathcal {H}\) be a function class over \(\{0,1\}^\ell \) and let \(\varPi _{\mathsf {HS}}\) be a homomorphic signature scheme for the message space \(\{0,1\}\) and function class \(\mathcal {H}'\) such that for any function \(f \in \mathcal {H}\), we have \(f \circ f_{\mathsf {recon}}\in \mathcal {H}'\), where \(f_{\mathsf {recon}}\) is the share-reconstruction function from Fig. 2. Suppose that \(\varPi _{\mathsf {HS}}\) satisfies correctness, unforgeability, and context-hiding. Then, the protocol \(\varPi _\textsc {bhs}\) (when instantiated with \(\varPi _{\mathsf {HS}}\)) securely realizes the ideal functionality \(\mathcal {F}_{\textsc {bhs}}\) (Fig. 1) with respect to function class \(\mathcal {H}\) in the presence of (static) malicious adversaries in the \(\mathcal {F}_{\textsc {ot}}^{\ell , s}\)-hybrid model.

Fig. 2.
figure 2figure 2

The \(\varPi _\textsc {bhs}\) protocol. The protocol description continues on the next page.

Full size image
Fig. 3.
figure 3

Preprocessing ZK argument in the \(\mathcal {F}_{\textsc {bhs}}\)-hybrid model.

Full size image

Blind homomorphic signatures from LWE. Combining the fully-secure homomorphic signature scheme described in the full version [74] (based on [63]) with the lattice-based UC-secure oblivious transfer protocol from [80], we obtain a blind homomorphic signature scheme from standard lattice assumptions. We describe our instantiation below.

Fact 5.2

(Oblivious Transfer from LWE [80]). Let \(\lambda \) be a security parameter and define parameters \(\ell , s = \mathsf {poly}(\lambda )\). Then, under the LWE assumption, there exists a protocol \(\varPi _\textsc {ot}\) that security realizes the ideal OT functionality \(\mathcal {F}_{\textsc {ot}}^{\ell ,s}\) in the presence of malicious adversaries in the CRS model (and assuming static corruptions). Moreover, the protocol \(\varPi _{\textsc {ot}}\) is round-optimal: it consists of one message from the receiver to the signer and one from the receiver to the signer.

Corollary 5.3

(Blind Homomorphic Signatures from LWE). Let \(\lambda \) be a security parameter. Then, under the LWE assumption, for all \(d = \mathsf {poly}(\lambda )\), there exists a protocol \(\varPi _\textsc {bhs}'\) that securely realizes \(\mathcal {F}_{\textsc {bhs}}\) for the class of depth-d Boolean circuits in the presence of malicious adversaries in the CRS model (and assuming static corruptions). Moreover, the protocol \(\varPi _{\textsc {bhs}}'\) satisfies the following properties:

  • The key-generation, signature-verification, and signature-evaluation protocols are non-interactive.

  • The signature-generation protocol (i.e., blind signing) is a two-round interactive protocol between the signer and the receiver (one message each way).

  • The length of a signature is \(\mathsf {poly}(\lambda , d)\).

Proof

Let \(\varPi _\textsc {bhs}\) be the protocol from Fig. 2 instantiated with a lattice-based homomorphic signature scheme (see the full version [74]). By Theorem 5.1, protocol \(\varPi _\textsc {bhs}\) securely realizes \(\mathcal {F}_{\textsc {bhs}}\) in the \(\mathcal {F}_{\textsc {ot}}^{\ell , s}\)-hybrid model, for some \(\ell , s = \mathsf {poly}(\lambda )\). We let \(\varPi _\textsc {bhs}'\) be the protocol obtained by instantiating the functionality \(\mathcal {F}_{\textsc {ot}}^{\ell , s}\) in \(\varPi _\textsc {bhs}\) with the protocol from Fact 5.2. Security of \(\varPi _\textsc {bhs}'\) then follows from the universal composition theorem. Key generation, signature verification, and signature evaluation in \(\varPi _\textsc {bhs}'\) simply corresponds to invoking the associated functionalities of the underlying homomorphic signature scheme, and thus, are non-interactive. The signature length is also inherited from \(\varPi _{\mathsf {HS}}\). The blind signing protocol reduces to a single invocation of \(\mathcal {F}_{\textsc {ot}}^{\ell , s}\), which by Fact 5.2, can be implemented by just two rounds of interaction.

6 Universally-Composable Preprocessing NIZKs

In this section, we show how to combine blind homomorphic signatures with CPA-secure encryption to obtain UC-NIZKs in the preprocessing model from standard lattice assumptions. We give our protocol \(\varPi _{\mathsf {ZK}}\) in the \(\mathcal {F}_{\textsc {bhs}}\)-hybrid model in Fig. 3. Next, we state the formal security theorem and describe how to instantiate it from standard lattice assumptions. We give the proof of Theorem 6.1 in the full version of this paper [74].

Theorem 6.1

(Preprocessing Zero-Knowledge Arguments). Let \(\varPi _{\mathsf {SE}}= (\mathsf {KeyGen}, \mathsf {Encrypt}, \mathsf {Decrypt})\) be a CPA-secure encryption scheme. Then, the protocol \(\varPi _{\mathsf {ZK}}\) in Fig. 3 (instantiated with \(\varPi _{\mathsf {SE}}\)) securely realizes \(\mathcal {F}_{\mathsf {ZK}}\) in the presence of (static) malicious adversaries in the \(\mathcal {F}_{\textsc {bhs}}\)-hybrid model.

Corollary 6.2

(Preprocessing UC-NIZKs from LWE). Let \(\lambda \) be a security parameter. Then, under the LWE assumption, for all \(d = \mathsf {poly}(\lambda )\), there exists a protocol \(\varPi _{\mathsf {NIZK}}'\) that securely realizes \(\mathcal {F}_{\mathsf {ZK}}\) in the presence of (static) malicious adversaries in the CRS model for all \(\mathsf {NP}\) relations \(\mathcal {R}\) that can be computed by a circuit of depth at most d. The protocol \(\varPi _{\mathsf {NIZK}}'\) satisfies the following properties:

  • The (one-time) preprocessing phase is a two-round protocol between the prover and the verifier.

  • The prover’s and verifier’s algorithms are both non-interactive.

  • If \(\mathcal {R}\) is an \(\mathsf {NP}\) relation, then the length of a proof of membership for the language associated with \(\mathcal {R}\) is \(m + \mathsf {poly}(\lambda , d)\), where m is the size of the witness associated with \(\mathcal {R}\).

Proof

Fix a depth bound \(d = \mathsf {poly}(\lambda )\). First, we can instantiate the CPA-secure encryption scheme \(\varPi _{\mathsf {SE}}= (\mathsf {KeyGen}, \mathsf {Encrypt}, \mathsf {Decrypt})\) in Fig. 3 from lattices using any lattice-based CPA-secure symmetric encryption scheme [6, 58]. Let \(d'\) be a bound on the depth of the circuit that computes the \(\mathsf {CheckWitness}_{\mathcal {R}, \mathsf {ct}, x}\) function in Fig. 3. Note that \(d' = \mathsf {poly}(\lambda , d)\), since the depth of the relation \(\mathcal {R}\) is bounded by d and the depth of the \(\mathsf {Decrypt}\) function is \(\mathsf {poly}(\lambda )\). By Corollary 5.3, under the LWE assumption, there exists a protocol \(\varPi _\textsc {bhs}'\) that securely realizes \(\mathcal {F}_{\textsc {bhs}}\) for the class of all depth-\(d'\) Boolean circuits in the presence of (static) malicious adversaries. The claim then follows by combining Theorem 6.1 with Corollary 5.3 and the universal composition theorem. We now check the additional properties:

  • The preprocessing phase corresponds to the blind signing protocol of \(\varPi _\textsc {bhs}'\), which is a two-round protocol between the signer and the verifier.

  • The prover’s algorithm corresponds to signature evaluation while the verifier’s algorithm corresponds to signature verification. Both of these are non-interactive in \(\varPi _\textsc {bhs}'\).

  • The length of a proof for an \(\mathsf {NP}\) relation \(\mathcal {R}\) consists of an encryption of the witness under \(\varPi _{\mathsf {SE}}\) (of size \(m + \mathsf {poly}(\lambda )\)) and a signature under \(\varPi _\textsc {bhs}'\) (of size \(\mathsf {poly}(\lambda , d)\)). The total size is bounded by \(m + \mathsf {poly}(\lambda , d)\).    \(\square \)

6.1 Applications to MPC

In the full version of this paper, we describe several applications of our preprocessing UC-NIZKs to boosting the security of MPC protocols. Specifically, we show that combining our construction with the round-optimal, semi-malicious MPC protocol of Mukherjee-Wichs [78] yields a round-optimal, malicious-secure MPC protocol from lattices in a reusable preprocessing model where the communication complexity only depends on the size of the inputs/outputs. Then, we show how to obtain a succinct version of the GMW [59, 60] compiler from lattice assumptions.