Zero-Knowledge Proofs must satisfy three requirements and they are presented here as described in “Handbook of Applied Cryptography” [MvOV01]:
• Soundness. There exists an expected polynomial-time algorithm P with the following property: if a dishonest prover can with non-negligible prob- ability successfully execute the protocol with the honest verifier, then P can be used to extract the prover’s knowledge, which allows for successful subsequent protocol executions.
• Completeness. Given an honest prover and an honest verifier, the proto- col succeeds with overwhelming probability. The definition of overwhelm- ing depends on the application, but generally implies that the probability of failure is not of practical significance.
• Proof of Zero-Knowledge. There exists an expected polynomial-time algorithm, which can produce, upon input of the assertion to be proven but without interacting with the real prover, transcripts indistinguishable from those resulting from interaction with the real prover.
2.8.1 Interactive Zero-Knowledge Proofs (IZKP)
This variation of the ZKP requires the prover, P, to interact with the verifier, V, in order to prove knowledge of a secret without disclosure of any information about it. To minimise the probability of successful cheating, the protocol can be executed many times, in favour of the verifier, until he/she is convinced of the proof. Usually, it is a three-move protocol and its general structure is illustrated below:
1. P → V: witness. The prover chooses a secret value from a pre-defined set of values as its commitment and from this computes the associated public witness. Thereafter, he sends the witness to the verifier; this is the commitment to the protocol.
2. P ← V: challenge. The verifier challenges the prover by sending a challenge, which could be the outcome of a fair coin toss.
3. P → V: response. Taking into account the secret, the witness and the challenge, the prover calculates and sends a response to the verifier, who checks its correctness.
In this subsection, the Fiat-Shamir identification protocol [FS86] is introduced as well as the Chaum-Pedersen protocol [CP92], which is used to prove equality of discrete logarithms. The work by Guillou and Quisquater [GQ88] is an extension of the Fiat-Shamir protocol and is used to prove knowledge of modulus N without revealing its factorisation. Shnorr’s identification algorithm [Sch91], is used to
prove knowledge of a secret key without revealing it. Due to their efficiency, speed and simplicity, these schemes are suitable for applications where the prover has limited memory and computational power. Additionally, in the next subsection how the Fiat-Shamir heuristic [FS86] can be used to transform an IZKP into a non-IZKP is illustrated. Applying the Fiat-Shamir heuristic, the aforementioned protocols can be transformed into a non-IZKP.
Fiat-Shamir Identification Protocol
The Fiat-Shamir protocol [FS86], is a combination of IZKP and identity-based schemes [Sha84] and is used to enable a user to prove his identity to other users without sharing any information about the used public keys. The scheme is based on the RSA cryptosystem, where the public key, N, is the product of two large prime numbers p and q. As is described in [FS86], the scheme assumes the existence of a trusted centre, which issues smart cards to physically identified users. The issuing centre proceeds as follows:
1. computes vi = H(I, j) for small values of i, where I is a string containing
all the information about the card holder and j = 1, . . . , k;
2. Let N = pq, where p and q are two large primes. Compute the correspond- ing k smallest square roots sj of vj−1 mod N , for j = 1, . . . , k. It should
be noted here that the credit card centre knows the factorisation of N and therefore it can calculate these square roots efficiently. The sj, . . . , sk are
called quadratic residues modulo N . For a formal description the reader is referred to [KL08].
3. it issues a card which contains I and all the first k sj values.
When a smart card is used in a verification device, such as a card reader, it must prove that it knows all the k th si values, i.e. s1, . . . , sk, without, of course,
revealing them. The above notation is followed, so the smart card is the prover, P, and the card reader the verifier, V. The IZKP executes the following steps:
1. P → V: I. The prover (smart card) sends I to the verifier (card reader). 2. V: generates vj = H(I, j) for i = j, . . . , k.
3. P → V: witness. P chooses ri and sends xi = ri2 mod N toV.
4. P ← V: challenge. V chooses a vector of binary values ei1, . . . , eikand sends
these challenges to P.
5. P → V: response. P calculates yi = ri Q eij=1
si mod N and sends this as
2.8. Zero-Knowledge Proofs 35
6. V: check. V checks whether xi = yi2
Q
eij=1
vi mod N holds.
The execution is iterative and the steps 3 to 6 can be repeated a number of times until V is satisfied with the outcome of the protocol. Its security relies on the difficulty of calculating modular square roots of a modulus N, given the fact that its factorisation is unknown.
Chaum-Pedersen Protocol
The Chaum-Pedersen protocol [CP92] is frequently used to prove equality of discrete logarithms. The same notation is used here as in Subsection 2.3.2, where the public key is the tuple hy, g, pi and the secret key is x = loggy. In this
situation, the prover, P, should prove to the verifier, V, that for a pair (m, n), the loggy = logmn = x holds. The proof works as follows:
1. P → V: witness. P chooses r from Zq, computes the pair (a, b) = (gr, mr)
and sends it toV.
2. P ← V: challenge. V chooses a random challenge c from Zq and sends it
back toP.
3. P → V: response. P computes s = r +xc mod q and sends it as a response toV.
4. V: check. V accepts the proof only if both gs= aycand ms= bnc hold.
The Chaum-Pedersen protocol can be used to prove correctness of the re-encryption and decryption operations of the El Gamal crytposystem, as presented in Sub- section 2.3.2. Recall an El Gamal ciphertext c = hα, βi = hgr, yrmi and its
re-encryption c0 = hαgr0, βyr0i = hgr+r0
, yr+r0mi, under a new random value r0 ∈ Zq. To prove that c0 is indeed a re-encryption of c, without revealing the secret
random value r0, the prover should prove to the verifier knowledge of r0, such that logy(βyr0
/β) = logg(αgr0 /α).
2.8.2 Non-Interactive Zero-Knowledge Proofs (NIZKP)
In contrast to an Interactive Zero-Knowledge Proof (IZKP) protocol, where both the prover and the verifier must be present in order to execute the protocol, a Non-Interactive Zero-Knowledge Proof (NIZKP) protocol, allows the prover to convince the verifier about knowledge of a secret by committing to the protocol only a single message, given the fact that both have access to a random string, i.e. generated by a collision-free “deterministic” hash function. This flavour of ZKP protocols was introduced by Blum, Feldman and Micali [BFM88] in 1988 and the security of the NIZKP relies on the properties of a one-way hash function, where
no one, including the verifier, can forecast its random outcome. In its general form, an NIZKP protocol works as follows:
1. P generates a witness.
2. P generates a challenge by hashing the witness and some other information. 3. P computes the response and sends the transcript of the witness, the chal-
lenge and the response to V.
Having briefly described how an NIZKP protocol works, it is now explained under what modifications the Fiat-Shamir protocol, as it has been presented in the previous section, can be turned into one NIZKP.
Fiat-Shamir Heuristic
The Fiat-Shamir heuristic [FS86], is used to convert an IZKP into a one-message NIZKP protocol by hashing the prover’s first message to select the verifier’s challenge. When describing the interactive Fiat-Shamir protocol, it was seen that the role of the verifier is passive, because the vector of random binary values he sends as challenges has no information and this prevents the prover from cheating. To turn this scheme into an NIZKP protocol,V’s role is replaced by a collision-resistant hash function H(·) and then, as it is described on page 34, the following protocol is obtained:
1. P: witness. P chooses ri at random and computes xi = r2i mod N , for
i = 1, . . . t, where t is the number of the protocol runs.
2. P: challenge. P computes the hash H(m, x1, . . . , xt) and uses the first kt
bits as the eij challenge values, where 1 ≤ i ≤ t, 1 ≤ j ≤ k and kt is
the number of bits P sends to V in order to decrease the number of the communicated bits in step 3 of the protocol on page 34.
3. P → V: response. P computes yi = ri Q eij=1
si mod N , for i = 1, . . . , t and
sends I, m, eij and yi (called transcript) to V.
To verify the validity of the transcript, the verifier, V, works as follows: 1. V computes vj = H(I, j), for j = 1, . . . , k.
2. V computes zi = yi2
Q
eij=1
vi mod N , for i = 1, . . . , t.
3. V: checks. V accepts the proof only if the first kt bits of H(m, z1, . . . , zk)