
Exploring Zero-Knowledge Proofs - Manishearth
http://manishearth.github.io/blog/2016/03/05/exploring-zero-knowledge-proofs/
======
aakilfernandes
Following this right up to the logic gates section. Personally, I find it
pretty hard to follow after that. Maybe try a different way of explaining it?

~~~
Manishearth
It's a pretty fiddly thing, and took me a while to work out too.

Are there specific things you're having a hard time understanding? I'd love to
explain and/or update the post!

~~~
kevinwang
I didn't quite understand this paragraph:

>Since XOR is its own inverse, if we wish to encrypt an input before piping it
through this gate, we just XOR it with the relevant input key. If we wish to
decrypt the output, we again XOR it with the output key. The XOR gates being
applied will just cancel out with the internal encryption gates. In other
words, encryption and decryption are done with the same operation!

So, there are 3 encryption keys for each encrypted-and-gate? I think I follow
this, but I don't follow how in the first sentence, "XOR is its own inverse"
logically leads to "if we wish to encrypt an input before piping it through
this gate, we just XOR it with the relevant input key".

Isn't the fact that XOR is its own inverse only pertinent to the second
sentence? I think it makes sense to me that since XOR is its own inverse, then
if we wish to encrypt an _output_ , we'd XOR it with that encryption key, and
then to decrypt that output, we'd XOR it again. But how is the fact that XOR
is its own inverse relevant to the AND gate's _inputs_?

~~~
Manishearth
Yes, there are three encryption keys.

I think I know where your confusion is coming from.

This _entire_ box is an encrypted AND gate.
[http://manishearth.github.io/images/post/and-encr-
xor.png](http://manishearth.github.io/images/post/and-encr-xor.png) .

The input wires _outside_ the box are "encrypted inputs". They get internally
decrypted via XOR and stuffed into a regular Joe AND gate. To create an
encrypted input, we must encrypt a regular input, by XORing _again_ (due to
the inverse thing).

Similarly, the output wire outside the box is an encrypted output. The output
of a regular Joe AND gate is encrypted internally (via XOR) to obtain this. To
decrypt this encrypted output, we must similarly XOR again.

Does this address your confusion? Let me know if you need more explanation!

~~~
kevinwang
Yes, thank you! I was thinking of the inputs to the box as the unencrypted
inputs, which the XOR gates in the box would encrypt, but now I see that it's
the opposite. It wasn't clear to me from the post that the outputs _and_
inputs from the encrypted-and-gate are both supposed to be encrypted, and it
might not be clear to others either. Thanks for taking the time to explain!

~~~
Manishearth
No problem! I updated the post to be clearer about this.

------
mike_hearn
The tricky part of the whole thing is that the original writeup claims "there
are compilers that convert C to circuits".

This is technically true but not helpful, because (as far as I'm aware) none
of the good ones are open source or even publicly available at all.

Also, they typically compile only a restrictive subset of C, not full blown C.
For instance, you normally have to be able to statically unroll all the loops.
The only compiler that can handle full C works by using a (very large) circuit
that emulates an actual CPU. Proving times are extremely high, as you might
imagine.

Without a compiler, you are restricted to proving very trivial statements that
are of little practical use (except as building blocks for more advanced apps)
... things like "I own the solution to a soduku puzzle" i.e. a pure constraint
satisfaction problem.

~~~
Manishearth
> Also, they typically compile only a restrictive subset of C,

It has to be a restrictive subset of C; since not all C code has a
combinatorical equivalent. Sequential circuits (those with things like flip
flops) do not work with this proof[1]. I also _suspect_ that there is no
general zero knowledge proof for these circuits/programs, and there may be
sequential circuits for which there is no ZKP at all. This is because
variables like "the number of iterations in a loop" can be extracted from the
execution proof, making it no longer zero knowledge. I don't think that this
can be masked in a general solution that doesn't completely unroll loops. I
don't know how to prove this, but I suspect that the halting problem will be
involved in raining on this parade.

However, most problems can be converted to this restrictive subset, since
given the size of the input there is usually a bound on the number of
iterations of a loop. In general the halting problem should stop you from
calculating this bound, but in most specific cases I think this would be
doable.

> none of the good ones are open source or even publicly available at all.

I've not used it, but libsnark ([https://github.com/scipr-
lab/libsnark](https://github.com/scipr-lab/libsnark)) seems to have a bunch of
utilities to be able to construct programs using various abstractions it
provides. But yeah, no compiler.

> you are restricted to proving very trivial statements that are of little
> practical use

Agree 100%. I'm more interested in the cool theory behind it (and its ability
to compose with systems like Bitcoin) than actual practical uses. This is
pretty much my usual attitude towards such things

One practical use I can come up with would be to securely sell a decryption
key (or really, any kind of key) via Bitcoin. The bitcoin script already lets
you do this, however in the process the key would become publicly known. You
can use the trick with the pad mentioned at the bottom of the post in
conjunction with ZKP. I suspect that writing the verifier for this using
something like libsnark wouldn't be too hard, but I don't know for sure.

[1]: They work in the sense that it's still possible to prove things using the
same algorithm, but it's no longer zero knowledge: many gates will be visited
multiple times, so more than one truth table entry will be revealed, which
makes it possible to decrypt the gate. The number of times a gate is visited
also leaks information.

