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
The specifics depend on local regulations, but roughy speaking: the government gives you a document in a standard format (eg MDOC). Your phone stores the document, with cooperation from a secure element that binds the document to the phone. The website you visit verifies the proof. The government gives documents to whatever wallet they want, which may be a special government wallet. They may or may not give the document to Google Wallet.

>>Matteo+We
Thank you.

> Your phone stores the document, with cooperation from a secure element that binds the document to the phone. The website you visit verifies the proof.

So it does require a "blessed" implementation, and I have to trust Google or Apple to handle my data? I cannot own the document myself and use an open-source client that I trust to provide the proof?

>>coldpi+Ef
It depends on local regulations. As far as I can tell Europe will require some sort of blessing of the wallet. To be clear, governments will develop their own apps and it's not clear that Google will be blessed. We (Google) are giving them the code pro bono to improve privacy.

>>Matteo+fg
Hmm. This introduces a third party to the protocol, right? Specifically the developer of the wallet. So we now have three parties: the user, the wallet developer, and the relying party. Does this zk protocol protect the user's privacy from the wallet developer as well as the relying party?

In other words, does the protocol give the wallet access to information about the relying party? For example, could this wallet that I don't control tell its owner, or the government, that I am using it to access a certain website?

>>coldpi+Sg
Yes, a malicious wallet could leak your information. This is why some governments will insist on using only blessed wallets. However, wallet+zk is strictly better than sending the plaintext MDOC to the relying party. There are no solutions in this space, only tradeoffs, and elected representatives have picked one tradeoff.

>>Matteo+Hi
That's too bad :( I wish the protocol had been designed with that in mind. Requiring users to trust proprietary software from Google & Apple to be in complete control over their digital identities is a pretty crummy direction to go in.

>>coldpi+Ej
See https://github.com/eu-digital-identity-wallet/eudi-doc-archi... for a reference to the nuances on all these topics, at least in the context of the European Union. Other locales have different problems and different solutions.

If you think you have a better idea shoot me an email.

>>Matteo+R61
The document states:

> Controlled by users: The EU Digital Identity Wallets will enable people to choose and keep track of their identity, data and certificates which they share with third parties. Anything which is not necessary to share will not be shared.

I think where the ZKP stuff being discussed here fails to meet this criteria is the wallet provider is also a third (non-user) party. You stated elsewhere that a malicious wallet could leak data about a transaction: that's exactly the vulnerability that is not being accounted for by this protocol.

> If you think you have a better idea shoot me an email.

Sure, will do. It does seem to me like a solvable problem. I think this kind of tech is really important and I'd love to see this hole get closed so I can feel better about supporting it.

>>coldpi+TD1
Update: After some email discussion with Matteo, it looks like my fears are unfounded. The EU regulations seem to require wallets to be open source[1]. Assuming that wallets do not need to pass any sensitive transaction data down to the OS libraries, then it should be possible for users to verify the behavior of their wallet software by examining the source and possibly even by building & deploying it themselves.

[1] See section 33 here https://www.european-digital-identity-regulation.com/Preambl...