Programmable Cryptography (2024)(0xparc.org) |
Programmable Cryptography (2024)(0xparc.org) |
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.
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.
You can do this today.
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 also reads like a junior dev or a student with „universal” having too much value in their own words.
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?
"Fiber-optic cables: Fiber-optic cables enable higher bandwidth phone lines and television—it’s about getting more television channels to more people."
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 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.
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.
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 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.
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.
https://github.com/microsoft/crescent-credentials
But of course the thing would need users in order to attract users.
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.
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.
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.
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.