Succinct Proofs for Hidden Order Groups

Wesolowski in [2], proposes a proof of knowledge of exponent scheme, where a Prover is trying to convince a Verifier that they know a number x such that, with a known base u, u^x = w holds.

Let’s take an example, with base 2 (u=2), and w=16, it would be x=4. How do we do that? We transmit x to the Verifier, they have to perform 2⁴, and check the result against w. If it matches, they’re convinced. The two steps that seem obvious here are:

the Verifier has to perform u^x: This is a costly operation for large numbers transmitting x to the Verifier: x might be large, and thus the bandwidth required to transmit it may be non-trivial.

Let’s see what protocols are being proposed to tackle this challenge. These protocols are all interactive, meaning the Verifier and the Prover send each other “challenges” that are used in subsequent steps of the protocol, to make it secure.

Proof of Exponentiation (PoE, section 3.1)

First, let’s see how we can convince the Verifier, without them actually having to run the whole exponentiation.

Proof of Exponentiation (note: current revision of the paper has a typo, and sets Q=g^q instead of u^q in page 8.

The protocol is useful, only if the Verifier is able to compute the residue r faster than computing u^x. It solves the exponentiation issue, but still requires that the prover transmits a potentially large x to the verifier, or that x is publicly known.

Proof of Knowledge of Discrete Log (PoKE, section 3.3)

Instead of transmitting x, we can instead transmit r. The proof becomes (Q,r) and the Verifier must additionally check that r is less than l (PoKE* protocol). This is insecure when the adversary can freely choose the base u!

The verifier got fooled by the Prover that they know z: u^z=w, without knowing z!

The detail that breaks the protocol here, is that the Prover picks the base u=g^x, so that x is co-prime with l.

We can be sure that the above protocol works for a base g which is fixed and encoded in the Common Reference String (CRS) — in simpler terms, all parties agree on the base g beforehand and it cannot be chosen arbitrarily by an adversary.

The protocol can be fixed by:

Proving knowledge of the discrete logarithm x of z = g^x, for a fixed g Prove that the same x is also the discrete logarithm of w base u.

So the final protocol (PoKE) is:

Proof is now 2 group elements, Q and Q’. Can we do better?

Reducing the proof to one group element can be done by adding an additional interactive step:

The verifier needs to send an additional challenge \alpha so that the prover cannot create fake proofs

Why does the challenge have to be a prime number?

The challenge l used in PoE, PoKE, PoKE2 (and their non-interactive variants), must be a prime number which is either provided as a challenge from the Verifier, or is produced by the prover through a collision resistant hash function that maps to a prime number domain (more on this in the next section). Why is that?

Huge thanks to Benedikt Bunz for taking the time to explain this attack to me.

In fact, the challenge l does not have to be a prime number, but it must have a large prime factor that is hard to predict.

Let’s attack the PoE protocol, when l has small prime factors (we also call these numbers B-smooth numbers):

A 5-smooth challenge is weak and enables an attacker to fool a Verifier about knowledge of a discrete logarithm

The attacker successfully fooled the Verifier into believing they know the discrete logarithm of y base g, when they only knew the discrete logarithm of y base w.

The above attack would not work if the challenge had a large prime factor which the attacker wasn’t able to predict.

To avoid this attack, we just set the challenge to be a large prime number the attacker cannot predict in advance. For RSA Accumulators as we’ll see later, the challenge must be larger than any of the accumulated primes (otherwise the above precomputation attack becomes trivial).