No, you don't look up the token. You check a zero-knowledge proof.

The way this works is, there's a function with both public and private inputs, and an output. You can send me public inputs, and I can pass those plus my private inputs into the function, and give you the function output, along with a proof that the output is correct given your inputs.

So in this case, the government has a public key, which it uses to sign your credentials, consisting of your birthdate and a unique identifier.

The website sends you a large random number.

The public inputs are the government public key, the random number, today's date, and maybe a revocation list of identifiers.

The private data is my unique identifier and birth date.

The function returns true if my calculated age > 18, the government's signature of my data is valid, my private identifier is not on the public revocation list, and (to avoid replays) that the hash of your random number is not zero.

I send you back the generated proof, which is just a 256-bit number. You can check that the proof is correct without looking anything up. The proof does not give you any way to reconstruct my private data. It is only associated with the random number you gave me, and the public data everyone knows.

To keep the revocation list from growing forever, we could also make credentials expire after some period of time. Add an issue date to the private data, and we can add an expiration check to the function. Client software can automatically get a new credential if the old one is valid, expiration is just to allow us to delete old identifiers from the revocation list.

A hole in the above scheme is that government could try redoing proofs for a given random number, using all the current identifiers. To prevent this, the user passes in another random number as private data, and the function checks that that doesn't hash to zero either. User can change that random number every time, its only function is to change the generated proof to something the government can't replicate.

So now you drop the other demand. If someone is caught faking credentials, remotely, what do you do? Because if you don't identify whose credentials they are proxying (just send the random number to an actual adult's phone and return the "generated proof") will mean everyone bypasses the security.

Which means your effectiveness is nothing if you have actual anonymity, because you can't catch who proxies. So you have a critical problem one way ... AND the other way.

So as I've mentioned elsewhere, that depends on how much of a stickler we insist on being.

If we're ok with "mostly fix it but if a few teenagers get through it's not the end of the world," then there are a few simple measures that could help a lot:

- Keep an eye out for any credentials posted online, and put those on the revocation list.

- Keep expirations short (and auto-renew).

- Keep the credentials in phone secure enclaves and USB hardware "wallets."

- Consider including private information like name/dob/ssn or credit card number in the credentials, so users have good reason not to share. (We could consider making USB hardware optional if we do this.)

Given secure hardware it might be possible to prevent proxies entirely, the same way we prevent other MITM attacks.

Failing that, we could start by making it illegal to run proxies. Installing a proxy on your phone would mean getting an app from a criminal, not checked by an app store, and giving the criminal a way to pay you. I wouldn't expect this to happen all that much. Installing on a computer, using a VPN, taking payment via anonymous cryptocurrency, sure, if the VPN isn't compromised. But I wouldn't expect all that many people to do all this. Generating the proofs is a bit expensive so you wouldn't have huge capacity per person.

Criminals in foreign countries could do it with stolen credentials, and they'd only need one. But our teenagers would have to pay a foreign company for the service, and for porn at least they could just pay a foreign porn site directly. For phones, the teenager would have to install an app to use the proxy, which is another dodgy untrusted app (on android, and not possible at all on iphone), and it's easier for parents to check what apps are on the phone than to check what websites the kid visits. And social media gets less appealing if a lot of your friends aren't on it.

If we want to lock things down harder we could go with criminal penalties for intentionally sharing your credentials, which I do not support, but would still be better than pervasive surveillance of everything we do online.

Requiring everyone to have secure cryptographic hardware would in one sense be annoying, but less so if we use it for other things too.

> So as I've mentioned elsewhere, that depends on how much of a stickler we insist on being.

This is an argument about a crypto algorithm. If you somehow fix the mathematical problems I'll start checking how it behaves under ddos conditions and you best have a good answer. And I'm an amateur. With your attitude, I'd strongly advise against mailing the openbsd lists.

> Criminals in foreign countries could do it with stolen credentials, and they'd only need one. But our teenagers would have to pay a foreign company for the service, and ...

Indeed. You see the problem.

So now you're moving to making the system insecure (and obviously insecure). That was also not acceptable ...

You can have the system be:

* anonymous, but guaranteed to be insecure

* secure (or at least, as long as you get to use the police to go after "criminals"), but not anonymous

> If we want to lock things down harder we could go with criminal penalties for intentionally sharing your credentials, which I do not support, but would still be better than pervasive surveillance of everything we do online.

The only way to do this would be regular and surprise offline inspections of every device. Aside from being extremely impractical to do, it would also be much worse than online surveillance.

I'm not sure what my "attitude" is but I'm being pragmatic. This is not a binary situation, where it's either perfectly secure or useless. If our society is not willing to do what you and I prefer and leave things entirely open, then perhaps it's good enough to make things more difficult for teens to access, rather than accept pervasive surveillance to make it impossible. If people think it will improve society enough if most teens stay off certain sites, then we can do that and maintain anonymity.

I'll note that you skipped over my point that even with a "perfect" system, teens could still pay foreign porn sites etc directly. And that using a proxy would require installing an untrusted app on the phone, which would be relatively easy for parents to monitor and could be prevented entirely on iPhone. And that we can probably fix proxies with secure hardware anyway.

And no, the police idea that I do not support would not require surprise inspections. It just requires careless teenagers to occasionally reveal their identities online, with enough evidence to convince a judge to issue a warrant. It's dumb to make a federal case out of this, but not as dumb as losing all privacy and anonymity online. And, as I mentioned, this is not something actually required to make the idea workable.

I'm not going to keep repeating myself so I think I'm done here unless you have a point I haven't addressed in previous comments.

Thinking about this further: it looks to me like we can fully prevent proxy attacks if we assume secure hardware handling the cryptography on the client side, and send an encrypted sessionid to the client after verification.

The reason is that:

- We send a random number from the server at the beginning which is associated with the session, so a proxy can't just replay the encrypted proof.

- We pass the server key into the proof, so a MITM attack would give the wrong server key to the client, and the real server wouldn't be able to verify the proof.

Then with each request the secure hardware can provide encrypt(sessionid, nonce).

This would not be anonymous and would allow website owners to uniquely identify the hardware used to authenticate.

So, once again: you can have a secure system XOR you can have anonimity.

Well it would be anonymous because the client public key is randomly generated every time, and the zk proof doesn't include the identifier.

If the public key signature of that random public key can't be uniquely identified as belonging to a particular device (allowing for a device to be revocated), then all it takes is 1 compromised phone to make the system insecure ...

(to say nothing of the fact that because of EU regulations the secure element is not app accessible on either apple or android. So you won't just be dependent on Google/Apple, you'll be using their APIs (which report every authentication to them) every single time an ID is needed)

If you can identify the device even just with a unique identifier, it's not anonymous.

I already described in detail how to do revocations despite the website not being able to identify the device.

The whole point of zero knowledge is that you can prove you have possession of information with particular properties, without having to actually reveal the information. I explained how to use this in my first reply to you. You're just repeating your claim without bothering to understand the first thing about the technology I'm talking about.

Age verification itself is a change to regulations. Obviously to make a private system, our regulations would have to change in a way that allows that, instead of in a way that destroys all privacy as they're attempting now.

And you again switch to dropping the other requirement. You would never be able to find the credentials to revoke to restore security if there is true anonymity.

The only requirement I dropped is absolute perfect security, which no system will have and certainly not the nonsense "show your ID to the camera" stuff they're actually using.

I showed how to eliminate proxies, and without that, the only hole is the credentials themselves getting passed around. If that happens at a small scale between people who know each other, it's a minor problem. If a credential gets posted online and widely shared, it's easy to notice and revoke it.

No you go in a circle. My claim is: the system can be secure XOR the system can be anonymous.

And you go in circles. One post, you drop anonymity, I point out that leads to security problem, next post you drop security and ... you get back anonymity, I point that out and, guess where we go from there? I mean your list of replies is becoming an ever stronger argument for what you're denying.

At this point I can only ask that you actually read my above comments more closely and think about them. I have exactly the level of security I described in my last comment, with complete anonymity, all with one design. If your claim is that this level of security is insufficient, my answer is that it's more secure than anything actually being used for age verification, by a significant margin.

The reason we keep switching back and forth is that every time you make objection A, and I explain how the system addresses that, you switch to objection B, ignoring that I already explained how the system addresses that as well.