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...
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?
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.
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]
]
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*
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.
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).
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.
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.
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.
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
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.
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.
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.
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.
You haven't provided an alternative way though? If you're looking for more complicated things they can do see: https://news.ycombinator.com/item?id=41430157
> 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).
This doesn't make sense, how do you verify someones age without getting their birthday? Hashes are binary yes/no checks, not range checks.
> Anybody can verify any document with enough identifying information about the document and a registry to match it up to.
So your alternate solution is that every government in the world runs an API you can check a passport against? Instead of them just providing a known public key they signed the passport with? Sounds way over complicated compared to a ZK proof.
Check if it has numbers: \d
Check if it has symbols: \W
Check if it's 6-64 chars long: {6,64}
> This doesn't make sense
Promise you it's how it works.
> Hashes are binary yes/no checks
Nope, just means encrypted text.
> every government in the world runs an API
Hilarious you think a decentralized approach where every participant has a copy of an append-only ledger is simpler than a central server with SQL database. The argument for decentralization was never that it was simpler - it's of course way simpler in many ways to have a single source of truth. If you mean using that passport library on a regular server, then you also have to run an API or nobody can use it.
- As you're still not getting it, how about this: This is a sha256 hash of my birthday, write a function that returns if I'm over 21: `1028d7ea22cbbcb17c4926b08b591506227d7b0e32ce6ce76122461e551a5ab2`
- Nothing I've mentioned needs an append only log, where are you even getting that from? A ZK proof is created from only the data stored on the passport chip.
And for the sake of this kindergarten discussion the hash is computed client-side - that's the whole point, so the server doesn't know your password. The hash is checked on the server side.
Your ZKP has no use case - most of you guys aren't web developers (that much is obvious) and don't realize these problems and solutions are trivial.
You are just talking about password hashing.
> when to encrypt
It depends on what you want to do, if it's user login over HTTPS you can pass a plaintext password to the server and hash/compare on the server only. It would still be secure because the plaintext is never saved in a db (only the hash is), and was TLS encrypted in transport.
-----
> This is a sha256 hash of my birthday, write a function that returns if I'm over 21: `1028d7ea22cbbcb17c4926b08b591506227d7b0e32ce6ce76122461e551a5ab2`
You hash the point of access like a password or key, not the data itself. When the access is granted, you return the data. sha256 is never meant to be decrypted. It would be like this:
interface User {
id: sha256;
name: string;
age: number;
}
const users: User[] = fetchUsers();
const isOver21 = plaintextId => users[encrypt(plaintextId)]?.age >= 21;
const validHashes: BirthdateHashSha256[] = seedHashesForToday();
const isOver21 = hash => validHashes.includes(hash);> And for the sake of this kindergarten discussion the hash is computed client-side - that's the whole point, so the server doesn't know your password. The hash is checked on the server side.
This is the exact thing I've mentioned 3 times already but you don't seem to grasp, you can't trust client side code! If you do trust the client then you don't need a proof, you may as well just have a popup that says "are you over 21?"
A rainbow table is just breaking the hash and then you may as well not have it.
:) if I get a penny every time someone logs sensitive information in plain text to some log file without realizing they did.
Also you might not understand web dev 101. Every website including this one that uses HTTPS sends encrypted data, the password you enter in a text input is in plaintext. For the backend - as I said above, the server hashes it and saves the hash, never the plaintext password.
That's how it works - nobody said anything about "log files".
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.
> "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?