[bschmidt1]

I wrote ZKPs off as hype ~2 years ago - is it a legit concept outside blockchain marketing? Someone help me understand how it's different from hashes and access tokens?

> "Zero-knowledge proofs (ZKPs) are a method for one party to cryptographically prove to another that they possess knowledge about a piece of information without revealing the actual underlying information."

So, like this?

1. An app needs to confirm a user login is correct

2. But the app can't know the user's password because it's a secret

3. So the app instead checks for a hash which only the correct password would translate into

4. Now the user can enter their password, and the app can verify the password is correct without actually knowing it

What am I missing?

[somezero]

It’s all just bytes and hashes and alike at the bottom. Absolutely nothing magical. It is the abstractions over them that makes them esoteric, not the fundamental building blocks.

As to why your example isn’t zero-knowledge proof of knowledge of a password, it’s because hash of the same password is always the same thing. So what if someone copies the hashed password and passes it as their own? You say, sign something? But I can reuse the signature. You say, sign a random challenge? Okay, but what if, on the other side, the verifier (ie. the app) adaptively picks a challenge instead of randomly sampling it? … Continue this line of thought, and once you have the correct solution, simplify it and remove the unnecessary parts (eg. Signing something is too strong of a requirement) and you get something called Zero-Knowledge proof of knowledge out of an honest-verifier sigma protocol.

As for ZK proofs that are not proofs of knowledge, then the easiest way to think of it is an encrypted data structure like a database. Imagine the client wants to check whether an element is in some set on a server, where the server has an “encrypted” form of a set and can’t see what’s in it. How can the server check membership of an element and convince the client? That’s done with a ZK proof. You say what about Fully Homomorphic encryption? That’s also technically ZK… what’s not a ZK? For anything that you can’t write a simulator. What’s a simulator? Pick a cryptography textbook.

[kikimora]

No, this is more like this. Here is my ZKP to verify you are older than 18. Please pass it your ID card and give me result. I’ll verify result and prove you are above 18. On top of that the proof output would contain your photo from the document so I can visually compare it with your face.

In the end all I know is you are older than 18. I don’t know your driver license number or SSN, I don’t know your name. I know nothing but the fact that your are older than 18.

[bschmidt1]

Same thing. In my example the function only knows whether the provided hash equals the one on file. Yours is essentially the same - is the provided DOB < the one on file (presumably, today's date 18 years ago). No other data is known about the person in either case.

This is also accomplished by just properly scoping the function. Considering the widespread availability of solutions to this well-known* problem, I wonder why anyone would "use ZKPs" - and what does that even mean? What npm should I install - and why?

* where my ACME Challenge fans at

[TimJRobinson]

The hash check is binary, you can only check if a password is correct or not. The ZK proof can prove anything, like that the password has enough special symbols and numbers that it's secure.

There's no way to check that someone's age is old enough with just a hash unless you break the hash.

The most common but painful way to write ZK circuits is with Circom. Better more modern ways are with Noir or using SP1 which can prove arbitrary rust code.

[bschmidt1]

> ZK proof can prove anything

Apparently not, isn't it designed specifically such that it's scoped to a particular "proof"?

You guys always say "without it linking you to your identity" as if identity is built into JavaScript or something. How does using a password hash inherently leak my PII? What problem does ZKP solve?

Using conventional development you can also do the trivial stuff you mentioned like running password through regexp.

[TimJRobinson]

What do you mean scoped to a particular proof? There are different proof types like there are different hashing algorithms, they can all prove any data just like sha256 and md5 can hash any data.

How do you verify the password meets certain requirements sever side without getting that user data? Client side input can't always be trusted as anyone can modify that regex check.

Here's a project doing passport verification for services without needing to send them a photo of your passport: https://github.com/zk-passport/openpassport

With something like TLS notary you can prove anything signed by a https certificate, so you can prove there are enough funds in your bank to get a mortgage without revealing how much money you have.

[bschmidt1]

Re: scoped

In response to your comment The ZK proof can prove anything, like that the password has enough special symbols and numbers - you definitely do not need "ZKPs" to do this trivial task.

and

> There's no way to check that someone's age is old enough with just a hash

Yeah you can, you log them in then link them to that userData with an identifier - typically an email address or unique user ID. You can easily write the login API to know nothing but hashes, or you can write it to respond with - to use your example that user's age - if the password is correct (without ever actually knowing the password).

Re: Passport verification

Anybody can verify any document with enough identifying information about the document and a registry to match it up to. You don't need a private/public key library wrapped around any functions to accomplish that, but the government probably requires the photo for a reason. Maybe you can verify the document, but a lot of services are going to require photo identification regardless of what your library can do without a photo. Again trying to find what problem this solves. Would have been way cooler if you said it verified faces with passport photos - that's the hardest part.

[magicalhippo]

The previous article[1] goes a bit into the difference from a simple has function.

It was very long-winded, so I haven't fully read it yet.

The key difference seems to be that a simple has function has a single argument. To verify the output you need the input value. While a ZKP function has two arguments, and one of them is not needed to verify the output.

Not sure if it makes much sense in a direct login scheme, but the alternative scenarios sound more interesting. For example, proving to an adult website you're over 18 without revealing your identity to that website.

[1]: https://zkintro.com/articles/friendly-introduction-to-zero-k...

[bschmidt1]

I can also enter a password without revealing my identity, how is it fundamentally different?

If I use an authentication provider, am I now "using ZKPs" because I can log people in without knowing who they are?

Or if I use any identity verification provider (example: Clear), am I using ZKPs since my app doesn't actually see your identity? We just get the OK from Clear?

[magicalhippo]

Like I said, I'm not sure the simple password scenario is a very good example, because the app doesn't really care about the details of the secret itself, ie your password. Only that it's the same as you presented when you signed up.

I found the Sudoku example more illustrative, where you want to share your knowledge of the solution without sharing the solution itself. In that case, others do indeed care about the details of your knowledge.

You can't just provide a hash of the solved board and say "lol solved it", as only those who had also already solved it could verify your statement. Maybe I don't trust those others who claim they also solved it, how can I verify that indeed you solved it? You could tell me the solution but then you'd ruin the puzzle for me, which is no good.

So as I understand it, the point of ZKP is that they allow you to share proof of your Sudoku solution to me, in a way where I can be certain you do indeed have the right solution, without me learning what exactly the solution is.

[bschmidt1]

> You can't just provide a hash of the solved board

Wait, why not? You could represent the Sudoku board as matrices, here's an example of one block:

    [

      [9, 5, 7]

      [4, 8, 3]

      [6, 1, 2]

    ]

(same idea for 9x9)

Imagine a "Sudoku Online" where we all have our own private boards, but we have a shared public chat like an online game. Any of us can click "Check Solution" which hashes our Suduku board and sends it to the chat. A message might look like:

    *magicalhippo is checking a hash... f3ghziiv × Failed*

    *bschmidt1 is checking a hash... 242eef7z × Failed*

    *magicalhippo is checking a hash... zzw4zq3x  Passed*

All players see the hash activity in the public chat, but none of us can see each others' boards - we only have insight to whether or not the solution was valid.

The validity check could run on a central trusted server, like where the game is hosted, or in a peer-to-peer setup a condition of passing could be that a peer machine must validate it. So no client can validate their own hash. It could even be in an "Unverified" state until some threshold % of players have validated it - could do anything you want, but I don't see how "ZKPs" offer any solutions.

Most of the libraries are either utils that have like generateUUID functions in them, or they're private/public key libraries that let you wrap functions in an additional encrypted layer. Haven't seen a goto ZKP npm yet or heard anything about what it improves/solves.

[blurbleblurble]

I've also found that it's hard to sort out the blockchain hype from the interesting stuff, but trust me, ZK proofs are amazing and have applications way beyond blockchain. They're a new primitive in a space that's being called "programmable cryptography". Some other interesting building blocks in this space are secure multi-party computation (MPC) and fully homomorphic encryption (FHE).

Forgive my simplified/contrived examples but you can do a whole lot more with zero knowledge proofs than you can do with just hashes and access tokens, stuff that has nothing to do with blockchain.

For example:

1. An individual receives a contract via email and needs to confirm that it contains a specific clause ("The client agrees to pay $10,000 within 30 days").

2. However, they don’t want to reveal the rest of the contract to the verifier.

3. The individual uses a ZKP that proves two things:

  a. The contract is digitally signed by the specific email domain of the sender (e.g., @example.com).
  b. The contract contains the specific clause matching a regular expression pattern (e.g., The client agrees to pay \d+\ within \d+ days).

4. The verifier receives the proof, checks its validity, and confirms both the signature and the presence of the clause, all without seeing the full document.

Here's another one:

1. A passenger needs to prove to a ride-sharing app that they are within a specific pickup zone to request a ride.

2. The passenger doesn’t want to broadcast their exact location due to privacy concerns. They're using a device that can attest to the authenticity of their location.

3. The passenger uses a ZKP that proves:

  a) Their current location is within the allowed pickup area.
  b) Their mobile device has provided an attestation that their given location wasn't spoofed.

4. The ride-sharing app verifies the proof, allowing the ride request, while the passenger’s precise location remains private.

5. The rider can choose to share their exact location with a nearby driver when the time comes, but doesn't need to broadcast their exact location to all drivers.

And yet another one:

A user wants to prove that their edited photo originated from an actual physical camera capable of signing images.

For each consecutive edit, the editing software creates a proof that the input image is either an original signed image or comes with a ZK proof that it's derived from a sequence of edits originating from a signed input image. ZK proofs can be combined in such that we can turn a large number of proofs with dependencies on one another into a single, quickly verifiable proof. So in the end you can quickly verify that a heavily edited image does indeed originate from a trusted camera.