david wong

Hey! I'm David, cofounder of zkSecurity and the author of the Real-World Cryptography book. I was previously a crypto architect at O(1) Labs (working on the Mina cryptocurrency), before that I was the security lead for Diem (formerly Libra) at Novi (Facebook), and a security consultant for the Cryptography Services of NCC Group. This is my blog about cryptography and security and other related topics that I find interesting.

Schnorr's Signature and non-interactive Protocols posted December 2014

Interactive Protocols

Interactive Protocols are basically a discussion between a Prover and a Verifier where the Prover has some piece of information he wants to prove, without giving out the information.

It is often illustrated with Peggy and Victor and their super tunnel.

peggy

Usualy it takes 3 steps:

  1. Prover sends a fixed value.
  2. Verifier sends a challenge.
  3. Prover answers the challenge.

The Verifier can then verify the answer based on the fixed value. If the answer is correct, the Verifier can assume the Prover knows what he's trying to prove. Sometimes you have to repeat the protocols multiple time to be sure, and not all problems have an Interactive Proof.

Classic examples of such proofs can be found on the Discrete Logarithm problem (we'll talk about that later) and the Hamiltonian Cycle problem.

Interactive Protocols are verified if they are :

  1. Complete: a Prover can successfully answer the challenge if he is honest.
  2. Sound : a dishonest Prover cannot convince the Verifier he knows the secret.

In the real definitions we use probabilities (an honest prover still has a small chance of making a mistake, a dishonest prover still has a small chance of convincing the Verifier).

We also often want a 3rd condition on our Interactive Protocols: we want it to be Zero-knowledge, no information about our secret should be leaked in this interaction.

Here are how you prove each one of them:

  1. Completeness: Can the Prover answer correctly thanks to his secret?
  2. Soundness: From the point of view of the Verifier. If the Prover can correctly answer two different challenges for the same fixed value (however he crafted the answers and the fixed value), does it mean that he must know the secret then?
  3. Zero-Knowledgeness: If you see a transcript of a recorded instance of this interaction, will you learn anything about the secret? (See if you can create fake transcripts)

There are also notions of weak Zero-knowledge, strong Zero-knowledge, dishonnest verifiers, etc...

But let's talk about something else.

Non-interactive Protocols

Since we said that a recorded transcript of a past interaction has no value (if it is zero-knowledge), then we could assume that there is no way of proving something by showing an old transcript, or by showing a transcript with yourself.

Don't fool yourself! Yes we can. We do this by using hash functions that we deem random enough.

The idea is that, by replacing the Verifier by a random oracle, we cannot predict the challenges and we thus cannot craft a fake transcript (we like to use random oracles instead of hashes, to prove some scheme is secure).

a random oracle is an oracle (a theoretical black box) that responds to every unique query with a (truly) random response chosen uniformly from its output domain. If a query is repeated it responds the same way every time that query is submitted.

What is interesting is that this protocol was used in a Signature Scheme.

Interactive Proof of a Discrete Logarithm

The most famous academic example of Interactive Protocol is done using the Discrete Logarithm problem.

we have <g> = G, with g of order q. The Prover wants to show he knows x in g^x = y.

  1. the Prover sends t = g^e
  2. the Verifier sends a challenge c
  3. the Prover sends d = e + cx

The Verifier can then compute y^c * t = g^(e + cx) and see if it equals g^d = g^(e + cx)

A transcript would look like this: (t, c, d)

Non-Interactive Proof of a Discrete Logarithm

Doing this with a non-interactive protocol, it would look like this:

(t, h(t), d) with h a hash function.

Schnorr's Signature

This is what Schnorr's Signature is doing:

  1. t = g^e
  2. c = H(m || t)
  3. d = e - x*c

he would then send (c, d) as the signature, along the message m. Which is basically a hash of the message with a proof that he knows the secret x.

To verify the signature you would use the public key y = g^x to compute y^c * g^d = t and then you would compute the hash. It would give you the proof that the signer knows x (authentication, non-repudiation) and that the message hasn't been tampered (integrity).

So this is one way of using Non-interactive proofs!

Well done! You've reached the end of my post. Now you can leave a comment or read something else.

Comments

Robin Alter

I am sure that you must have spent loads of your valuable time writing this useful article, Well! I must say that you write amazingly well. Thanks so much for sharing such useful info. cheers.

david

btw the process of creating a signature algorithm from a zkp (or doing nizkp from zkp) is called fiat-shamir.

Lev Menshchikov

Thanks for well-done indeep research, but it's a little bit unclear what you mean by saying:

"...along the message m. Which is basically a hash of the message with a proof that he knows the secret x." in the last part of the article.

How exactly can we imagine that parameter of signature? Can you provide any example or mathematic interpretation?

leave a comment...