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 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.
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.
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."
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
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
"Fiber-optic cables: Fiber-optic cables enable higher bandwidth phone lines and television—it’s about getting more television channels to more people."
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.
https://github.com/microsoft/crescent-credentials
But of course the thing would need users in order to attract users.
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?
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 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.