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

Programmable Cryptography (2024)

0xparc.org

Post reply on HN
Print view View original

41–47 of 47 posts

Re: Programmable Cryptography (2024)

#41

Post by ozim »

tern wrote: post #32
Uptrenda wrote: post #23

Most of the crypto in the OP requires trusted setup phases and is too slow to use for any kind of general-purpose computation. It's the reason why most cryptographic protocols consist of simpler schemes and don't try to do everything. This article is click bait though. Feel like OP just stumbled upon what people have been doing for the past 5 years and wrote this half-baked article on it.

0xparc is a research lab. They may be wrong or mislead, but they work on this stuff every day—it's not some guy stumbling across something.

If they are research labs then this article feels like was written by junior researcher they just hired and he is so pumped.

But this stuff is not going to replace current state of things as article claims.

Re: Programmable Cryptography (2024)

#44

Post by miki123211 »

ulrikrasmussen wrote: post #38
miki123211 wrote: post #18

Earlier quoted context omitted.

Europe is rolling out ZKP afaik. The actual problem with ZKP is that you need a way to prevent generating thousands or millions of assertions from one ID and distributing them to whoever wants one, in a way which is undetectable and unstoppable by the government, and the only way to do that is with Google Play Integrity Protection and such.

Sort of, but not really. They have a design document for how ZKP-based age verification would be implemented in the white-label prototype app, but it is my understanding that the first implementation to be rolled out in the early adopter countries like mine (Denmark) will be based on "trust me, bro" central verifiers who promise not to do logging, with ZKP mentioned as a possible future alternative. Until I see the r…

> This could be achieved using a USB dongle.

What stops one from selling access to that USB dongle over the internet, anonymously doing thousands of verifications per second, cardsharing[1] style?

With Google Play Integrity Protection, each such verification needs a human physically clicking buttons on the device, which makes things much harder.

[1] https://en.wikipedia.org/wiki/Card_sharing

Re: Programmable Cryptography (2024)

#45

Post by ulrikrasmussen »

miki123211 wrote: post #44
ulrikrasmussen wrote: post #38

Earlier quoted context omitted.

Sort of, but not really. They have a design document for how ZKP-based age verification would be implemented in the white-label prototype app, but it is my understanding that the first implementation to be rolled out in the early adopter countries like mine (Denmark) will be based on "trust me, bro" central verifiers who promise not to do logging, with ZKP mentioned as a possible future alternative. Until I see the r…

> This could be achieved using a USB dongle. What stops one from selling access to that USB dongle over the internet, anonymously doing thousands of verifications per second, cardsharing[1] style? With Google Play Integrity Protection, each such verification needs a human physically clicking buttons on the device, which makes things much harder. [1] https://en.wikipedia.org/wiki/Card_sharing

Built-in rate limiting perhaps? What you describe is also just rate limiting, and buttons/swipes can always be faked, also on a smartphone using mechanized fingers. What do you think Play Integrity adds that cannot be done on a USB dongle?

Re: Programmable Cryptography (2024)

#46

Post by j2kun »

cyberax wrote: post #34
j2kun wrote: post #33

Earlier quoted context omitted.

How would you prove to the government in step 2 that you are the person whose age they're certifying? This also seems like a lot of effort to maintain uptime and security of a service like this as scale, when errors would potentially keep people locked out of essential services. A system that requires a one-time download of a user-specific secret key, which can then be used to interact with the service provider direc…

> How would you prove to the government in step 2 that you are the person whose age they're certifying? How would you prove to the black box ZKP that you are the phone owner? Same problem. An interpretive dance before the camera, singing the national anthem, scanning the passport, etc. Doesn't really change anything. > This also seems like a lot of effort to maintain uptime and security of a service like this as scal…

> How would you prove to the black box ZKP that you are the phone owner?

My point was that your described flow was just shifting the burden of identity verification from one service to another. I think the ZKP solution has the benefit of the government not having to coordinate with other services. They can ship one set of cryptographic material to your device (with a single time when you have to do your annoying passport scan) and then you can do age verification with any service indefinitely. Heck, with a range query you can get that material when you're 16 and you're issued an ID and use it for age verification checks at 16, 18, 21, 25, whatever. I think there's a lot to be said for flexibility of the application here.

Re: Programmable Cryptography (2024)

#47

Post by saltpath »

cyberax wrote: post #19
tripplyons wrote: post #15

Earlier quoted context omitted.

To answer your question, ZKPs can enable the verification step to be done privately in your example. Another use case could be allowing cloud computing hosts to prove that they did not tamper with the results of a computation.

In this case, the government service doesn't get to know anything about the service (it only gets to see the salted hash of the service name)? And the service doesn't get to know anything about me, except for the "age certificate". You can add more layers there, if needed for non-repudiation, all within the bounds of classic asymmetric crypto. > Another use case could be allowing cloud computing hosts to prove that t…

The concrete scenario is AI agent execution. Agent calls a third-party API at 3am — you have your logs, they have theirs, and if there's a dispute you're comparing two mutable records. Sealing both the request hash and response hash with an RFC 3161 timestamp before the agent proceeds gives you a neutral third-party witness. Not zero-knowledge — content is visible — but for audit and dispute resolution it covers 90% of real cases and is deployable today without ZKP overhead.
Post reply on HN