Zero-Knowledge Arguments for Lattice-Based Accumulators: Logarithmic-Size Ring Signatures and Group Signatures Without Trapdoors

Abstract

International audienceAn accumulator is a function that hashes a set of inputs into a short, constant-size string while preserving the ability to efficiently prove the inclusion of a specific input element in the hashed set. It has proved useful in the design of numerous privacy-enhancing protocols, in order to handle revocation or simply prove set membership. In the lattice setting, currently known instantiations of the primitive are based on Merkle trees, which do not interact well with zero-knowledge proofs. In order to efficiently prove the membership of some element in a zero-knowledge manner, the prover has to demonstrate knowledge of a hash chain without revealing it, which is not known to be efficiently possible under well-studied hardness assumptions. In this paper, we provide an efficient method of proving such statements using involved extensions of Stern's protocol. Under the Small Integer Solution assumption, we provide zero-knowledge arguments showing possession of a hash chain. As an application, we describe new lattice-based group and ring signatures in the random oracle model. In particular, we obtain: (i) The first lattice-based ring signatures with logarithmic size in the cardinality of the ring; (ii) The first lattice-based group signature that does not require any GPV trapdoor and thus allows for a much more efficient choice of parameters

Zero-Knowledge Password Policy Check from Lattices

“…Stern's protocol was originally proposed for code-based cryptography, and adapted to lattices by Kawachi et al [29]. It was subsequently empowered by Ling et al [37] to handle the matrix-vector relations associated with the SIS and inhomogeneous SIS problems and extended to design several lattice-based schemes: group signatures [38,36,34,39], policy-based signatures [12] and group encryption [35]. The basic protocol has 3 moves.…”

“…We thus need a lattice-based sub-protocol for proving set membership. In the lattice-based world, a set membership argument system with logarithmic complexity in the cardinality of the set was proposed in [36], exploiting Stern-like protocols [50] and Merkle hash trees. However, the asymptotic efficiency does not come to the front when the underlying set has small, constant size.…”

“…These are less efficient than those of the first family because each protocol execution admits a constant soundness error, and require repeating protocols ω(log n) times, for a security parameter n, to achieve negligible soundness error. On the upside, Stern-like protocols have perfect completeness and can handle a wide range of lattice-based relations [38,36,12,34,35,39], especially when witnesses have to not only be small or binary, but also certain prescribed arrangement of coordinates. Furthermore, unlike protocols of the first family, the extractor of Stern-like protocols can output witness vectors with the same properties expected of valid witnesses.…”

Logarithmic-Size Ring Signatures with Tight Security from the DDH Assumption

“…So far, the only known solutions with logarithmic signature length [24,28] suffered from loose reductions: the underlying hard problem could only be solved with a probability smaller than the adversary's advantage by a linear factor in the number of hash queries. Our main result is to give the first construction that simultaneously provides tight security -meaning that there is essentially no gap between the adversary's probability of success and the reduction's advantage in solving a hard problem -and logarithmic signature size in the number of ring members.…”

“…The hash-based accumulators of [12,13] would not provide efficient solutions as they would incur proofs of knowledge of hash function pre-images. While the lattice-based construction of [28] relies on hash-based accumulators, its security proof is not tight and its efficiency is not competitive with discrete-logarithm-based techniques. Sander's number-theoretic accumulator [35] is an alternative candidate to instantiate [15] without a setup phase.…”