2 ms·

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 clien

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

teravor 2mo ago
> 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.
- diamondclouds 2mo ago
  [flagged]
- what 2mo ago
  > 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?
  - ahmetson 2mo ago
    But it’s not working that way, there is a third party like attestation that provides the data to client to generate zk proof
    - what 2mo ago
      Then just ask the third party?
      - Nursie 2mo ago
        That can leak information to the third party that you may not want them to know.
        ctdinjeu99 2mo ago
        [flagged]
      - teravor 2mo ago
        a third party can voluntarily surrender complete control over what is going on. they can issue a token for something, for example a $10 dollar bill but do it in such a way (blind signature) that when you go to spend it they cannot connect the spend to the bill they issued. 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).
      - ahmetson 1mo ago
        You can. For example for verifying enough funds the immigration office could ask the bank itself. But it also adds additional problem, such that without users concern they can do anything. Even if it’s solved with papers and users signature it’s more slower. With zk proof you can optimize immigration from third world country to the first world country with a single online application. Or you can make it for remote programming job. Create a zk proof of codes he has worked on. And apply to HR so hr doesnt have to waste time on due diligence or mess with nda to look at private code base, few devs have public code. Zk makes, cross institute as an online service more efficient.
  - cryptonector 2mo ago
    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's security characteristics are supposed to make that exceedingly difficult. Meanwhile, the ZKPP is also supposed to make it exceedingly difficult to recover the password from a ZKPP exchange that any eavesdropper could record. A non-augmented ZKPP protects the password from eavesdroppers, but the server's verifier is a password-equivalent (though it isn't the password, just a one-way function of it). A ZKPP is the simplest ZKP application, but others work similarly. In other words: you're missing everything about ZKPs.
    - ctdinjeu99 2mo ago
      [flagged]
  - schoen 2mo ago
    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" 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!
    - teravor 2mo ago
      in that scenario you can obtain a nullifier which serves as your identifier but prevents you from generating a new one without another valid passport. 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.
Ar-Curunir 2mo ago
What is your envisaged application? ZKPs give you integrity guarantees which prevent malicious behaviour.
- rubyclouds 2mo ago
  [dead]
- teravor 2mo ago
  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.

teravor 2mo ago

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

diamondclouds 2mo ago
[flagged]
what 2mo ago
> 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?
- ahmetson 2mo ago
  But it’s not working that way, there is a third party like attestation that provides the data to client to generate zk proof
  - what 2mo ago
    Then just ask the third party?
    - Nursie 2mo ago
      That can leak information to the third party that you may not want them to know.
      - ctdinjeu99 2mo ago
        [flagged]
    - teravor 2mo ago
      a third party can voluntarily surrender complete control over what is going on. they can issue a token for something, for example a $10 dollar bill but do it in such a way (blind signature) that when you go to spend it they cannot connect the spend to the bill they issued. 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).
    - ahmetson 1mo ago
      You can. For example for verifying enough funds the immigration office could ask the bank itself. But it also adds additional problem, such that without users concern they can do anything. Even if it’s solved with papers and users signature it’s more slower. With zk proof you can optimize immigration from third world country to the first world country with a single online application. Or you can make it for remote programming job. Create a zk proof of codes he has worked on. And apply to HR so hr doesnt have to waste time on due diligence or mess with nda to look at private code base, few devs have public code. Zk makes, cross institute as an online service more efficient.
- cryptonector 2mo ago
  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's security characteristics are supposed to make that exceedingly difficult. Meanwhile, the ZKPP is also supposed to make it exceedingly difficult to recover the password from a ZKPP exchange that any eavesdropper could record. A non-augmented ZKPP protects the password from eavesdroppers, but the server's verifier is a password-equivalent (though it isn't the password, just a one-way function of it). A ZKPP is the simplest ZKP application, but others work similarly. In other words: you're missing everything about ZKPs.
  - ctdinjeu99 2mo ago
    [flagged]
- schoen 2mo ago
  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" 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!
  - teravor 2mo ago
    in that scenario you can obtain a nullifier which serves as your identifier but prevents you from generating a new one without another valid passport. 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.

Ar-Curunir 2mo ago

What is your envisaged application? ZKPs give you integrity guarantees which prevent malicious behaviour.

rubyclouds 2mo ago
[dead]
teravor 2mo ago
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.