New Techniques for Structural Batch Verification in Bilinear Groups with Applications to Groth-Sahai Proofs

Abstract

Bilinear groups form the algebraic setting for a multitude of important cryptographic protocols including anonymous credentials, e-cash, e-voting, e-coupon, and loyalty systems. It is typical of such crypto protocols that participating parties need to repeatedly verify that certain equations over bilinear groups are satisfied, e.g., to check that computed signatures are valid, commitments can be opened, or non-interactive zero-knowledge proofs verify correctly. Depending on the form and number of equations this part can quickly become a performance bottleneck due to the costly evaluation of the bilinear map.To ease this burden on the verifier, batch verification techniques have been proposed that allow to combine and check multiple equations probabilistically using less operations than checking each equation individually. In this work, we revisit the batch verification problem and existing standard techniques. We introduce a new technique which, in contrast to previous work, enables us to fully exploit the structure of certain systems of equations. Equations of the appropriate form naturally appear in many protocols, e.g., due to the use of Groth-Sahai proofs.The beauty of our technique is that the underlying idea is pretty simple: we observe that many systems of equations can alternatively be viewed as a single equation of products of polynomials for which probabilistic polynomial identity testing following Schwartz-Zippel can be applied. Comparisons show that our approach can lead to significant improvements in terms of the number of pairing evaluations. Indeed, for the BeleniosRF voting system presented at CCS 2016, we can reduce the number of pairings (required for ballot verification) from 4k + 140, as originally reported by Chaidos et al. [19], to k + 7. As our implementation and benchmarks demonstrate, this may reduce the verification runtime to only 5% to 13% of the original runtime. CCS CONCEPTS• Security and privacy → Mathematical foundations of cryptography; Public key (asymmetric) techniques; • Theory of computation → Cryptographic protocols; KEYWORDS Batch verification; bilinear maps; Groth-Sahai proofs; structurepreserving cryptography; Belenios; P-signatures. = [t 1 ] T e ([x 1 ] 1 , [y 2 ] 2 ) ? = [t 2 ] T e ([x 2 ] 1 , [y 1 ] 2 ) ? = [t 3 ] T e ([x 2 ] 1 , [y 2 ] 2 ) ? = [t 4 ] T1 This is inspired by (but even simpler than) the polynomial framework of [36].2

Shorter Pairing-Based Arguments Under Standard Assumptions

“…In the most efficient instantiation, the proof size is (3d + 2)|G 1 | + (d + 2)|G 2 | and naive verification requires to compute 3d pairings for the quadratic relations and 2(n 0 + 3d + 4) for the linear part, n d exponentiations in G 1 for the output. Using the "bilinear batching" techniques of Herold et al [21] the number of pairings can be reduced to n 0 + 3d + 4 for the linear part. Since the input is known in Z p , n 0 pairings in this part can be replaced by n 0 exponentiations in G T .…”

“…First, one can observe that in fact since the input is known in Z p , the n 0 pairings can be replaced by exponentiations in G T . Second, using the "bilinear batching" techniques of [21] this is reduced to 7d + 3d + 4. Finally, using traditional batching techniques [6], the cost of verifying all the to GS equations can be reduced to d + 6, resulting in a total cost of 4d + 10 pairings (and O(n 0 + d) exponentiations).…”

(R)CCA Secure Updatable Encryption with Integrity Protection

“…For decryption, we need to check the equations. Using the probabilistic verification of [Her+17], we can reduce the number of pairings needed to compute to rougly 22 for NYUE and 29 for NYUE. We ignore the additional overhead, which is one (small) exponentiation per commitment and several per proof.…”

P6V2G: a privacy-preserving V2G scheme for two-way payments and reputation

“…For the verification of NIZK proofs, we assume batch verification techniques from (Herold et al 2017) to significantly speed up the verification process. Also note, that the number of operations needed for verification was generously estimated.…”