by cyberax 9 hours ago
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?
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...
> 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.
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?
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.
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.