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

Opening up ‘Zero-Knowledge Proof’ technology

blog.google

Post reply on HN
Print view View original

191–200 of 217 posts

Re: Opening up ‘Zero-Knowledge Proof’ technology

#191

Post by piracyrules »

MatteoFrigo wrote: post #24
mystifyingpoi wrote: post #20

Earlier quoted context omitted.

Well, you don't have another solution. That doesn't immediately mean that the one presented in the post is the correct one. Far from it.

The post does not present a solution to that problem. Governments around the world, especially in Europe, have legislated the solution, and the solution they have picked is a privacy nightmare. This post solves the privacy problem, which is strictly better than the status quo. We (Google) do not decide what should or should not be regulated.

[dead]

Re: Opening up ‘Zero-Knowledge Proof’ technology

#192

Post by hobofan »

MatteoFrigo wrote: post #176
tzs wrote: post #142

Earlier quoted context omitted.

Am I correctly understanding that I'd get the credential from say my state DMV once, and then later whenever I want to prove my age to a website the proof protocol is just between that website and my device? The DMV gets no information about what websites I use the DMV credential with and they get no information about when I use the credential even if the website and the DMV decide to cooperate? All they would be abl…

You are correct. The property that the colluding website and DMV still cannot identify you is called "unlinkability" and as far as I can tell cannot be achieved without zero-knowledge proofs. See https://github.com/user-attachments/files/15904122/cryptogra... for a discussion on this issue. However, the timing attack resurfaces once you allow the DMV to revoke credentials. Exactly how the revocation is done matters.…

One part that I don't understand yet: How does the system ensure "sybil resistance"? (not sure if that's the right term in that context)

By providing both attestation of individual attributes combined with "unlikability", how would even a single verifying party ensure that different attestations don't come from the same identity?

E.g. In the case of age attestation a single willing dissenting identity could set up a system to mint attestations for anyone without it being traceable back to them, right? Similar to how a single of-age person could purchase beer for all their under age friends (+ without any feat of repercussions.

Re: Opening up ‘Zero-Knowledge Proof’ technology

#193

Post by VMtest »

csomar wrote: post #177
csense wrote: post #128

How do you defend against someone who: - Buys or borrows a laptop / phone / whatever from somebody with an authorized private key - Downloads an authorized private key file from a sketchy forum (maybe hacked from an unwilling target, maybe willingly shared by a free-speech advocate) - Uses a VPN over HTTPS to visit websites in countries where age checks aren't legally mandated (and non-compliance is implicitly or exp…

You do not. These measures are targeted against law-abiding and productive citizens to control them further. The other ones (the top 0.1% or the bottom 20%) are uncontrollable anyway. In the future, you'll need a signed certificate with your PII/KYC to access the internet and get an IP address. China is already on the way there and the west is warming up to this approach.

is it possible to lend your device to your IT hacker cousin?

Re: Opening up ‘Zero-Knowledge Proof’ technology

#194

Post by MatteoFrigo »

hobofan wrote: post #192
MatteoFrigo wrote: post #176

Earlier quoted context omitted.

You are correct. The property that the colluding website and DMV still cannot identify you is called "unlinkability" and as far as I can tell cannot be achieved without zero-knowledge proofs. See https://github.com/user-attachments/files/15904122/cryptogra... for a discussion on this issue. However, the timing attack resurfaces once you allow the DMV to revoke credentials. Exactly how the revocation is done matters.…

One part that I don't understand yet: How does the system ensure "sybil resistance"? (not sure if that's the right term in that context) By providing both attestation of individual attributes combined with "unlikability", how would even a single verifying party ensure that different attestations don't come from the same identity? E.g. In the case of age attestation a single willing dissenting identity could set up a…

Great question. The current thinking, at least in high level-of-assurance situations, is this. The identity document is only usable in cooperation with a hardware security element. The relying party picks a random nonce and sends it to the device. The device signs the nonce using the SE, and either sends the signature back to the relying party (in the non-ZKP case), or produces a ZKP that the signature is correct. The SE requires some kind of biometric authentication to work, e.g. fingerprint. So you cannot set up a bot that mints attestations. (All this has nothing to do with ZKP and would work the same way without ZKP.)

In general there is a tradeoff between security and privacy, and different use cases will need to choose where they want to be on this spectrum. Our ZKP library at least makes the privacy end possible.

Re: Opening up ‘Zero-Knowledge Proof’ technology

#195

Post by hobofan »

MatteoFrigo wrote: post #194
hobofan wrote: post #192

Earlier quoted context omitted.

One part that I don't understand yet: How does the system ensure "sybil resistance"? (not sure if that's the right term in that context) By providing both attestation of individual attributes combined with "unlikability", how would even a single verifying party ensure that different attestations don't come from the same identity? E.g. In the case of age attestation a single willing dissenting identity could set up a…

Great question. The current thinking, at least in high level-of-assurance situations, is this. The identity document is only usable in cooperation with a hardware security element. The relying party picks a random nonce and sends it to the device. The device signs the nonce using the SE, and either sends the signature back to the relying party (in the non-ZKP case), or produces a ZKP that the signature is correct. Th…

Okay, yeah that's what I assumed.

That seems a bit like a game of whack-a-mole where as long as the forging side is willing to go further and further into out-of-hardware emulation (e.g. prosthetic finger on a robot hand to trick fingerprint scanners), they are bound to win. Biometrics don't feel like they hold up much if you can have collusion without fear of accountability.

> Our ZKP library at least makes the privacy end possible.

Yes, that's also one of the main things that make me excited about it. I've been following the space for quite some time now, and I'm happy that it becomes more tractable for standard cryptographic primitives and thus a lot more use-cases.

Thanks for your contributions to the space and being so responsive in this thread!

Re: Opening up ‘Zero-Knowledge Proof’ technology

#198

Post by coldpie »

endgame wrote: post #141
tzs wrote: post #139

Earlier quoted context omitted.

You can have a password manage your passkey private data. Several now have passkey support, including some that work on Linux such as 1Password and Bitwarden letting you use passkeys even if your household is completely Apple-free, Microsoft-free, and Google-free.

https://github.com/keepassxreboot/keepassxc/issues/10407#iss... > To be very honest here, you risk having KeePassXC blocked by relying parties Even if the bigtechs don't "officially" make the passkey standards require bigtech involvement, it seems very likely to me that conservative businesses like banks will only accept bigtech implementations. And then you're sunk. Similarly, look at how OpenID turned into "Sign in…

> Even if the bigtechs don't "officially" make the passkey standards require bigtech involvement, it seems very likely to me that conservative businesses like banks will only accept bigtech implementations.

Indeed. It's not a theoretical concern, either. The spec authors themselves actually maintain a "naughty client list": https://passkeys.dev/docs/reference/known-issues/

> This ZKP+hardware secure element stuff seems even worse, because how are you going to make it work on old hardware, or with free software, or with open devices?

I don't love it, but I actually do see an argument that this kind of proof-of-property stuff really does belong in a secure area, backed by approved software. It is making government-backed, legal claims about a person or entity. Unlike with Passkeys, it's not really "your" data, rather it's a way for the government to provide legally-backed information to someone, without the government actually having to be in the loop. I'd probably argue the solution to the big-tech dependency here is the government should be required to provide its own, verifiable solution (such as a physical ID card with open software) for users who do not want to trust big-tech.

Where the ZKP spec authors goofed was in not considering the wallet provider to be a party in the transaction. That third party may have interests that are not aligned with the user's.

Re: Opening up ‘Zero-Knowledge Proof’ technology

#199

Post by coldpie »

MatteoFrigo wrote: post #182
coldpie wrote: post #66

Earlier quoted context omitted.

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.

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.

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.

Re: Opening up ‘Zero-Knowledge Proof’ technology

#200

Post by coldpie »

MatteoFrigo wrote: post #176
tzs wrote: post #142

Earlier quoted context omitted.

Am I correctly understanding that I'd get the credential from say my state DMV once, and then later whenever I want to prove my age to a website the proof protocol is just between that website and my device? The DMV gets no information about what websites I use the DMV credential with and they get no information about when I use the credential even if the website and the DMV decide to cooperate? All they would be abl…

You are correct. The property that the colluding website and DMV still cannot identify you is called "unlinkability" and as far as I can tell cannot be achieved without zero-knowledge proofs. See https://github.com/user-attachments/files/15904122/cryptogra... for a discussion on this issue. However, the timing attack resurfaces once you allow the DMV to revoke credentials. Exactly how the revocation is done matters.…

>> The DMV gets no information about what websites I use the DMV credential with and they get no information about when I use the credential even if the website and the DMV decide to cooperate?

> You are correct. The property that the colluding website and DMV still cannot identify you is called "unlinkability" and as far as I can tell cannot be achieved without zero-knowledge proofs.

Well, no. This is true only if you trust the unverifiable wallet software on your phone, which was provided by a for-profit, American big tech advertising company. In this protocol, the wallet may secretly leak the transaction details back to the DMV or whoever else they wish[1].

[1] "Yes, a malicious wallet could leak your information." https://news.ycombinator.com/item?id=44458549

Post reply on HN