3 ms·

Any time I get someone to explain a real world use case they explain the concept of password hashing. Also, the only people who ever talk about "ZKPs" are these

Any time I get someone to explain a real world use case they explain the concept of password hashing. Also, the only people who ever talk about "ZKPs" are these obviously non-technical crypto founders - it's possible they think it's a new thing when it's something we deal with everyday as developers. I can't get anyone to explain how it's different than a password hash other than in these elaborate hypothetical scenarios that don't relate to technology.

kikimora 2y ago
Instead of asking your id police office pass you a circuit. You present your ID to the circuit and pass results to the officer. The officer then verifies you are not a criminal without ever looking at your documents.
- cyberax 2y ago
  How will the circuit determine that you are actually you? How will it make a query to the police database to look for warrants?
  - kikimora 2y ago
    Circuit returns a photo form your document as an output and the officer compares it to your face. The circuit won’t query DB but rather return your name or maybe a hash that can be used to query the database.
  - TimJRobinson 2y ago
    The ID would need to have some government digital signature for the ZK circuit to work. The proof would be "this digital ID that has this valid government signature shows XYZ". The verifier would need the government public key and then can see "This ID that has been signed by the governments private key shows XYZ"
    - cyberax 2y ago
      And the next question is: why bother? We have well-established protocols for the ID card: a police scanner creates a nonce and sends it to the card, the card signs it with its private key, and provides a certificate signed by the government. The police scanner then verifies the signature and checks that the certificate is correctly signed by the government's public key. No need for ZKP.
      - TimJRobinson 2y ago
        You think peoples licenses / passports are little computers with API's built into them that return arbitrary information on demand? Over the internet?
        cyberax 2y ago
        > You think peoples licenses / passports are little computers with API's built into them that return arbitrary information on demand? Literally yes, in some places. Passports have a chip in them, and licenses in some countries as well. > Over the internet? Tunneling private information over untrusted networks is literally how you're seeing this message.
        TimJRobinson 2y ago
        Yea the chip gives the information written on the device. It doesn't answer arbitrary questions about the data. The whole point of ZK proofs is the zero knowledge part. If you don't care about the person being able to see the information of course there's no need for them.
        bschmidt1 2y ago
        First you described exactly the concept of password hashing, now you're describing something else entirely: > It doesn't answer arbitrary questions about the data. Why would you need a "ZKP" to prevent anyone from "asking arbitrary questions" you simply don't build that functionality. When I create a web server and allow people to login through an endpoint, they can't ask arbitrary questions about user data either - how would that functionality even exist without me writing it? Typically the server doesn't even know passwords. It simply compares a hash - the hash is computed client-side and the server never sees the real password. Any peripheral user data you want to return is up to you. Identity is not "built in" to conventional programming languages. Furthermore, none of the ZKP libraries on npm do anything. Most of them are utility libraries with functions like "generateUUID" and "leftPad". The ones from providers like Cloudflare (their least popular stuff) are just private/public key encryption libraries that they call "ZKP".
- bschmidt1 2y ago
  This is the same fundamental thing as the password hash example. I can verify you without ever seeing your password, the policeman can verify you without ever seeing your documents - same exact concept. My question is then: What is unique to ZKPs? Are the ZKP folks just asking us to start calling these techniques "ZKPs"? When I use Clear for IDV is that a ZKP? Just like your example, they show the ID to Clear, but I never see the ID.
  - kikimora 2y ago
    Hashing is a limited variant of ZKP which can answer one exact question. With ZKP you can also check if password has certain length, special characters, etc., without ever seen the password itself. Clear is not ZKP because Clear servers learn all data from your documents. With ZKP Clear would only know that you hold an ID with details matching the ticket you also hold. This is just 1 bit of information instead of many.
    - bschmidt1 2y ago
      Re: Hashing - The point of one-way encryption is that it can't be decrypted. A plaintext password has 1 job, to be read, not saved - yet you want to encrypt it as if it will be saved, but because it's one-way encrypted now it can't be read. What problem did you solve? You created a problem (that you now need ZKP to solve...) Anyway, the ZKP concept is not about decrypting hashes at all, but looking at peripheral data to prove something (Alibaba Cave - Victor only knows Peggy knew the password because he had access to some other data - the path she took). "checking length etc." only if those hints are already available to the system in some way. And because of this approach, why would you need the hash? Just don't use passwords at all in the case of ZKP right? Simply rely on the other identifying data that you have access to, that you use anyway. Also - how secure is this loose profiling technique compared to email-backed passwords over HTTPS? I imagine few product use cases allow for a server to trust all the clients with encryption, while not trusting itself - but there are some use cases like when the server is not the source of truth - file system service, or peer-to-peer stuff like ledgers: If the server's purpose is just to maintain a shared ledger and all the clients in the network are trusted. But in the case we're talking about, of a service that authenticates clients, you're saying you can't trust the authenticator when that is kinda the point of authentication - they don't trust you, or rather - the server cannot tell for sure that any incoming connection is who they say they are, even if it has "zero knowledge" like their IP address and a face scan (your brother in the same house might pass). The point of a username and password is that you want the server to not trust any connecting clients unless they have this specific data precisely. So I wouldn't use it for auth.

kikimora 2y ago

Instead of asking your id police office pass you a circuit. You present your ID to the circuit and pass results to the officer. The officer then verifies you are not a criminal without ever looking at your documents.

cyberax 2y ago
How will the circuit determine that you are actually you? How will it make a query to the police database to look for warrants?
- kikimora 2y ago
  Circuit returns a photo form your document as an output and the officer compares it to your face. The circuit won’t query DB but rather return your name or maybe a hash that can be used to query the database.
- TimJRobinson 2y ago
  The ID would need to have some government digital signature for the ZK circuit to work. The proof would be "this digital ID that has this valid government signature shows XYZ". The verifier would need the government public key and then can see "This ID that has been signed by the governments private key shows XYZ"
  - cyberax 2y ago
    And the next question is: why bother? We have well-established protocols for the ID card: a police scanner creates a nonce and sends it to the card, the card signs it with its private key, and provides a certificate signed by the government. The police scanner then verifies the signature and checks that the certificate is correctly signed by the government's public key. No need for ZKP.
    - TimJRobinson 2y ago
      You think peoples licenses / passports are little computers with API's built into them that return arbitrary information on demand? Over the internet?
      - cyberax 2y ago
        > You think peoples licenses / passports are little computers with API's built into them that return arbitrary information on demand? Literally yes, in some places. Passports have a chip in them, and licenses in some countries as well. > Over the internet? Tunneling private information over untrusted networks is literally how you're seeing this message.
        TimJRobinson 2y ago
        Yea the chip gives the information written on the device. It doesn't answer arbitrary questions about the data. The whole point of ZK proofs is the zero knowledge part. If you don't care about the person being able to see the information of course there's no need for them.
        bschmidt1 2y ago
        First you described exactly the concept of password hashing, now you're describing something else entirely: > It doesn't answer arbitrary questions about the data. Why would you need a "ZKP" to prevent anyone from "asking arbitrary questions" you simply don't build that functionality. When I create a web server and allow people to login through an endpoint, they can't ask arbitrary questions about user data either - how would that functionality even exist without me writing it? Typically the server doesn't even know passwords. It simply compares a hash - the hash is computed client-side and the server never sees the real password. Any peripheral user data you want to return is up to you. Identity is not "built in" to conventional programming languages. Furthermore, none of the ZKP libraries on npm do anything. Most of them are utility libraries with functions like "generateUUID" and "leftPad". The ones from providers like Cloudflare (their least popular stuff) are just private/public key encryption libraries that they call "ZKP".
bschmidt1 2y ago
This is the same fundamental thing as the password hash example. I can verify you without ever seeing your password, the policeman can verify you without ever seeing your documents - same exact concept. My question is then: What is unique to ZKPs? Are the ZKP folks just asking us to start calling these techniques "ZKPs"? When I use Clear for IDV is that a ZKP? Just like your example, they show the ID to Clear, but I never see the ID.
- kikimora 2y ago
  Hashing is a limited variant of ZKP which can answer one exact question. With ZKP you can also check if password has certain length, special characters, etc., without ever seen the password itself. Clear is not ZKP because Clear servers learn all data from your documents. With ZKP Clear would only know that you hold an ID with details matching the ticket you also hold. This is just 1 bit of information instead of many.
  - bschmidt1 2y ago
    Re: Hashing - The point of one-way encryption is that it can't be decrypted. A plaintext password has 1 job, to be read, not saved - yet you want to encrypt it as if it will be saved, but because it's one-way encrypted now it can't be read. What problem did you solve? You created a problem (that you now need ZKP to solve...) Anyway, the ZKP concept is not about decrypting hashes at all, but looking at peripheral data to prove something (Alibaba Cave - Victor only knows Peggy knew the password because he had access to some other data - the path she took). "checking length etc." only if those hints are already available to the system in some way. And because of this approach, why would you need the hash? Just don't use passwords at all in the case of ZKP right? Simply rely on the other identifying data that you have access to, that you use anyway. Also - how secure is this loose profiling technique compared to email-backed passwords over HTTPS? I imagine few product use cases allow for a server to trust all the clients with encryption, while not trusting itself - but there are some use cases like when the server is not the source of truth - file system service, or peer-to-peer stuff like ledgers: If the server's purpose is just to maintain a shared ledger and all the clients in the network are trusted. But in the case we're talking about, of a service that authenticates clients, you're saying you can't trust the authenticator when that is kinda the point of authentication - they don't trust you, or rather - the server cannot tell for sure that any incoming connection is who they say they are, even if it has "zero knowledge" like their IP address and a face scan (your brother in the same house might pass). The point of a username and password is that you want the server to not trust any connecting clients unless they have this specific data precisely. So I wouldn't use it for auth.