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.
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).
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.
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.
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 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.
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.