Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming Zero Knowledge Proofs: From Zero to Hero

zkintro.com

Post reply on HN
Print view View original

161–170 of 170 posts

Re: Programming Zero Knowledge Proofs: From Zero to Hero

#161

Post by nailer »

tzs wrote: post #23
nailer wrote: post #3

> We can take a digital identity card and prove that we are over 18 years old > Without revealing anything else, like your full name or address If you are in this articles audience you would simply state the producer of the ID card signs a statement that the person is over 18. No ZKP needed. The article like many others would be improved with a better example.

I don't think a simple signature is sufficient if you want to maintain privacy with both the party you are trying to convince that you are over 18 and the party that signs the statement saying you are over 18. If the signer keeps a copy of the signature and who they made it for, someone who gets a hold of that and the records of party you used the signature at they can find out who you are. There are ZKP based protoc…

The party that attests to your age would still not know where you were using that attestation using regular digital signatures.

And yes, as previously mentioned the party you are testing to does not know your birthdate or any other information.

There is zero need for zkp with either of these

Re: Programming Zero Knowledge Proofs: From Zero to Hero

#162

Post by eru »

nailer wrote: post #148
eru wrote: post #139

Earlier quoted context omitted.

Sorry, what is certificate chaining in this context? ZKP allows you to run arbitrary logic, without the id providers having to anticipate what you are trying to do nor having to cooperate. Eg you could prove that 'either your age is a prime number or that you have green eyes and live in New York'.

> Sorry, what is certificate chaining in this context? crypto people need to learn crypto.

Let me be more blunt: I don't think certificate chaining is a useful concept in this context, but I wanted to be more polite about my objection and give you a chance to explain your idea. Better?

Re: Programming Zero Knowledge Proofs: From Zero to Hero

#163

Post by kikimora »

cyberax wrote: post #108
kikimora wrote: post #106

Earlier quoted context omitted.

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.

How will the circuit determine that you are actually you? How will it make a query to the police database to look for warrants?

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.

Re: Programming Zero Knowledge Proofs: From Zero to Hero

#164

Post by kikimora »

bschmidt1 wrote: post #112
kikimora wrote: post #106

Earlier quoted context omitted.

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.

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…

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.

Re: Programming Zero Knowledge Proofs: From Zero to Hero

#165

Post by kikimora »

bschmidt1 wrote: post #158
bschmidt1 wrote: post #155

Earlier quoted context omitted.

[flagged]

To address edits: > 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: `1028d7ea22cbbcb…

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

:) if I get a penny every time someone logs sensitive information in plain text to some log file without realizing they did.

Re: Programming Zero Knowledge Proofs: From Zero to Hero

#166

Post by bschmidt1 »

kikimora wrote: post #165
bschmidt1 wrote: post #158

Earlier quoted context omitted.

To address edits: > 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: `1028d7ea22cbbcb…

>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. :) if I get a penny every time someone logs sensitive information in plain text to some log file without realizing they did.

If I had a penny for every straw man argument. Who said anything about writing plaintext passwords to files - you just made that up?

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

Re: Programming Zero Knowledge Proofs: From Zero to Hero

#167

Post by bschmidt1 »

kikimora wrote: post #164
bschmidt1 wrote: post #112

Earlier quoted context omitted.

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…

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 man…

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.

Re: Programming Zero Knowledge Proofs: From Zero to Hero

#168

Post by kindkang2024 »

cyberax wrote: post #151
kindkang2024 wrote: post #134

Earlier quoted context omitted.

I'm not sure what you're referring to specifically. If you're asking why we need zero-knowledge proofs (ZKP) in a human passport system: Imagine you have 6 billion to give away, and all lives worldwide should get their fair share. How could you do this? Giving money to authorities like governments and trusting them? In the context of 'alllivesmatter.world', I propose the DUKI system. Here's how it works: - Each perso…

> - Each person has a human passport (they should never have more than one) I have 4 passports, all valid. With slightly different name spellings, from 3 different countries. That kind of real-world complexity is always hand-waved by cryptopushers in the: "Imagine Goldman Sachs..." pitches.

Thank you for highlighting the complexities around multiple passports and identity. Let me clarify the vision for a "human passport" concept:

1. The "human passport" I'm envisioning differs from traditional passports. Perhaps we could reuse the name WorldID that Worldcoin is developing, which uses biometric data like iris codes to ensure uniqueness. This approach is already working to some degree. Ideally, I just wish that it became a standard, with more implementations and also keep the iris-data at the device level, leaving countries with no excuse to refuse adoption. The goal is to have a standardized, cross-verifiable iris data system, rather than relying on a single authority to guarantee against forgery.

2. The varying name spellings on your different passports wouldn't be relevant to this system. Names are too variable to be components of a unique ID for each human. Instead, I imagine using something more like a social security number, that authorities issuing passports guarantee you never used twice at the same period. The ID thing is just a quick way to locate your public passport. The uniqueness check doesn't depend on this ID. It can be derived using your own private data to access your "human passport" released in public, which is generated using zero-knowledge proofs, and preserving privacy. Its uniqueness relies on authorities, also relies on some biometric data for example iris-data one-way features, etc., so even if you try to trick the system and create multiple IDs, you'd probably get caught.

3. This isn't just a vision - WorldID is already in use with millions of users. I just wish for wider adoption and for countries to have no excuse not to adapt it as a worldwide standard. The human passport vision isn't about pushing crypto tech; it's about considering how to make 'all lives matter worldwide' from another perspective.

Re: Programming Zero Knowledge Proofs: From Zero to Hero

#169

Post by somezero »

piotr93 wrote: post #61
somezero wrote: post #56

Earlier quoted context omitted.

A signature is a PoK, but not ZK.

I was not clear enough, thanks. Whether it is a pok or zk depends on the chosen signature scheme. In any case, zk signature schemes exist and are implied by the existence of one way functions and publicly verifiable nizk

> zk signature schemes exist and are implied by the existence of one way functions and publicly verifiable nizk.

Almost. The result is from CRYPTO89 paper of Bellare and Goldwasser. They derive a signature scheme from a nizk. It is not known whether you can get a nizk from a signature scheme. Moreover, no signature scheme can be a ZK: https://crypto.stackexchange.com/questions/35177/is-using-di...

Re: Programming Zero Knowledge Proofs: From Zero to Hero

#170

Post by somezero »

bschmidt1 wrote: post #94

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…

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.

Post reply on HN