Programmable Cryptography (2024) • Hacker News Board

Re: Programmable Cryptography (2024)

#21

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

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…

Got it.

The scenario I'm describing there is how a service like AWS has the ability to tamper with your code or its output. If instead, each response came with a ZK proof showing that the inputs you provided lead to the outputs it returned, you could efficiently verify that nothing was modified.

Re: Programmable Cryptography (2024)

#22

Post by Retr0id » Tue, Mar 03, 2026, 12:58 AM UTC

tripplyons wrote: post #17

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."

That part in particular is suspect and I wouldn't be surprised if it was AI-assisted, but the article as a whole feels human-written to me.

Re: Programmable Cryptography (2024)

#23

Post by Uptrenda » Tue, Mar 03, 2026, 1:10 AM UTC

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.

Re: Programmable Cryptography (2024)

#24

Post by Uptrenda » Tue, Mar 03, 2026, 1:21 AM UTC

Retr0id wrote: post #5

I agree that we have more capable+flexible cryptographic primitives than ever before, but I don't really buy the "Universal Protocol" thing. For non-cryptographic uses we have "universal protocols" already, JSON being an example. You can adapt just about any format to and from JSON, if you want. But the fact that this is possible has not solved the interop problem, in the general case. Similarly for "Hallucinated Ser…

I think the idea is that if an API (or anything really) is using a flexible cryptographic model then it would be possible to string together any system for use in any cryptographic scheme.

For example: you could write the cryptographic equivalent of "if user deposits $100 into this bank account then allow them to redeem these crypto-currencies"

This would mean making systems broadly compatible. Anyone could envision new use-cases for pre-existing systems and be able to extend them without having to modify the existing system. But the challenge of this is (1) designing a simple, fast cryptographic stack (2) widespread adoption.

Re: Programmable Cryptography (2024)

#25

Post by Retr0id » Tue, Mar 03, 2026, 2:15 AM UTC

Uptrenda wrote: post #24

Retr0id wrote: post #5

I agree that we have more capable+flexible cryptographic primitives than ever before, but I don't really buy the "Universal Protocol" thing. For non-cryptographic uses we have "universal protocols" already, JSON being an example. You can adapt just about any format to and from JSON, if you want. But the fact that this is possible has not solved the interop problem, in the general case. Similarly for "Hallucinated Ser…

I think the idea is that if an API (or anything really) is using a flexible cryptographic model then it would be possible to string together any system for use in any cryptographic scheme. For example: you could write the cryptographic equivalent of "if user deposits $100 into this bank account then allow them to redeem these crypto-currencies" This would mean making systems broadly compatible. Anyone could envision…

> For example: you could write the cryptographic equivalent of "if user deposits $100 into this bank account then allow them to redeem these crypto-currencies"

You can do this today.

Re: Programmable Cryptography (2024)

#26

Post by Uptrenda » Tue, Mar 03, 2026, 2:25 AM UTC

Retr0id wrote: post #25

Uptrenda wrote: post #24

Earlier quoted context omitted.

I think the idea is that if an API (or anything really) is using a flexible cryptographic model then it would be possible to string together any system for use in any cryptographic scheme. For example: you could write the cryptographic equivalent of "if user deposits $100 into this bank account then allow them to redeem these crypto-currencies" This would mean making systems broadly compatible. Anyone could envision…

> For example: you could write the cryptographic equivalent of "if user deposits $100 into this bank account then allow them to redeem these crypto-currencies" You can do this today.

Thanks for letting me know. I also worked on this in 2013.

Re: Programmable Cryptography (2024)

#27

Post by DennisP » Tue, Mar 03, 2026, 2:34 AM UTC

tripplyons wrote: post #16

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.

One method would be to use the same key that you use to hold some cryptocurrency, so if you share then you risk losing a bond.

Of course it's not ideal to make everybody hold crypto just to use online services, but maybe we can approximate that in other ways. Say, have the private data include name/SSN/DOB and maybe a credit card number, require the user to enter that stuff (or have browser do it), prover checks that it's all correct. Combine that with a challenge/response so proofs can't be reused. User can't share credentials without risking identity theft. Downside is more openings for local malware to succeed in identity theft, but maybe that's better than sending full credentials to big juicy central locations.

A third option would be to give everyone a hardware key that's hard to copy, but that would get expensive.

I think the best idea is to just skip age verification and keep the good ol' internet we've enjoyed for decades.

Re: Programmable Cryptography (2024)

#28

Post by cyberax » Tue, Mar 03, 2026, 2:58 AM UTC

Ar-Curunir wrote: post #20

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.

How would this work? What happens if a child picks up my unlocked phone and copies the authentication data to another device?

I guess you can put the proof-generating code inside some kind of a secure enclave? But then it's still not any better than classic asymmetric exchange, except that the government provides you a certificate that signs the private key held inside the TPM.

Or are you thinking about using a ZKP for a biometric proof? But then this still doesn't solve the issue of a malicious user just taking biometric pictures once, and then re-feeding them to the verifier.

I don't think this is solveable without some kind of trusted computing environment, at which point the classic asymmetrical crypto is fine anyway.

Re: Programmable Cryptography (2024)

#29

Post by IAmLiterallyAB » Tue, Mar 03, 2026, 3:32 AM UTC

Citation needed. We don't even know if indistinguishability obfuscation is possible.

Re: Programmable Cryptography (2024)

#30

Post by sali0 » Tue, Mar 03, 2026, 3:59 AM UTC

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.

This was true 3 years ago but not generally the case anymore. There's been significant advancements to move away from trusted setups and the speedups with current methods are quickly approaching viability.