zlacker

>>doomro+(OP)
Anyone have a good explanation on the intuition of non-interactive zero-knowledge proofs? For example, I thought the "paint-mixing" analogy for Diffie-Hellman key exchange (https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange#Ge...) really helped me handwave the math into "mixing easy, unmixing hard".

https://blog.cryptographyengineering.com/2014/11/27/zero-kno... was a good intro for interactive ZK proofs but I haven't been able to find something for non-interactive ones.

This blog post comparing ZK-STARKs to erasure coding is in the right flavor but didn't quite stick to my brain either: https://vitalik.eth.limo/general/2017/11/09/starks_part_1.ht...

>>bobbie+yc
Yeah I'm also interested in some of the details here, but the linked library repo is a bit too low-level for my current understanding.

For example, in the usecase of providing a proof-of-age to a website: who provides the verification data (the government?); what form does that take (a file in a standard format?); who holds/owns the verification data (the user?); who runs the verification software (the end-user's web browser?).

Can the user use any implementation to provide the proof, or must it be a "blessed" implementation such as Google Wallet?

>>coldpi+1e
(1) in this case, an identity issuer provides the source of truth identity information. Examples include state DMV, your passport (you can try "Id pass" in Google wallet), etc.

(2) One of the goals of this project was to layer ZK on top of current identity standards that DMVs already issue, so that gov orgs don't have to change what they currently do to support the strongest user privacy. One example format is called Mdoc.

(3) The user holds the identity information on their device only. No other copies. The user's device makes the zkp proof on-device. This was one of the major technical challenges.

(4) The relying party (eg a website) runs the zk verification algorithm on the proof that is produced by the device to ensure soundness.

(5) Yes, the user can use any compatible implementation to produce the proof. We have open-sourced our implementation and we have a spec for the proof format that others can also reimplement.

>>abhv+hf
Thanks for the reply. So in theory, I could get this MDOC file and store it on my desktop computer, and use an open-source library whose behavior I can verify, to provide the proof to the website via my web browser. Yeah? This sounds good to me.

>>coldpi+7g
No. Using the MDOC requires a signature from a hardware security key in the phone, and a lot of the complexity is how to avoid leaking the private key, which would identify you.

>>Matteo+zg
Well, that's not great. My phone is closed-source and its software is provided by an ad company. I do not trust it to always behave in my interests.

>>coldpi+8h
An alternative would be some secure chip in a credit-card size plastic document, but nobody seems to like that idea. We (Google) don't make these choices.

>>Matteo+ej
Another approach could be for a component in the protocol that I do trust (eg an open source web browser) to serve as an intermediary, providing only the information required to each of the components that I don't trust (wallet, website). The wallet does not need to know who is requesting the proof, right?

>>coldpi+3k
I hear you. The main problem is how to prevent you from giving your document to somebody else, and things have converged on certified smartphone with security key plus biometrics.

>>Matteo+3m
Yeah, Passkeys are doing the same thing, expecting users to just blindly trust American Big Tech companies. It's distressing that no one working on these protocols considers the developers of the software that implements the protocol to be a party in the protocol. What are the wallet provider's interests in this exchange? How can the user be protected from the wallet provider? Seems no one asks these questions :(