41–50 of 54 posts
Earlier quoted context omitted.
> 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?
Consider ZK password proof protocol: at enrollment (password set / change) the server -or a third party it trusts- knows the password and computes a verifier, while at login time the server uses the verifier to validate that the client knows the password but without the client revealing the password to the server. The client could perhaps have found an alternative password that matches the same verifier, but the ZKPP…
Earlier quoted context omitted.
But it’s not working that way, there is a third party like attestation that provides the data to client to generate zk proof
Then just ask the third party?
if you want to do it without a third party you end up with something like zcash. monero plans to follow suit (currently only the amounts in monero are zero knowledge).
Earlier quoted context omitted.
> 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 th…
> 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?
This setting is generally "proof of attribute" or "proof of group membership" although in practice it is most often more like "proof of possession of a credential". An interesting example demonstrated a few years ago is that you could prove that you possess a passport from a certain country without revealing anything else about your identity (as the passports are digitally signed by their issuing authorities using publicly-known keys). You could then have, for example, an online forum or poll that only allows participation of people with a certain credential, yet the forum or poll operator never learns the offline identities of the members or participants.
There are some logistical issues with this depending on the purpose for which the verifier is relying on the statement, including what happens if a prover submits the same credential twice, and what happens if a prover borrows a credential from someone else. In some settings this is OK or unlikely, while in other settings it might effectively blow up the whole application!
Fiat-Shamir transformation. The interactive process between the prover and verifier can be transformed into a non-interactive one with a hash function(modeled as a random oracle). This improves the "user experience" as the entire proving process can be done in a single turn. The idea is to feed the problem itself into the hash function and let it generate randomness that was originally given by the verifier.
Earlier quoted context omitted.
> 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?
You can prove that you possess a digital signature from some authority over a statement that says that you are 18 or that you have $1,000,000. However, you don't have to reveal that actual statement or signature. Typically, that would be because the statement contains your offline identity and you don't want to reveal that to the verifier. This setting is generally "proof of attribute" or "proof of group membership"…
the nullifier can then be your cryptographic identity as a member of some group. without disclosing the actual member.
it will likely be some time before such structures see use.
imagine a physical meeting between 1000 people and they all exchange some random-seeming string (prepared ahead of time), then they join a special group chat where they know there can only be 1000 members and each one corresponds to someone who was present in the meeting. but unless they out themselves (or everyone else does) they will never know who is who. and yet the group chat can be entirely p2p and no one can cheat. and there could be spy cameras watching every exchange in the meeting and all the exchanged notes and it wouldn't matter.
that way that works is by using a ZKP to prove that a previously secret but now disclosed nullifier string is a cryptographic relation to one member of the sorted list of all the exchanged strings in the meeting. and the nullifier happens to be a public key hash.
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.