Programmable Cryptography (2024)(0xparc.org)
0xparc.org
Programmable Cryptography (2024)
https://0xparc.org/writings/programmable-cryptography-1
46 comments
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.
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.
I do not give a * about programmable cryptography, because it is not something useful for individual users or for small/medium businesses.
It is something that big companies hope to be able to use for providing services to customers that will move all their computing needs to clouds owned by others, instead of owning their computers.
The cryptographic applications that are useful for individual users and for small/medium businesses remain the traditional ones, e.g. data encryption, data authentication, random number generation, strong one-way hash functions, password hashing schemes.
None of the algorithms suitable for programmable cryptography can ever approach the efficiency of the classic cryptographic algorithms, simply because the requirements for the classic algorithms are much weaker.
Thus, no matter how universal an algorithm for programmable cryptography might be, it will not be an acceptable substitute for any of the classic algorithms, whenever the additional requirements for programmable cryptography are not necessary.
It is something that big companies hope to be able to use for providing services to customers that will move all their computing needs to clouds owned by others, instead of owning their computers.
The cryptographic applications that are useful for individual users and for small/medium businesses remain the traditional ones, e.g. data encryption, data authentication, random number generation, strong one-way hash functions, password hashing schemes.
None of the algorithms suitable for programmable cryptography can ever approach the efficiency of the classic cryptographic algorithms, simply because the requirements for the classic algorithms are much weaker.
Thus, no matter how universal an algorithm for programmable cryptography might be, it will not be an acceptable substitute for any of the classic algorithms, whenever the additional requirements for programmable cryptography are not necessary.
The article reads exactly like written by a person who is much into the topic imagining use cases that are not there.
It also reads like a junior dev or a student with „universal” having too much value in their own words.
It also reads like a junior dev or a student with „universal” having too much value in their own words.
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
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?
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?
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 directly, would be much more scalable...
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 directly, would be much more scalable...
> 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 scale, when errors would potentially keep people locked out of essential services.
This is also trivially solveable with classic crypto. Just pre-generate a few (hundred) tokens for each user. The user just needs to generate a bunch of one-time private/public keys and get the "user is at least 18" certificates for each of the public keys. Then the user can just use them one by one as needed.
Apple Pay works this way, btw. That's why you can make payments with an Apple Watch while it's completely offline.
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 scale, when errors would potentially keep people locked out of essential services.
This is also trivially solveable with classic crypto. Just pre-generate a few (hundred) tokens for each user. The user just needs to generate a bunch of one-time private/public keys and get the "user is at least 18" certificates for each of the public keys. Then the user can just use them one by one as needed.
Apple Pay works this way, btw. That's why you can make payments with an Apple Watch while it's completely offline.
> 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.
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.
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.
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.
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?
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?
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.
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.
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.
Homomorphic encryption and similar techniques in this paper are just getting going. They are impressive technologies. However, they often take 100x the compute of "regular" systems with encrypted networking. This is probably the main blocker for these types of technologies. Until and unless insurance companies mandate these technologies because they are tired of paying out for their customers getting hacked, they probably won't be deployed. Probably for the best. Most devs can barely make code without advanced math and encrypted data work, let alone these types of advanced platforms.
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.
Google is rolling out ZKP for age verification with state-issued digital IDs. See https://www.eff.org/deeplinks/2025/07/zero-knowledge-proofs-... for context
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.
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 requirement of ZKP or equivalent provable zero-trust privacy guarantees in the law, I consider the promise of ZKP as a distraction (lie) to shut down the harshest criticism.
Google Play Integrity is not a requirement, but governments think it is. All you need to avoid trivial duplication of certificates is that keys are bound to a device which is also able to perform the primitive cryptographic operations needed to construct a ZKP proof. This could be achieved using a USB dongle. Still proprietary technology, but the scope of what needs to be locked down is much, much smaller than with a solution like Play Integrity.
Google Play Integrity is not a requirement, but governments think it is. All you need to avoid trivial duplication of certificates is that keys are bound to a device which is also able to perform the primitive cryptographic operations needed to construct a ZKP proof. This could be achieved using a USB dongle. Still proprietary technology, but the scope of what needs to be locked down is much, much smaller than with a solution like Play Integrity.
> 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
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?
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.
I saw a presentation about this 6 months ago, it looked promising for age verification for example, it's even an already done system, not a research article.
https://github.com/microsoft/crescent-credentials
But of course the thing would need users in order to attract users.
https://github.com/microsoft/crescent-credentials
But of course the thing would need users in order to attract users.
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.
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.
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.
I assume they are solving this with secure enclaves creating one-time signatures.
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.
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.
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."
"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.
I know I'm just adding to the noise here, but it seems like half the time I look at comments on posts (anywhere) I see a claim like this. I think you're probably just trying to warn people so they don't waste their time, but for me this type of comment is not helpful at all.
Thanks for the PSA. Sounds like some cool new developments I want to learn about.
[deleted]
But won't this make the Palantir AI Overlord angery?
Citation needed. We don't even know if indistinguishability obfuscation is possible.
This changed in 2020! Indistinguishability Obfuscation from Well-Founded Assumptions: https://eprint.iacr.org/2020/1003.pdf
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 Servers". Even if you trust all nodes (and don't need cryptography), distributed computing is still kinda hard, and we have to write programs in particular ways to make them efficiently distributable. I'm sure this can work really well for some problem domains, but it's a subset.