Amazing article. Will save to explain ZKP to others.
One tiny correction
random.randrange(100) gives 300 possible commitments(3 colors for hundred nonces) After seeing a couple of revealed edges, the verifier can figure out the palette and brute-force all 300 combinations, effectively opening every commitment.
It can be mitigated if we use 128 bits of randomness, e.g. secrets.token_bytes(16).
Also I would use sha256 instead of hash. Python hash is not considered secure as it does not have proper collision resistance.
I don't think ZKPs / programmable cryptography are useless like some of the other commenters. But I do remember being surprised, based on the way that people talk about building on top of it, to learn that the performance is so bad (except on dedicated servers) that it's basically a theoretical technology until that's fixed. Has this changed recently? Not a rhetorical question.
Nowadays you can run arbitrary verified computation at 100-300MHz using so-called zkvm. State of the art are probably risczero and succinct.
Practically speaking, write any program you want, compile it to riscv, imagine to run it on a pretty fast microcontroller, and in addition to the result you get a proof of correct execution.
I’d say it’s pretty practical, all major unlocks happened like in the past 3-4y and of course there’s a ton of research still happening.
This is the slow/generic version. For specific problems (aka dedicated circuits) it can be much faster.
There's a big asymmetry where creating a proof is usually dramatically more expensive than verifying it (which is often extremely cheap!). That might be OK for some applications but still rule out other applications.
Not one mention that ZKP depends on servers trusting clients.
The single reason ZKP is not viable for most security is that it relies on you trusting the client to send you true information about data.
With conventional security the user sends their inputs and the server validates it.
Something I notice that is almost never mentioned when people bring up ZKP - it is pretty much only for peer-to-peer when there is no authoritative server. Or when that server trusts the “nodes” (clients).
> relies on you trusting the client to send you true information about data
this is false. the client is constrained to send you true information or else the verifiers will know to reject it.
ZKP's are not magic, you need a cryptographic operation on which to operate the ZKP. this way you can conceal the input while still proving something about it. this works because the ZKP follows the trace of execution through the cryptographic primitive which proves it was executed properly and then the output was validated by some public measure.
conversely, if ZKP's ever get fast enough to be useful for this you can prove a public input (ex. source code) was compiled properly into a public output (ex. binary). for obvious reasons doing this only makes sense when it's efficient otherwise you can just execute it yourself.
> this way you can conceal the input while still proving something about it
This doesn’t mean the input is “true” though. I can send some zkp that says I’m at least 18 or that I have at least $1M in my bank account, but it doesn’t mean that I actually am or do. Or am I missing something?
there is a dead comment below yours, these new accounts (weird?) seem convinced that a prover needs to be trusted. but if you trust the prover why would you need a proof? nevermind the fact that they are entirely mistaken it doesn't even make sense what they are alleging.
Zcash and many other cryptocurrency-related projects. The amount of cryptographers working on zero-knowledge proofs probably multiplied 10x thanks to cryptocurrencies.
It's a little bit funny to me. I can understand a response of "Hmm, while your application of cryptography may have some legitimate uses, in practice it seems like it's largely used for crime and scams." But I wonder what they thought the primary application of cryptography was going to me! Privacy-preserving technologies that allow you to hide from the government are necessarily going to be useful to criminals. But that's the price of freedom, no?
(I guess to be fair, some cryptographers might be interested in things like privacy-preserving voting, which wouldn't ever be useful to criminals.)
It relies on trusting that Alice’s request is valid. If Alice sends another proof, she will have a different balance. Alice decides what to send. The server blindly accepts it.
You actually don’t want that for a lot of security and that’s why nobody uses ZKP for passwords or really anywhere outside theory - dumb theory that doesn’t understand basic web dev. We already have hashing and databases. There is a narrow use case for trusting clients - like receiving updates from intranet or p2p devices - maybe you use ZKP to omit unnecessary pii. But that’s it. It’s not what you think it is.
Alice can send anything in any cryptographic scheme involving two parties, the only real safety in any of it is "are the odds of an accepted different value low enough to be impractical for an attacker". Does that apply here too?
What? Of course it’s a massive security flaw if you let any end user device send anything they want and just go “well they probably won’t send fake amounts”
Imagine such a bank. Or social media (impersonate anyone, just say you’re them on the request why not), or any website.
I think the fine article says it best when it says
> After doing a bit of research, we decided that the most common real world use cases of zero-knowledge proofs (age verification, crypto, etc) aren’t particularly interesting to us. We enjoyed the graphs and theory of computation and networked computing though. We hope you had fun playing around with interactive proofs too.
The inclusion of this statement makes your comments look rather bizarre and strangely combative by comparison. Maybe we can just enjoy a bit of math together?
I actually don't think ZKPs solve the age verification problem (for a variety of reasons that won't fit here), but they solve plenty of more interesting problems. Private transactions in Zcash, for example.
Only because zcash trusts the sending node - whoever is hosting that ledger.
If they had no clue who it was, like the typical http web, they could not allow a sender to be a prover, since they would not be able to verify their balance. At some point a balance inquiry would have to reveal who they are. It only works if you trust the banker.
Or by being a middleman. You send [payment service] the money and they send it to the recipient, hiding your info.
Amazing article. Will save to explain ZKP to others.
One tiny correction
random.randrange(100) gives 300 possible commitments(3 colors for hundred nonces) After seeing a couple of revealed edges, the verifier can figure out the palette and brute-force all 300 combinations, effectively opening every commitment.
It can be mitigated if we use 128 bits of randomness, e.g. secrets.token_bytes(16).
Also I would use sha256 instead of hash. Python hash is not considered secure as it does not have proper collision resistance.
I don't think ZKPs / programmable cryptography are useless like some of the other commenters. But I do remember being surprised, based on the way that people talk about building on top of it, to learn that the performance is so bad (except on dedicated servers) that it's basically a theoretical technology until that's fixed. Has this changed recently? Not a rhetorical question.
Nowadays you can run arbitrary verified computation at 100-300MHz using so-called zkvm. State of the art are probably risczero and succinct.
Practically speaking, write any program you want, compile it to riscv, imagine to run it on a pretty fast microcontroller, and in addition to the result you get a proof of correct execution.
I’d say it’s pretty practical, all major unlocks happened like in the past 3-4y and of course there’s a ton of research still happening.
This is the slow/generic version. For specific problems (aka dedicated circuits) it can be much faster.
There's a big asymmetry where creating a proof is usually dramatically more expensive than verifying it (which is often extremely cheap!). That might be OK for some applications but still rule out other applications.
Not one mention that ZKP depends on servers trusting clients.
The single reason ZKP is not viable for most security is that it relies on you trusting the client to send you true information about data.
With conventional security the user sends their inputs and the server validates it.
Something I notice that is almost never mentioned when people bring up ZKP - it is pretty much only for peer-to-peer when there is no authoritative server. Or when that server trusts the “nodes” (clients).
ZKP's are not magic, you need a cryptographic operation on which to operate the ZKP. this way you can conceal the input while still proving something about it. this works because the ZKP follows the trace of execution through the cryptographic primitive which proves it was executed properly and then the output was validated by some public measure.
conversely, if ZKP's ever get fast enough to be useful for this you can prove a public input (ex. source code) was compiled properly into a public output (ex. binary). for obvious reasons doing this only makes sense when it's efficient otherwise you can just execute it yourself.
> this way you can conceal the input while still proving something about it
This doesn’t mean the input is “true” though. I can send some zkp that says I’m at least 18 or that I have at least $1M in my bank account, but it doesn’t mean that I actually am or do. Or am I missing something?
But it’s not working that way, there is a third party like attestation that provides the data to client to generate zk proof
> the client is constrained to send you true information
Yeah ok bud. You wouldn’t last a week.
What is your envisaged application? ZKPs give you integrity guarantees which prevent malicious behaviour.
there is a dead comment below yours, these new accounts (weird?) seem convinced that a prover needs to be trusted. but if you trust the prover why would you need a proof? nevermind the fact that they are entirely mistaken it doesn't even make sense what they are alleging.
something is fishy in this comment section.
Zcash make a significant contro to ZKPs though, what would be the state without their tec?
Did their advancements have any other implications besides cryptocurrency?
Zcash and many other cryptocurrency-related projects. The amount of cryptographers working on zero-knowledge proofs probably multiplied 10x thanks to cryptocurrencies.
It's a little bit funny to me. I can understand a response of "Hmm, while your application of cryptography may have some legitimate uses, in practice it seems like it's largely used for crime and scams." But I wonder what they thought the primary application of cryptography was going to me! Privacy-preserving technologies that allow you to hide from the government are necessarily going to be useful to criminals. But that's the price of freedom, no?
(I guess to be fair, some cryptographers might be interested in things like privacy-preserving voting, which wouldn't ever be useful to criminals.)
ZKP is 100% bullshit.
It’s a new word invented by people who don’t know hashing and databases already exist.
PAKE has been using ZKPs for a decade. Here. Read this : https://en.wikipedia.org/wiki/Password_Authenticated_Key_Exc...
Funny that not only are you ignorant you are violently confident in your ignorance. I suffer from this sometimes too so I get it. Get some help.
> Alice sends out
It relies on trusting that Alice’s request is valid. If Alice sends another proof, she will have a different balance. Alice decides what to send. The server blindly accepts it.
You actually don’t want that for a lot of security and that’s why nobody uses ZKP for passwords or really anywhere outside theory - dumb theory that doesn’t understand basic web dev. We already have hashing and databases. There is a narrow use case for trusting clients - like receiving updates from intranet or p2p devices - maybe you use ZKP to omit unnecessary pii. But that’s it. It’s not what you think it is.
> Alice sends out
Alice can send anything in any cryptographic scheme involving two parties, the only real safety in any of it is "are the odds of an accepted different value low enough to be impractical for an attacker". Does that apply here too?
What? Of course it’s a massive security flaw if you let any end user device send anything they want and just go “well they probably won’t send fake amounts”
Imagine such a bank. Or social media (impersonate anyone, just say you’re them on the request why not), or any website.
The “zero knowledge” part of the name checks out.
Please explain how Alice’s request can ever be not valid. It’s literally a pre authenticated exchange.
Also nice sock puppet.
It has a use case in peer-to-peer or anywhere that you want the server to trust the connections.
Sometimes you want clients to be authoritative (although rare).
A great way to announce that you don't understand ZKP
Explain why you need ZKP for their flagship problem - the “prove you’re 21” thing.
Or choose any case you like.
Explain why I can’t do it without this hilariously elementary philosophy detached from real world dev.
No cheating! I get access to the same resources. Explain why I need ZKP.
I think the fine article says it best when it says
> After doing a bit of research, we decided that the most common real world use cases of zero-knowledge proofs (age verification, crypto, etc) aren’t particularly interesting to us. We enjoyed the graphs and theory of computation and networked computing though. We hope you had fun playing around with interactive proofs too.
The inclusion of this statement makes your comments look rather bizarre and strangely combative by comparison. Maybe we can just enjoy a bit of math together?
I actually don't think ZKPs solve the age verification problem (for a variety of reasons that won't fit here), but they solve plenty of more interesting problems. Private transactions in Zcash, for example.
Only because zcash trusts the sending node - whoever is hosting that ledger.
If they had no clue who it was, like the typical http web, they could not allow a sender to be a prover, since they would not be able to verify their balance. At some point a balance inquiry would have to reveal who they are. It only works if you trust the banker.
Or by being a middleman. You send [payment service] the money and they send it to the recipient, hiding your info.
Yes, they just hand out Turing Awards for bullshit.