Exploring Zero-Knowledge Proofs
manishearth.github.io
manishearth.github.io
Are there specific things you're having a hard time understanding? I'd love to explain and/or update the post!
>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?
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 .
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!
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.
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) 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.