Post-Quantum Zero-Knowledge and Signatures from Symmetric-Key Primitives

Transcription

1 Post-Quantum Zero-Knowledge and Signatures from Symmetric-Key Primitives Melissa Chase Microsoft Research Claudio Orlandi Aarhus University David Derler Graz University of Technology Sebastian Ramacher Graz University of Technology Steven Goldfeder Princeton University Christian Rechberger Graz University of Technology & Denmark Technical University ABSTRACT Daniel Slamanig AIT Austrian Institute of Technology We propose a new class of post-quantum digital signature schemes that: (a) derive their security entirely from the security of symmetric-key primitives, believed to be quantum-secure, and (b) have extremely small keypairs, and, (c) are highly parameterizable. In our signature constructions, the public key is an image y = f (x) of a one-way function f and secret key x. A signature is a non-interactive zero-knowledge proof of x, that incorporates a message to be signed. For this proof, we leverage recent progress of Giacomelli et al. (USENIX 16) in constructing an efficient Σ-protocol for statements over general circuits. We improve this Σ-protocol to reduce proof sizes by a factor of two, at no additional computational cost. While this is of independent interest as it yields more compact proofs for any circuit, it also decreases our signature sizes. We consider two possibilities to make the proof non-interactive: the Fiat-Shamir transform and Unruh s transform (EUROCRYPT 12, 15, 16). The former has smaller signatures, while the latter has a security analysis in the quantum-accessible random oracle model. By customizing Unruh s transform to our application, the overhead is reduced to 1.6x when compared to the Fiat-Shamir transform, which does not have a rigorous post-quantum security analysis. We implement and benchmark both approaches and explore the possible choice of f, taking advantage of the recent trend to strive for practical symmetric ciphers with a particularly low number of multiplications and end up using LowMC (EUROCRYPT 15). The full version of this paper is available as IACR Cryptology eprint Archive Report 2017/279. This paper is a merge of [34, 46]. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. CCS 17, October 30-November 3, 2017, Dallas, TX, USA 2017 Copyright held by the owner/author(s). Publication rights licensed to Association for Computing Machinery. ACM ISBN /17/10... $ Greg Zaverucha Microsoft Research gregz@microsoft.com CCS CONCEPTS Security and privacy Digital signatures; Theory of computation Cryptographic primitives; KEYWORDS Post-quantum cryptography, zero-knowledge, signatures, block cipher, Fiat-Shamir, Unruh, implementation 1 INTRODUCTION More than two decades ago Shor published his polynomial-time quantum algorithm for factoring and computing discrete logarithms [81]. Since then, we know that a sufficiently powerful quantum computer is able to break nearly all public key cryptography used in practice today. This motivates the invention of cryptographic schemes with post quantum (PQ) security, i.e., security against attacks by a quantum computer. Even though no sufficiently powerful quantum computer currently exists, NIST recently announced a post-quantum crypto proect 1 to avoid a rushed transition from current cryptographic algorithms to PQ secure algorithms. The proect is seeking proposals for public key encryption, key exchange and digital signatures thought to have PQ security. The deadline for proposals is fall In this paper we are concerned with constructing signature schemes for the post-quantum era. The building blocks of our schemes are interactive honest-verifier zero-knowledge proof systems (Σ-protocols) for statements over general circuits and symmetric-key primitives, that are conectured to remain secure in a post-quantum world. Post-Quantum Signatures. Perhaps the oldest signature scheme with post-quantum security are one-time Lamport signatures [63], built using hash functions. As Grover s quantum search algorithm can invert any black-box function [52] with a quadratic speed-up over classical algorithms, one has to double the bit size of the hash function s domain, but still requires no additional assumptions to provably achieve post-quantum security. Combined with Merkletrees, this approach yields stateful signatures for any polynomial

2 number of messages [71], where the state ensures that a one-time signature key from the tree is not reused. By making the tree very large, and randomly selecting a key from it (cf. [47]), along with other optimizations, yields practical stateless hash-based signatures [17]. There are also existing schemes that make structured (or numbertheoretic) assumptions. Code-based signature schemes can be obtained from identification schemes based on the syndrome decoding (SD) problem [70, 82, 86] by applying a variant of the well-known Fiat-Shamir (FS) transform [40]. Lattice-based signature schemes secure under the short integer solution (SIS) problem on lattices following the Full-Domain-Hash (FDH) paradigm [13] have been introduced in [43]. More efficient approaches [7, 9, 65, 66] rely on the FS transform instead of FDH. BLISS [36], a very practical scheme, also relies on the FS transform, but buys efficiency at the cost of more pragmatic assumptions, i.e., a ring version of the SIS problem. For signatures based on problems related to multivariate systems of quadratic equations only recently provably secure variants relying on the FS transform have been proposed [56]. When it comes to confidence in the underlying assumptions, hash-based signatures are arguably the preferred candidate among all existing approaches. All other practical signatures require an additional structured assumption (in addition to assumptions related to hash functions). 1.1 Contributions We contribute a novel class of practical post-quantum signature schemes. Our approach only requires symmetric key primitives like hash functions and block ciphers and does not require additional structured hardness assumptions. Along the way to building our signature schemes, we make several contributions of general interest to zero-knowledge proofs both in the classical and post-quantum setting: We improve ZKBoo [44], a recent Σ-protocol for proving statements over general circuits. We reduce the transcript size by more than half without increasing the computational cost. We call the improved protocol ZKB++. This improvement is of general interest outside of our application to post-quantum signatures as it yields significantly more concise zero knowledge proofs even in the classical setting. We also show how to apply Unruh s generic transform [83 85] to obtain a non-interactive counterpart of ZKB++ that is secure in the quantum-accessible random oracle model (QROM; see [18]). To our knowledge, we are the first to apply Unruh s transform in an efficient signature scheme. Unruh s construction is generic, and does not immediately yield compact proofs. However, we specialize the construction to our application, and we find the overhead was surprisingly low whereas a generic application of Unruh s transform incurs a 4x increase in size when compared to FS, we were able to reduce the size overhead of Unruh s transform to only 1.6x. Again, this has applications wider than our signature schemes as the protocol can be used for non-interactive post-quantum zero knowledge proofs secure in the QROM. We build upon these results to achieve our central contribution: two concrete signature schemes. In both schemes the public key is set up to be an image y = f (k) with respect to one-way function f and secret key k. We then turn an instance of ZKB++ to prove knowledge of k into two signature schemes one using the FS transform and the other using Unruh s transform. The FS variant, dubbed Fish, yields a signature scheme that is secure in the ROM, whereas the Unruh variant, dubbed Picnic, yields a signature scheme that is secure in the QROM, and we include a complete security proof. We review symmetric-key primitives with respect to their suitability to serve as f in our application and conclude that the LowMC family of block ciphers [4, 6] is well suited. We explore the parameter space of LowMC and show that we can obtain various trade-offs between signature size and computation time. Thereby, our approach turns out to be very flexible as besides the aforementioned trade-offs we are also able to adust the security parameter of our construction in a very fine-grained way. We provide an implementation of both schemes for 128-bit postquantum security, demonstrating the practical relevance of our approach. In particular, we provide two reference implementations on GitHub 2,3. Moreover, we rigorously compare our schemes with other practical provably secure post-quantum schemes. 1.2 Related Work We now give a brief overview of other candidate schemes and defer a detailed comparison of parameters and performance to Section 7. We start with the only existing instantiation that solely relies on standard assumptions, i.e., comes with a security proof in the standard model (SM). The remaining existing schemes rely on structured assumptions related to codes, lattices and multivariate systems of quadratic equations that are assumed to be quantum safe and have a security proof in the ROM. At the end of the section, we review the state of the art in zero-knowledge proofs for nonalgebraic statements. Hash-Based Signatures (SM). Hash-based signatures are attractive as they can be proven secure in the standard model (i.e., without ROs) under well-known properties of hash functions such as second preimage resistance. Unfortunately, highly efficient schemes like XMSS [22] are stateful, which seems to be problematic for practical applications [68]. Stateless schemes like SPHINCS [17] are thus more desirable, but this comes at reduced efficiency and increased signature sizes. SPHINCS has a tight security reduction to security of its building blocks, i.e., hash functions, PRGs and PRFs. At the 128-bit post-quantum security level, signatures are about 41 kb in size, and keys are of size about 1 kb each. Code-Based Signatures (ROM). In the code-based setting the most prominent and provably secure approach is to convert identification schemes due to Stern [82] and Véron [86] to signatures using FS. For the 128-bit PQ security level one obtains signature sizes of around 129 kb (in the best case) and public key size of

3 160 bytes. 4 We note that there are also other code-based signatures [27] based on the Niederreiter [72] dual of the McEliece cryptosystem [67], which do not come with a security reduction, have shown to be insecure [38] and also do not seem practical [64]. There is a more recent provably secure approach [37], however, it is not immediate if this leads to efficient signatures. Lattice-Based Signatures (ROM). For lattice based signatures there are two maor directions. The first are schemes that rely on the hardness of worst-to-average-case problems in standard lattices [7, 9, 30, 43, 66]. Although they are desirable from a security point of view, they suffer from huge public keys, i.e., in the orders of a few to some 10 MBs. TESLA [7] (based upon [9, 66]) improves all aspects in the performance of GPV [43], but still has keys on the order of 1 MB. More efficient lattice-based schemes are based on ring analogues of classical lattice problems [3, 10, 11, 36, 53] whose security is related to hardness assumptions in ideal lattices. These constructions drop key sizes to the order of a few kbs. Most notable is BLISS [35, 36], which achieves performance nearly comparable to RSA. However, it must be noted, that ideal lattices have not been investigated nearly as deeply as standard lattices and thus there is less confidence in the assumptions (cf. [75]). MQ-Based Signatures (ROM). Recently, Hülsing et al. in [56] proposed a post-quantum signature scheme (MQDSS) whose security is based on the problem of solving a multivariate system of quadratic equations. Their scheme is obtained by building upon the 5-pass (or 3-pass) identification scheme in [79] and applying the FS transform. For 128-bit post-quantum security, signature sizes are about 40 kb, public key sizes are 72 bytes and secret key sizes are 64 bytes. We note that there are other MQ-based approaches like Unbalanced Oil-and-Vinegar (UOV) variants [74] or FHEv variants (cf. [76]), having somewhat larger keys (order of kbs) but much shorter signatures. However, they have no provable security guarantees, the parameter choice seems very aggressive, there are no parameters for conservative (post-quantum) security levels, and no implementations are available. Supersingular Isogenies (QROM). Yoo et al. in [87] proposed a post-quantum signature scheme whose security is based on supersingular isogeny problems. The scheme is obtained by building upon the identification scheme in [39] and applying the Unruh transform. For 128-bit post-quantum security, signature sizes are about 140 kb, public key sizes are 768 bytes, and secret key sizes are 49 bytes. At the same time, Galbraith et al. [41] published a preprint containing one conceptually identical isogeny-based construction, and one based on endomorphism rings. They report improved signature sizes using a time-space trade-off and only present their improvements in terms of classical security parameters. Zero-Knowledge for Arithmetic Circuits. Zero-knowledge (ZK) proofs [49] are a powerful tool and exist for any language in NP [48]. Nevertheless, practically efficient proofs were until recently only known for restricted languages covering algebraic statements in certain algebraic structures, e.g., discrete logarithms [28, 80] or equations over bilinear groups [51]. Expressing any NP language 4 The given estimates are taken from a recent talk of Nicolas Sendrier (available at https: //pqcrypto.eu.org/mini.html), as, unfortunately, there are no free implementations available. as a combination of algebraic circuits could be done for example by expressing the relation as a circuit, however for circuits of practical interest (such as hash functions or block ciphers), this quickly becomes prohibitively expensive. Even SNARKS, where proof size can be made small (and constant) and verification is highly efficient, have very costly proofs (cf. [15, 26, 42] and the references therein). 5 Unfortunately, signatures require small proof computation times (efficient signing procedures), and this direction is not suitable. Quite recently, dedicated ZK proof systems for statements expressed as Boolean circuits by Jawurek et al. [58] and statements expressed as RAM programs by Hu et al. [55] have been proposed. As we exclusively focus on circuits, let us take a look at [58]. They proposed using garbled circuits to obtain ZK proofs, which allow efficient proofs for statements like knowledge of x for y = SHA-256(x). Unfortunately, this approach is inherently interactive and thus not suitable for the design of practical signature schemes. The very recent ZKBoo protocol due to Giacomelli et al. [44], which we build upon, for the first time, allows to construct non-interactive zero-knowledge (NIZK) proofs with performance being of interest for practical applications. QROM vs ROM. One way of arguing security for signatures obtained via the FS heuristic in the stronger QROM is to assume that it simply holds as long as the underlying protocol and the hash function used to instantiate the random oracle (RO) are quantumsecure. However, it is known [18] that there are signature schemes secure in the ROM that are insecure in the quantum-accessible ROM (QROM), i.e., when the adversary can issue quantum queries to the RO. One central issue in this context is how to handle the rewinding of adversaries within security reductions as in the FS transform [31]. Possibilities to circumvent this issue are via historyfree reductions [18] or the use of oblivious commitments within the FS transform, which is not applicable to our approach. Although many existing schemes ignore QROM security, given the general uncertainty of the capabilities of quantum adversaries, we prefer to avoid this assumption. Building upon results from Unruh [83 85], we achieve provable security in the QROM under reasonable assumptions. 2 BUILDING BLOCKS Below, we informally recall the notion of Σ-protocols and other standard primitives. Sigma Protocol. A sigma protocol (or Σ-protocol) is a three flow protocol between a prover Prove and a verifier Verify, where transcripts have the form (r,c,s). Thereby, r and s are computed by Prove and c is a challenge chosen by Verify. Let f be a relation such that f (x) = y, where y is common input and x is a witness known only to Prove. Verify accepts if ϕ(y,r,c,s) = 1 for an efficiently computable predicate ϕ. There also exists an efficient simulator, given y and a randomly chosen c, outputs a transcript (r,c,s) for y that is indistinguishable from a real run of the protocol for x,y. 5 Using SNARKS is reasonable in scenarios where provers are extremely powerful (such as verifiable computing [42]) or the runtime of the prover is not critical (such as Zerocash [14]). 1827

4 n-special Soundness. A Σ-protocol has n-special soundness if n transcripts (r,c 1,s 1 ),..., (r,c n,s n ) with distinct c i guarantee that a witness may be efficiently extracted. Fiat-Shamir. The FS transform [40] converts a Σ-protocol into a non-interactive zero knowledge proof of knowledge. A Σ-protocol consists of a transcript (r,c,s). The corresponding non-interactive proof (r,c,s ) generates r and s as in the interactive case, but obtains c H (r ) instead of receiving it from the verifier. This is known to be a secure NIZK in the random oracle model against standard (non-quantum) adversaries [40]. Other Building Blocks. This paper requires other common primitives, namely one-way functions, pseudorandom generators, and commitments. We use the canonical hash-based commitment and require commitments to be hiding and binding. Definitions are given in the full version of this paper, where we also recall the definition of signature schemes, and existential unforgeability under chosen message attacks (EUF-CMA), which is the standard security notion for signature schemes. 3 ZKBOO AND ZKB++ ZKBoo is a proof system for zero-knowledge proofs on arbitrary circuits described in [45]. We recall the protocol here, and present ZKB++, an improved version of ZKBoo with proofs that are less than half the size. 3.1 ZKBoo While ZKBoo is presented with various possible parameter options, we present only the final version from [45] with the best parameters. Moreover, while ZKBoo presents both interactive and noninteractive protocol versions, we present only the non-interactive version since our main goal is building a signature scheme. Overview. ZKBoo builds on the MPC-in-the-head paradigm of Ishai et al. [57], that we describe only informally here. The multiparty computation protocol (MPC) will implement the relation, and the input is the witness. For example, the MPC could compute y = SHA-256(x) where players each have a share of x and y is public. The idea is to have the prover simulate a multiparty computation protocol in their head, commit to the state and transcripts of all players, then have the verifier corrupt a random subset of the simulated players by seeing their complete state. The verifier then checks that the computation was done correctly from the perspective of the corrupted players, and if so, he has some assurance that the output is correct and the prover knows x. Iterating this for many rounds then gives the verifier high assurance. ZKBoo generalizes the idea of [57] by replacing MPC with socalled circuit decompositions, which do not necessarily need to satisfy the properties of an MPC protocol and therefore lead to more efficient proofs in practice. Fix the number of players to three. In particular, to prove knowledge of a witness for a relation R := {(x,y),ϕ(x) = y}, we begin with a circuit that computes ϕ, and then find a suitable circuit decomposition. This contains a Share function (that splits the input into three shares), three functions Output i {1,2,3} (that take as input all of the input shares and some randomness and produce an output share for each of the parties), and a function Reconstruct (that takes as input the three output shares and reconstructs the circuit s final output). This decomposition must satisfy correctness and 2-privacy which intuitively means that revealing the views of any two players does not leak information about the witness x. The decomposition is used to construct a proof as follows: the prover runs the computation ϕ using the decomposition and commits to the views three views per run. Then, using the FS heuristic, the prover sends the commitments and output shares from each view to the random oracle to compute a challenge the challenge tells the prover which two of the three views to open for each of the t runs. Because of the 2-privacy property, opening two views for each run does not leak information about the witness. The number of runs, t, is chosen to achieve negligible soundness error i.e., intuitively it would be infeasible for the prover to cheat without getting caught in at least one of the runs. The verifier checks that (1) the output of each of the three views reconstructs to y, (2) each of the two open views were computed correctly, and (3) the challenge was computed correctly. We now give a detailed description of the non-interactive ZKBoo protocol. Throughout this paper, when we perform arithmetic on the indices of the players, we omit the implicit mod 3 to simplify the notation. Definition 3.1 ((2,3)-decomposition). Let f ( ) be a function that is computed by an n-gate circuit ϕ such that f (x) = ϕ(x) = y, and let κ be the security parameter. Let k 1,k 2, and k 3 be tapes chosen uniformly at random from {0,1} κ corresponding to players P 1,P 2 and P 3, respectively. Consider the following set of functions, D: (view (0) 1, view(0) 2, view(0) 3 ) Share(x,k 1,k 2,k 3 ) view (+1) i Update(view () i,view () i+1,k i,k i+1 ) y i Output(View i ) y Reconstruct(y 1,y 2,y 3 ) such that Share is a potentially randomized invertible function that takes x as input and outputs the initial view for each player containing the secret share x i of x, i.e. view (0) i = x i. The function Update computes the wire values for the next gate and updates the view accordingly. The function Output i takes as input the final view, View i view (n) i after all gates have been computed and outputs player P i s output share, y i. We require correctness and 2-privacy as informally outlined before. We defer a formal definition to Appendix A.1. The concrete decomposition used by ZKBoo is presented in Appendix A ZKBoo Complete Protocol. Given a (2,3)-decomposition D for a function ϕ, the ZKBoo protocol is a Σ-protocol for languages of the form L := {y x : y = ϕ(x)}. We note that this directly yields a non-interactive zero-knowledge (NIZK) proof system for the same relation using well known results. We recall the details of ZKBoo in Appendix A. Serializing the Views. In the (2,3)-decomposition, the view is updated with the output wire value for each gate. While conceptually a player s view includes the values that they computed locally, when the view is serialized, it is sufficient to include only the wire values of the gates that require non-local computations (i.e., the binary multiplication gates). The verifier can recompute the parts of the view due to local computations, and they do not need to be 1828

5 serialized. Giving the verifier locally computed values does not even save any computation as the verifier will still need to recompute the values in order to check them. In ZKBoo, the serialized view includes: (1) the input share, (2) output wire values for binary multiplication gates, and (3) the output share. The size of a view depends on the circuit as well as the ring that it is computed over. Let ϕ : (Z 2 l ) m (Z 2 l ) n be the circuit being computed over Z 2 l such that there arem input wires, n output wires, and each wire can be expressed with l bits. Moreover, assume that the circuit has b binary-multiplication gates. The size of a view in bits is thus given by: View i = l(m + n + b). ZKBoo Proof Size. Using the above notation, we can now calculate the size of ZKBoo proofs. Let κ be the (classical) security-parameter. The random tapes will be of size κ as mentioned above. Furthermore, let c be the size of the commitments c i (in bits) for a commitment scheme secure at the given security level. In ZKBoo, hash-based commitments were used and instantiated with SHA-256, and thus c = 256. In ZKBoo, the openings D of the commitments contain the value being committed to as well as the randomness used for the commitments. Let s denote the size of the randomness in bits used for each commitment. The size of the output share y i is the same as the output size of the circuit, (l n). Let t denote the number of parallel repetitions that we must run, and from ZKBoo we know that to achieve soundness error of 2 κ, we must set t = κ(log 2 3 1) 1. The total proof size is given by p = t [3 ( y i + c i ) + 2 ( View i + k i + s)] = t [3 (ln + c) + 2 (l (m + n + b) + κ + s)] = t [3c + 2κ + 2s + l (5n + 2m + 2b)] = κ(log 2 3 1) 1 [3c + 2κ + 2s + l (5n + 2m + 2b)] 3.2 ZKB++ We now present ZKB++, an improved version of ZKBoo with NIZK proofs that are less than half the size of ZKBoo proofs. Moreover, our benchmarks show that this size reduction comes at no extra computational cost. 6 We present the ZKB++ optimizations in an incremental way over the original ZKBoo protocol. O1: The Share Function. We make the Share function sample the shares pseudorandomly as: (x 1,x 2,x 3 ) Share(x,k 1,k 2,k 3 ) x 1 = R 1 (0 x 1 ) x 2 = R 2 (0 x 1 ) x 3 = x x 1 x 2 where R i is a pseudorandom generator seeded with k i, and by R i (0 x 1 ) we denote the first x bits output by R i. We note that sampling in this manner preserves the 2-privacy of the decomposition. In particular, given only two of {(k 1,x 1 ), (k 2,x 2 ), (k 3,x 3 )}, x remains uniformly distributed over the choice of the third unopened (k i,x i ). 6 Our analysis of the original ZKBoo source code uncovered some errors which were corrected in the new implementation. We specify the Share function in this manner as it will lead to more compact proofs. For each round, the prover is required to open" two views. In order to verify the proof, the verifier must be given both the random tape and the input share for each opened view. If these values are generated independently of one another, then the prover will have to explicitly include both of them in the proof. However, with our sampling method, in View 1 and View 2, the prover only needs to include k i, as x i can be deterministically computed by the verifier. The exact savings depend on which views the prover must open, and thus depend on the challenge. The expected reduction in proof size resulting from using the ZKB++ sampling technique instead of the technique used in ZKBoo is (4t x )/3 bits. O2: Not Including Input Shares. Since the input shares are now generated pseudorandomly using the seed k i, we do not need to include them in the view when e = 1. However, if e = 2 or e = 3, we still need to send one input share for the third view for which the input share cannot be derived from the seed. Since the challenge is generated uniformly at random from {1,2,3}, the expected number of input shares that we ll need to include for a single iteration is 2/3. O3: Not Including Commitments. In ZKBoo proofs, the commitments of all three views are sent to the verifier. This is unnecessary as for the two views that are opened, the verifier can recompute the commitment. Only for the third view that the verifier is not given the commitment needs to be explicitly sent. We stress that there is no lost security here (in some sense we use e as a commitment to the commitments ) as even when the prover sends the commitments, the verifier must check that the prover has sent the correct commitments by hashing the commitments to recompute the challenge. Here too, the verifier checks that the commitments that it computed are the same ones that were used by the prover by hashing them as part of the input to recompute the challenge. There is also no extra computational cost in this approach whereas the verifier now must recompute the commitments, in the original ZKBoo protocol, the verifier needed to verify the commitments in step 2 ( see the full version of the paper for the full ZKBoo protocol ). For the hash-based commitment scheme used in ZKBoo, the function to verify the commitment first recomputes the commitment and thus there is no extra computation. O4: No Additional Randomness for Commitments. Since the first input to the commitment is the seed value k i for the random tape, the protocol input to the commitment doubles as a randomization value, ensuring that commitments are hiding. Further, each view included in the commitment must be well randomized for the security of the MPC protocol. In the random oracle model the resulting commitments are hiding (the RO model is needed here since k i is used both as seed for the PRG and as randomness for the commitment. Since one already needs the RO model to make the proofs non-interactive, there is no extra assumption here). O5: Not Including the Output Shares. In ZKBoo proofs, as part of a, the output shares y i are included in the proof. Moreover, for the two views that are opened, those output shares are included a second time. 1829

6 Session I1: Post-Quantum First, we do not need to send two of the output shares twice. However, we actually do not need to send any output shares at all as they can be deterministically computed from the rest of the proof as follows: For the two views that are given as part of the proof, the output share can be recomputed from the remaining parts of the view. Essentially, the output share is ust the value on the output wires. Given the random tapes and the communicated bits from the binary multiplication gates, all wires for both views can be recomputed. For the third view, recall that the Reconstruct function simply XORs the three output shares to obtain y. But the verifier is given y, and can thus instead recompute the third output share. In particular, given yi, yi+1 and y, the verifier can compute: yi+2 = y + yi + yi+1. Computational Trade-Off. While we would expect some computational cost from recomputing rather than sending the output shares, our benchmarks show that there is no additional computational cost incurred by this modification, perhaps because it is a small part of the overall verification. For the challenge view, Viewe, the verifier anyway needs to recompute all of the wire values in order to do the verification, so there is no added cost. For the second view, Viewe+1, the verifier must recompute the wire values as well since the verifier will need to compute the values which must be stored as output of the (2, 3)-decomposition, so there is effectively no cost. For the third view, the extra cost of recomputing the output share is ust two additions in the ring, which is exactly the cost of a single call to Reconstruct. However, in step 2 of the verification in ZKBoo, the verifier has to call Reconstruct in order to verify that the three output shares given are correct (see the full version of the paper for the full ZKBoo protocol ). But in our optimization, the verifier no longer needs to perform this check as the derivation of the third share guarantees that it will reconstruct correctly. Thus, the verifier is adding one Reconstruct but saving one, and thus no cost is incurred. We note that the outputs will be checked as the yi s are hashed with H to determine the challenge. The verifier recomputes the challenge and if the yi values used by the verifier do not match those used by the prover, the challenge will be different (by the collision resistance property of H ), and the proof will fail. correctness. Indeed, for this view, the prover only needs to send the input wire value and nothing else Putting it All Together: ZKB++. This series of optimizations results in our new protocol ZKB++ which is presented in Scheme 1. Notice that in ZKB++, the prover explicitly sends the challenge e to the verifier. In the original ZKBoo protocol, the verifier is explicitly given all of the inputs to the challenge random oracle, so it can compute the challenge right away, and then check the proofs. However, in our protocol, the verifier is no longer explicitly given these inputs. Thus our verifier must first recompute all implicitly given values. To be able to compute those values, the challenge e is required which is why we explicitly include e in the proof. There are 3 possible challenges for each iteration, so the cost of sending e for a t iteration proof is t log2 (3). ZKB++ Proof Size. The expected proof size is p = t[ c i + 2 ki + 2/3 x i + b w i + ei ] = t[c + 2κ + 2/3ℓm + bℓ + log2 (3)] = t[c + 2κ + log2 (3) + ℓ (2/3 m + b)] = κ (log2 3 1) 1 [c + 2κ + log2 (3) + ℓ (2/3 m + b)] The ZKB++ improvements reduce the proof size compared to ZKBoo by a factor of 2; independent of the concrete circuit. As an example, we can consider the concrete case of proving knowledge of a SHA-256 pre-image. For this example, we set ℓ = 1 (for Boolean circuits), c = 256 (we use SHA-256 as a commitment scheme), and s = κ (the randomness for the commitment in ZKBoo that we eliminated in ZKB++). For the circuit, we use the SHA-256 boolean circuit from [23], for which m = 512, n = 256, and b = Given these parameters, if we set κ = 128, then the ZKB++ proof size is 618 kilobytes, which is only 48% of ZKBoo proof size (1287 kilobytes). At the 80-bit security level, the ZKB++ proof size is 385 kilobytes, and at the 40-bit security level, the proof size is 193 kilobytes. For all these figures, we used 256-bit commitments, and thus in practice they may be slightly reduced by using a weaker commitment scheme. ZKB++ Security. From our argumentation above we conclude that the security of ZKBoo directly implies security of ZKB++ in the (Q)ROM. O6: Not Including Viewe. In step 2 of the proof, the verifier recomputes every wire in Viewe and checks as he goes that the received values are correct. However we note that this is not necessary. The verifier can recompute Viewe given ust the random tapes ke,ke+1 and the wire values of Viewe+1. But the verifier does not need to explicitly check that each wire value in Viewe is computed correctly. Instead, the verifier will recompute the view, and check the commitments using the recomputed view. By the binding property of the commitment scheme, the commitments will only verify if the verifier has correctly recomputed every value stored in the view. Notice that this modification reduces the computational time as the verifier does not need to perform part of step 2, i.e., there is no need to check every wire as checking the commitment will check these wires for us. But more crucially, this modification reduces the proof size significantly. There is no need to send the AND wire values for Viewe as we can recompute them and check their 4 THE FISH SIGNATURE SCHEME The FS transform is an elegant way to obtain EUF-CMA secure signature schemes. The basic idea is similar to constructing NIZK proofs from Σ-protocols, but the challenge c is generated by hashing the prover s first message r and the message m to be signed, i.e., c H (r,m). In the following we will index the non-interactive PPT algorithms (ProveH, VerifyH ) by the hash function H, which we model as a random oracle. Let us consider a language L R with associated witness relation R of pre-images of a one-way function fk : Dκ Rκ, sampled uniformly at random from a family of oneway functions { fk }k Kκ, indexed by key k and security parameter κ: ((y,k ),x ) R y = fk (x ). Henceforth, we may use { fk } for brevity. The function family { fk } could be any one-way function family, but since we found that 1830

7 For public ϕ and y L ϕ, the prover has x such that y = ϕ(x). The prover and verifier use the hash functions G( ) and H ( ) and H ( ) which will be modeled as random oracles (H will be used to commit to the views). The integer t is the number of parallel iterations. p Prove(x): 1. For each iteration r i,i [1,t]: Sample random tapes k 1 output share y. For each player P compute (x 1,x 2,x 3 View y ) Share(x,k 1,k 2,k 2,k 3 and simulate the MPC protocol to get an output view View and,k 3 ) = (G(k 1 ),G(k 2,k Update(Update( Update(x,x +1 Output(View ). ),x G(k 1 ) G(k 2 )),,k +1 )...)...)...), Commit [C,D ] [H (k,x,view ),k View ], and let a = (y 1,y 2,y 3,C 1,C 2,C 3 ). 2. Compute the challenge: e H (a (1),...,a (t ) ). Interpret the challenge such that for i [1,t], e {1,2,3} 3. For each iteration r i, i [1,t]: let b = (y,c ) and set e (i ) +2 e (i ) +2 (View z 2 (View 3 (View 1 4. Output p [e, (b (1),z (1) ), (b (2),z (2) ),, (b (t ),z (t ) )]. b Verify(y,p):,k 1,k 2,k 3,k 2 ) if e = 1,,k 3,x 3 ) if e = 2,,k 1,x 3 ) if e = For each iteration r i,i [1,t]: Run the MPC protocol to reconstruct the views, input and output shares that were not explicitly given as part of the proof p. In particular: G(k x 1 ) if e = 1, G(k G(k e (i ) 2 ) if e = 2, x 2 ) if e = 1, x 3 given as part of z if e e (i ) +1 x 3 given as part of z if e = 2, = 3. G(k 1 ) if e = 3. Obtain View e (i ) +1 from z and compute View e Update(... Update(x e,x e+1,k e,k e+1 )...), y Output(View e (i ) e (i ) ), y e (i ) +1 Output(View ), e (i ) y +1 e (i ) +2 y y y e (i ) e (i ) +1 Compute the commitments for views View and View e (i ) e. For {e,e + 1}: (i ) [C,D ] [H (k ) and note that y,x,view ),k View ] and C e (i ) +2 is a part of z. Let a = (y 1,y 2,y 3,C 1,C 2,C 3 e (i ) Compute the challenge: e H (a (1),...,a (t ) ). If, e = e, output Accept, otherwise output Reect. Scheme 1: The ZKB++ proof system, made non-interactive using the Fiat-Shamir transform. function families based on block ciphers gave the most efficient signatures, we tailor our description to this choice of {f k }. Here we have that f k (x) Enc(x,k), where Enc(x,k) denotes the encryption of a single block k {0,1} c κ with respect to key x {0,1} c κ. One can sample a one-way function {f k } with respect to security parameter κ uniformly at random by sampling a uniformly random block k {0,1} c κ. In Appendix C we formally argue that we can use a block cipher (viewed as a PRF) in this way to instantiate an OWF. In the classical setting we set c = 1, whereas we set c = 2 in the post-quantum setting to account for the generic speedup imposed by Grover s algorithm [52]. The rationale for using a random instead of a fixed block k when creating the signature keypair is to improve security against multi-user key recovery attacks and generic time-memory trade-off attacks like [54]. To reduce the size of the public key, one could choose a smaller value that is unique per user, or use a fixed value (with a potential decrease in security). Since public keys in our schemes are small (at most 64 bytes), our design uses a full random block. When using ZKBoo to prove knowledge of such a pre-image, we know [44] that this Σ-protocol provides 3-special soundness. We apply the FS transform to this Σ-protocol to obtain an EUF-CMA secure signature scheme. In the so-obtained signature scheme the public verification key pk contains the image y and the value k determining f k. The secret signing key sk is a random value x from D κ. The corresponding signature scheme, dubbed Fish, is illustrated in Scheme 2. If we view ZKBoo as a canonical identification scheme that is secure against passive adversaries one ust needs to keep in mind that most definitions are tailored to 2-special soundness, and the 3-special soundness of ZKBoo requires an additional rewind. In particular, an adapted version of the proof of [61, Theorem 8.2] which 1831

8 Gen(1 κ ) : Choose k R K κ, x R D κ, compute y f k (x), set pk (y,k) and sk (pk,x) and return (sk,pk). Sign(sk,m) : Parse sk as (pk,x), compute p = (r,s) Prove H ((y,k),x) and return σ p, where internally the challenge is computed as c H (r,m). Verify(pk,m,σ ) : Parse pk as (y,k), and σ as p = (r,s). Return 1 if the following holds, and 0 otherwise: Verify H ((y,k),p) = 1, where internally the challenge is computed as c H (r,m). Scheme 2: Generic description the Fish and Picnic signature schemes. In both schemes Prove is implemented with ZKB++, in Fish it is made non-interactive with the FS transform, while in Picnic, Unruh s transform is used. considers this additional rewind attests the security of Scheme 2. The security reduction, however, is a non-tight one, like most signature schemes constructed from Σ-protocols. 7 We obtain the following: Corollary 4.1. Scheme 2 instantiated with ZKB++ and a secure one-way function yields an EUF-CMA secure signature scheme in the ROM. 5 THE PICNIC SIGNATURE SCHEME The Picnic signature scheme is the same as Fish, except for the transform used to make ZKB++ noninteractive. Unruh [83] presents an alternative to the FS transform that is provably secure in the QROM. Indeed, Unruh even explicitly presents a construction for a signature scheme and proves its security given a secure a Σ protocol. Unruh s construction requires a Σ protocol and a hard instance generator, but he does not give an instantiation. We use his approach to argue that with a few modifications, our signature scheme is also provably secure in the QROM. One interesting aspect is that, while on first observation Unruh s transform seems much more expensive than the standard FS transform, we show how to make use of the structure of ZKB++ to reduce the cost significantly. Unruh s Transform: Overview. At a high level, Unruh s transform works as follows: Given a Σ-protocol with challenge space C, an integer t, a statement x, and a random permutation G, the prover will (1) Run the first phase of the Σ-protocol t times to produce r 1,...,r t. (2) For each i {1,...,t}, and for each C, compute the response s i for r i and challenge. Compute д i = G(s i ). (3) Compute H (x,r 1,...,r t,д 11,...,д t C ) to obtain a set of indices J 1,..., J t. (4) Output π = (r 1,...,r t,s 1J1,...,s t Jt,д 11,...,д t C ). Similarly, the verifier will verify the hash, verify that the given s i Ji values match the corresponding д i Ji values, and that the s i Ji values are valid responses w.r.t. the r i values. Informally speaking, in Unruh s security analysis, zero knowledge follows from HVZK of the underlying Σ-protocol: the simulator ust generates t transcripts and then programs the random oracle to get the appropriate challenges. The proof of knowledge property is more complex, but the argument is that any adversary who has non-trivial probability of producing an accepting proof 7 There are numerous works on signatures from (three move) identification schemes [1, 2, 12, 32, 62, 73, 77]. Unfortunately existing proof techniques do not give tight security reductions. will also have to output some д i for J i which is a correct response for a different challenge - then the extractor can invert G and get the second response, which by special soundness allows it to produce a witness. To instantiate the function G in the protocol, Unruh shows that one does not need a random oracle that is actually a permutation. Instead, as long as the domain and co-domain of G have the same length, it can be used, since it is indistinguishable from a random permutation. Applying the Unruh transform to ZKB++: The Direct Approach. We can apply Unruh to ZKB++ in a relatively straightforward manner by modifying our protocol. Although ZKB++ has 3-special soundness, whereas Unruh s transform is only proven for Σ-protocols with 2-special soundness, the proof is easily modified to 3-special soundness. Since ZKB++ has 3-special soundness, we would need at least three responses for each iteration. Moreover, since there only are three possible challenges in ZKB++, we would run Unruh s transform with C = {1,2,3}, i.e., every possible challenge and response. We would then proceed as follows: Let G : {0,1} s i {0,1} s i be a hash function modeled as a random oracle. 8 Non-interactive ZKB++ proofs would then proceed as follows: (1) Run the first ZKB++ phase t times to produce r 1,...,r t. (2) For each i {1,...,t}, and for each 1,2,3, compute the response s i for r i and challenge. Compute д i = G(s i ). (3) Compute H (x,r 1,...,r t,д 11,...,д t3 ) to obtain a set of indices J 1,..., J t. (4) Output π = (r 1,...,r t,s 1J1,...,s t Jt,д 11,...,д t3 ). While this works, it comes as a significant overhead in the size of the proof. That is, we have to additionally include д 11,...,д t3. Each д i is a permutation of an output share and there are 3t such values, so in particular the extra overhead would yield a proof size of t [c + 2κ + log 2 (3) + l (2/3 m + b)]+ 3t [2κ + l (2/3 m + b)] = t [c + 8κ + loд 2 (3) + l (8/3m + 4b)]. Since for most functions, the size of the proof is dominated by t lb, this proof is roughly four times as large as in the FS version. To this end, we again introduce some optimizations. 8 Actually, the size of the response changes depending on what the challenge is. If the challenge is 0, the response is slightly smaller as it does not need to include the extra input share. So more precisely, this is actually two hash functions, G 0 used for the 0-challenge response and G 1,2 used for the other two. 1832

9 O1: Making Use of Overlapping Responses. We can make use of the structure of the ZKB++ proofs to achieve a significant reduction in the proof size. Although we refer to three separate challenges, in the case of the ZKB++ protocol, there is a large overlap between the contents of the responses corresponding to these challenges. In particular, there are only three distinct views in the ZKB++ protocol, two of which are opened for a given challenge. Instead of computing a permutation of each response, s i, we can compute a permutation of each view, v i. For each i {1,...,t}, and for each {1,2,3}, the prover computes д i = G(v i ). The verifier checks the permuted value for each of the two views in the response. In particular, for challenge i {1,2,3}, the verifier will need to check that д i = G(v i ) and д i (+1) = G(v i (+1) ). O2: Omit Re-Computable Values. Moreover, since G is a public function, we do not need to include G(v i ) in the transcript if we have included v i in the response. Thus for the two views (corresponding to a single challenge) that the prover sends as part of the proof, we do not need to include the permutations of those views. We only need to include G(v i (+2) ), where v i (+2) is the view that the prover does not open for the given challenge. Putting it Together: New Proof Size. Combining these two modifications yields a maor reduction in proof size. For each of the t iterations of ZKB++, we include ust a single extra G(v) than we would in the FS transform. As G is a permutation, the per-iteration overhead of ZKB++/Unruh over ZKB++/FS is the size of a single view. This overhead is less that one-third of the overhead that would be incurred from the naive application of Unruh as described before. In particular, the expected proof size of our optimized version is then t [c + 2κ + log 2 (3) + l (2/3 m + b)]+ t [κ + l (1/3 m + b)] = t [c + 3κ + loд 2 (3) + l (m + 2b)]. The overhead depends on the circuit. For LowMC, we found the overhead ranges from 1.6 to 2 compared to the equivalent ZKB++/FS proof. Security of the Modified Unruh Transform. For zero knowledge, we can take the same approach as in Unruh [84]: to simulate the proof we choose the set of challenges J 1,..., J t, run the (2,3)- decomposition simulator to obtain views for each pair of dishonest parties J i, J i+1, honestly generate д i Ji and д i Ji+1 and the commitments to those views, and choose д Ji+2 and the corresponding commitment at random. Then we program the random oracle to output J 1,..., J t on the resulting tuple. The analysis follows exactly as in [84]. For the soundness argument, our protocol has two main differences from Unruh s general version: (1) the underlying protocol we use only has 3-special soundness, rather than the normal 2-special soundness, and (2) we have one commitment for each view, and one G(v) for each view, rather than having a separate G(view i,view i+1 ) for each i. As mentioned above, the core of Unruh s argument [84, Lemma 17], says that the probability that the adversary can find a proof such that the extractor cannot extract but the proof still verifies is negligible. For our case, the analysis is as follows: For a given tuple of commitments r 1... r t, and G-values д 11,д t C that is queried to the random oracle either one of the following is true: (1) There is some i for which (G 1 (д i1 ), G 1 (д i2 )), (G 1 (д i2 ), G 1 (д i3 )), (G 1 (д i3 ), G 1 (д i1 )), are valid responses for challenges 1,2,3 respectively 9, or (2) For all i at least one of these pairs is not a valid response. In particular this means that if this is the challenge produced by the hash function, A will not be able to produce an accepting response. From that, we can argue that if the extractor cannot extract from a given tuple, then the probability (over the choice of a RO) that there exists an accepting response for A to output is at most (2/3) t. Then, we can rely on [84, Lemma 7], which tells us that given q H queries, the probability that A produces a tuple from which we cannot extract but A can produce an accepting response is at most 2(q H + 1)(2/3) t. The rest of our argument can proceed exactly as in Unruh s proof and we obtain the following: Corollary 5.1. Scheme 2 instantiated with ZKB++, a secure permutation and one-way function yields an EUF-CMA secure signature scheme in the QROM. The full proof is given in Appendix D. The security reduction in our proof is non-tight, the gap is proportional to the number of RO queries. 6 SELECTING AN UNDERLYING PRIMITIVE We require one or more symmetric primitives suitable to instantiate a one-way function. We now first investigate how choosing a primitive with certain properties impacts the instantiations of our schemes. From this, we derive concrete requirements, and present our choice, LowMC. 6.1 Survey of Suitable Primitives The signature size depends on constants that are close to the security expectation (cf. Section 7 for our choices). The only exceptions are the number of binary multiplication gates, and the size of the rings, which all depend on the choice of the primitive. Hence we survey existing designs that can serve as a one-way function subsequently. Standardized General-Purpose Primitives. The smallest known Boolean circuit of AES-128 needs 5440 AND gates, AES-192 needs 6528 AND gates, and AES-256 needs 7616 AND gates [20]. An AES circuit in F 2 4 might be more efficient in our setting, as in this case the number of multiplications is lower than 1000 [25]. This results in an impact on the signature size that is equivalent to 4000 AND gates. Even though collision resistance is often not required, hash functions like SHA-256 are a popular choice for proof-of-concept implementations. The number of AND gates of a single call to the SHA-256 compression function is about and a single call to the permutation underlying SHA-3 is Lightweight Ciphers. Most early designs in this domain focused on small area when implemented in hardware where an XOR gate is by a small factor larger than an AND or NAND gate. Notable designs with a low number of AND gates at the 128-bit security 9 In fact G is not exactly a permutation, but we ignore that here. We can make this formal exactly as in Unruh s proof, by considering the set of preimages. 1833