A true giant. His algorithm for Pythagorean addition, which computes sqrt(a^2 + b^2) without taking square roots, is a wonderful gem.
Fun anecdote about early Matlab. In the '80s, while in high school, I "acquired" the source code of an early version of matlab, similar to the one that you linked. An email from Cleve Moler in 1990 asked people not to distribute the code, so I didn't give it to anybody. In the late '90s I visited Cleve Moler at his Mathworks office, and he proudly showed the early Matlab running on DOS, remarking that he only had that binary but had lost the source code. So I gave it to him.
ZKP is integrated in Google Wallet and has been running in production for a few months. We (Google) released the ZKP library as open source last year (this is the library used in production).
Afterwards, folks from ISRG produced an independent implementation
https://github.com/abetterinternet/zk-cred-longfellow with our blessing and occasional help. I don't know if the authors would call it "production ready" yet, but it is at least code complete, fast enough, and interoperable with ours.
Yes. The whole trick is a delicate balance between 1) committing to enough information that uniquely pins down the solution, assuming that one can open all the lock boxes, and 2) not opening too many lock boxes so that the verifier does not learn the solution.
Yes. However, at some point there needs to be some unforgeable piece of hardware that prevents copying the document. I am a big fan of yubikeys and I wish everybody used them, but the reality is that people lose them way more often than they lose their phone.
This post is restricted to the context of the European Union and is intended to be factual.
The EU age verification app is intended to be a pilot to the EU Digital Identity Wallet (EUDIW), which EU law requires to be deployed everywhere in Europe by the end of 2026. (Thus your "worry" is in fact the explicit plan of record.)
The EUDIW will store more attributes than age. Think of it as a digital form of a passport (with name, address, etc.). The exact set of attributes is determined by local laws.
Thus, the DOCUMENT that you obtain is tied to you, and of course the state knows what is in the DOCUMENT since the state creates the document in the first place.
The state does not generate proofs. The phone generates proofs. Given a proof (and only the proof), nobody can associate the proof to the phone or to you.
Now I switch to less factual statements, which are still approximately correct.
Why would you trust the wallet software not to phone home to the state or us (Google)? The EUDIW regulations require that the wallet software be open source. However, states will only issue DOCUMENT to their own certified wallet software---you cannot just take the open source and recompile it, since the state won't issue DOCUMENT to your uncertified wallet. (Maybe your gym will issue a gym membership to your raspberry pi wallet, since it's not a big deal.)
The reason for this strictness is that the EUDIW is intended for official or semi-official uses. For example, you can open a bank account with it, or use it as ID to get a mortgage. The bank must by law accept DOCUMENT, the state guarantees that DOCUMENT is correct, and you get better privacy than handling over a piece of plastic that is then photocopied by who knows whom. This is the tradeoff of the current EU law. It would be inappropriate for this kind of official, passport-like documents to store attributes such as your profession (journalist or whatever), and nobody is talking about it.
Another excellent question. The current answer in the EU seems to be "you need a phone". My preferred answer (despite being one of the Google guys who designed the ZKP mechanism) would be that the government sends you some sort of plastic card with a chip that does not tie you to a phone. Still fighting that battle.
Here is a hopefully simple example of how this ZKP thing may even be possible. Imagine that you give me a Sudoku puzzle. I solve it, and then I want to prove to you that I have solved it without telling you the solution. It sounds impossible, but here is one way to do it.
I compute the solution. I randomly scramble the digits 1-9 and I put the scrambled solution in a 9x9 array of lock boxes on a table. I have the keys to the 81 locks but I am not giving you the key yet. You randomly ask me to open either 1) one random row chosen by you; 2) one random column chosen by you; 3) one random 3x3 block chosen by you; or 4) the cells corresponding to the original puzzle you posed to me. In total you have 28 possibilities, and assume that you choose them with equal probability. You tell me what you want and I open the corresponding lockboxes. You verify that the opened lock boxes are consistent with me knowing a solution, e.g. all numbers in a row are distinct, the 3x3 block consists of distinct numbers, etc. If I am cheating, then at least one of your 28 choices will be inconsistent, and you catch me with probability 1/28, so if we repeat this game 1000 times, and I don't know the solution, you will catch me with probability at least 1-(1/28)^1000 which is effectively 1. However, every time we repeat the game, I pick a different random scrambling of the integers 1-9, so you don't learn anything about the solution.
All of ZKP is a fancy way to 1) encode arbitrary computations in this sort of protocol, and 2) amplify the probability of success via clever error-correction tricks.
The other thing you need to know is that the protocol I described requires interaction (I lock the boxes and you tell me which ones to open), but there is a way to remove the interaction. Observe that in the Sudoku game above, all you are doing is flipping random coins and sending them to me. Of course you cannot let me pick the random coins, but if we agree that the random coins are just the SHA256 hash of what I told you, or something else similarly unpredictable, then you will be convinced of the proof even if the "coins" are something that I compute myself by using SHA256. This is called the "Fiat-Shamir transformation".
How do we implement the lock boxes? I tell you SHA256(NONCE, VALUE) where the NONCE is chosen by me. Given the hash you cannot compute VALUE. To open the lock box, I tell you NONCE and VALUE, which you believe under the assumption that I cannot find a collision in SHA256.
Excellent question. More generally, what prevents me from copying the credential and giving it to somebody else?
The currently favored approach works like this. The DOCUMENT contains a device public key DPK. The corresponding secret key is stored in some secure hardware on the phone, designed so that I (or malware or whatever) cannot extract the secret key from the secure hardware. Think of it as a yubikey or something, but embedded in the phone. Every presentation flow will demand that the secure element produce a signature of a random challenge from the RP under the secret key of the secure hardware. In the ZKP presentation, the ZKP prover produces a proof that this signature verifies correctly, without disclosing the secret key of the secure hardware.
In your example, the parent could give the phone to the kid. However, in current incarnations, the secure hardware refuses to generate a signature unless unlocked by some kind of biometric identification, e.g. fingerprint. The fingerprint never leaves the secure hardware.
How does the issuer (e.g. the republic of France) know that DOCUMENT is bound to a given fingerprint? This is still under discussion, but as a first bid, a French citizen goes to city hall with his phone and obtains DOCUMENT after producing a fingerprint on the citizen's phone (as opposed to a device belonging to the republic of France). You can imagine other mechanisms based on physical tokens (yubikeys or embedded chips in credit cards, or whatever). Other proposals involve taking pictures compared against a picture stored in DOCUMENT. As always, one needs to be clear about the threat model.
In all these proposals the biometric identification unlocks the secure hardware into signing a nonce. The biometrics themselves are not part of the proof and are not sent to the relying party or to the issuer.
This is, of course, very technical, but here is how it works at a high level.
In the non-ZKP presentation, the "holder" (phone) sends the credential to the relying party (website), and the RP executes some verification algorithm. In the ZK presentation, the holder executes the verification algorithm and sends to the RP a proof that the algorithm was executed correctly.
The "proof" has this magical property that it reveals nothing other than the check passed. (You will have to take on faith that such proofs exist.) In particular, if the check was the predicate "I have a signature by ISSUER on HASH, and SHA256(DOCUMENT)==HASH, and DOCUMENT["age_gt_18"]=TRUE", anybody looking at the proof cannot infer ISSUER, HASH, DOCUMENT, or HASH, or nothing else really. "Cannot infer" means that the proof is some random object and all HASH, DOCUMENT, ISSUER, etc. that satisfy the predicate are equally likely, assuming that the randomness used in the proof is private to the holder. Moreover, a generating a proof uses fresh randomness each time, so given two proofs of the same statement, you still cannot tell whether they come from the same ISSUER, HASH, DOCUMENT, ...
I don't dispute your general sentiment that the ZK terminology is abused. However, at least one serious attempt exists to deploy a real ZKP system.
Specifically, our system [1] is available as open source [2] and work is underway to implement it in the EU age verification app [3]. I understand that this thread is about the UK and not the EU, and I make no claims about the UK. The system is not theory, but it is already shipping in Google Wallet [4] and in the Open Wallet Foundation multipaz system [5].
Great question. The current thinking, at least in high level-of-assurance situations, is this. The identity document is only usable in cooperation with a hardware security element. The relying party picks a random nonce and sends it to the device. The device signs the nonce using the SE, and either sends the signature back to the relying party (in the non-ZKP case), or produces a ZKP that the signature is correct. The SE requires some kind of biometric authentication to work, e.g. fingerprint. So you cannot set up a bot that mints attestations. (All this has nothing to do with ZKP and would work the same way without ZKP.)
In general there is a tradeoff between security and privacy, and different use cases will need to choose where they want to be on this spectrum. Our ZKP library at least makes the privacy end possible.
You got it. There are a few nuisances, e.g. the "theorem statement" must be hashed as well so that proving that name=Mickey has a different oracle than proving that name=Goofy, but your basic understanding is correct.
No. ZK has a technical definition I don't want to get into, but note that the described system is deterministic and it always produces the same proof for Alice on a given day, and the proof for a later day can be derived from the proof for an earlier day. So two proofs can be linked back to Alice, and thus the system is not ZK. You need some kind of randomness for ZK.
As the Google guy who did the system, I really don't want to engage in this discussion.
I'll just say that the b-systems solve a different problem, and for the problem solved by our system there is currently no other solution available.
We spoke with Ying Tong and her colleagues from the Ethereum foundation. They have a project investigating which ZK technology would be best for digital credentials, and they have ran a few benchmarks at https://hackmd.io/@clientsideproving/zkIDBenchmarks For reference, our implementation runs the benchmark in about 200ms on the same hardware. The ETHF folks have had access to our code for a while and they agree with this result, but they decided not to publish numbers until the Google code was open-sourced for all. Our system is thus about 10x faster than the closest contender for this problem.
I don't want to make any general claims about who is better than whom. Our system is designed for our problem, and it's not a surprise that another system designed for another problem would perform worse on our problem. We are big fans of the Binius system of Diamond and Posen at Irreducible, and there is a chance that Binius may eventually work better than our stuff. That's however not the case today.
You also have to be careful about which hardware to use. Our implementation is single-threaded no GPU because it has to run on all phones everywhere in the world. Whether or not one can do better on a high-end GPU is irrelevant to us.
Either way, "stale" is not a word I would use. The word I would use is "works today".
The government gives a signed document to natural persons, and the ZK system proves that the document is signed by the government. Bots don't have passports or driver's licenses.
How does the government guarantee that the natural person is such? Various jurisdictions will decide what's good enough, but as a strawman proposal, you go in person to city hall once and upload a document to your phone.
Fun anecdote about early Matlab. In the '80s, while in high school, I "acquired" the source code of an early version of matlab, similar to the one that you linked. An email from Cleve Moler in 1990 asked people not to distribute the code, so I didn't give it to anybody. In the late '90s I visited Cleve Moler at his Mathworks office, and he proudly showed the early Matlab running on DOS, remarking that he only had that binary but had lost the source code. So I gave it to him.