Programmable Cryptography (2024) • Hacker News Board

Re: Programmable Cryptography (2024)

#11

Post by hunterpayne » Tue, Mar 03, 2026, 12:01 AM UTC

perching_aix wrote: post #3

miohtama wrote: post #2

Zk would perfect for online age verification, but governments do not want to implement it like this. Instead they want id and face collection for mass surveillance, using age verification as an excuse.

For age verification and identity verification both afaik. Sometimes I wonder if what's needed is "just" a more public push for it, but these topics are so hopelessly technical, I think it has no hope to ever reach the mainstream and poll well. And that is ignoring all the other counterarguments against these that compound on top, some of which are culturally sensitive for many.

These topics are political and I seriously doubt these types of solutions are what the politicians are looking for. In fact, they are the exact opposite of what they are looking for because it takes away the excuses they are using and would lay bare what they are actually trying to do. BTW, I'm not suicidal and I bet you aren't either.

Re: Programmable Cryptography (2024)

#12

Post by cyberax » Tue, Mar 03, 2026, 12:06 AM UTC

I've been looking at the field, and I can't really see how most of this is useful. ZKPs and FHE add a lot of complexity to a pretty simple task: verifying the age and/or identity.

These tasks are so simple that you can _almost_ use the existing TLS client certificates for that. Their only drawback is that they're trackable. A simple asymmetric challenge-response system with a nonce easily fixes this:

1. The service provider generates a 128-bit nonce and sends it to me.

2. I use a verification system provided by my government, and it returns a document saying: "The owner is more than 18 years old, the nonce for the request was ......, and this proof is valid for this service name hash". This document is signed by the trusted government certificate.

3. I send this signed document to the service provider.

No need for range proofs and other stuff. I think this flow can even be expressed using OIDC and JWTs!

What am I missing that requires full-blown ZKPs?

Re: Programmable Cryptography (2024)

#13

Post by hinkley » Tue, Mar 03, 2026, 12:08 AM UTC

pullthatupjamie wrote: post #7

miohtama wrote: post #2

Zk would perfect for online age verification, but governments do not want to implement it like this. Instead they want id and face collection for mass surveillance, using age verification as an excuse.

Based on recent revelations with certain "files" and brazen disregard for human life, I find it hard to believe that the "people" in the gov really care about children at all.

They care the way a cheetah cares about gazelles.

Re: Programmable Cryptography (2024)

#14

Post by DonsDiscountGas » Tue, Mar 03, 2026, 12:36 AM UTC

I really liked reading this but I imagine the impact will be a lot less than the author is imagining. Current encryption methods are pretty good to the point where privacy beaches are always social engineering or stolen laptop or something dumb like that

Re: Programmable Cryptography (2024)

#15

Post by tripplyons » Tue, Mar 03, 2026, 12:42 AM UTC

cyberax wrote: post #12

I've been looking at the field, and I can't really see how most of this is useful. ZKPs and FHE add a lot of complexity to a pretty simple task: verifying the age and/or identity. These tasks are so simple that you can _almost_ use the existing TLS client certificates for that. Their only drawback is that they're trackable. A simple asymmetric challenge-response system with a nonce easily fixes this: 1. The service p…

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.

Re: Programmable Cryptography (2024)

#16

Post by tripplyons » Tue, Mar 03, 2026, 12:45 AM UTC

miohtama wrote: post #2

Zk would perfect for online age verification, but governments do not want to implement it like this. Instead they want id and face collection for mass surveillance, using age verification as an excuse.

One problem with private age verification is that because each verification cannot be traced back to a user, it is hard to prevent abuse like credential sharing. Imagine how a single stolen credential can be used by any number of users because the verification step kept the credential private.

Re: Programmable Cryptography (2024)

#17

Post by tripplyons » Tue, Mar 03, 2026, 12:48 AM UTC

As much as I like the ideas, this article looks AI generated. This line with the bullet point, bolded label and colon, em-dash, and the second clause "it's about" all point to AI writing.

"Fiber-optic cables: Fiber-optic cables enable higher bandwidth phone lines and television—it’s about getting more television channels to more people."

Re: Programmable Cryptography (2024)

#18

Post by miki123211 » Tue, Mar 03, 2026, 12:51 AM UTC

miohtama wrote: post #2

Zk would perfect for online age verification, but governments do not want to implement it like this. Instead they want id and face collection for mass surveillance, using age verification as an excuse.

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.

Re: Programmable Cryptography (2024)

#19

Post by cyberax » Tue, Mar 03, 2026, 12:52 AM UTC

tripplyons wrote: post #15

cyberax wrote: post #12

I've been looking at the field, and I can't really see how most of this is useful. ZKPs and FHE add a lot of complexity to a pretty simple task: verifying the age and/or identity. These tasks are so simple that you can _almost_ use the existing TLS client certificates for that. Their only drawback is that they're trackable. A simple asymmetric challenge-response system with a nonce easily fixes this: 1. The service p…

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 they did not tamper with the results of a computation.

What is the exact scenario here?

Re: Programmable Cryptography (2024)

#20

Post by Ar-Curunir » Tue, Mar 03, 2026, 12:56 AM UTC

cyberax wrote: post #12

I've been looking at the field, and I can't really see how most of this is useful. ZKPs and FHE add a lot of complexity to a pretty simple task: verifying the age and/or identity. These tasks are so simple that you can _almost_ use the existing TLS client certificates for that. Their only drawback is that they're trackable. A simple asymmetric challenge-response system with a nonce easily fixes this: 1. The service p…

ZKPs don’t require you to interact with a government service, and don’t need an internet connection at all.