Well, yes, if they use something completely different to what's published and designed.
But no, we're not talking about the case where there's no trust at all in the government, because then you don't get verifiable credentials at all. We're talking about building privacy-preserving credentials that actually have a use.
That's not how that works - they can prove they check by showing logs, rather than VPs. There's even legal limits on what identifiers they can store and for how long. But even ignoring that, they'd be storing only very limited disclosures.
The base registry stores identifiers of issuers and verifiers, not credential holders.
Even the status register does not contain the tokens themselves:
> Within these status lists, each index (i.e., status entry) documents the validity of one VC. The corresponding index is captured in the VC’s metadata to allow for a decentralized status information retrieval that does not require verifiers or the VC holder to contact the issuer.
Of course, each issuer needs to maintain a list of the credentials they have issued in order to be able to ever revoke them. That's unavoidable.
In the Swiss system, it depends on what they verified. If they required your full ID, that has a document number like a passport and they could track that.
If they did the right thing and only asked for the over 18 bit, then they wouldn't have a trackable identifier.
There's no dynamic analysis done, necessarily. In the Swiss design, fex, SD-JWTs are used for selective disclosure. For those, any information that you can disclose is pre-hashed and included in the signed credential. So `over_18: true` is provided as one of those hashes and I just show this to the verifier.
The verifier gets no other information than the strictly necessary (issuer, expiry, that kind of thing) and the over 18 bit, but can trust that it's from a real credential.
That's not strictly a zero knowledge proof based system, though, but it is prvacy-preserving.
The revocation checking is implemented in a way where the government doesn't know who you checked and you can even cache the information (if that's good enough for you) so they won't notice at all.
That assumes the companies store the individual tokens, as does the government. Neither of which are part of the design, but could be done if both sides desired it.
The Swiss design actually doesn't store the issued tokens centrally. It only stores a trust root centrally and then a verifier only checks the signature comes from that trust root (slightly simplified).
Considering that companies will do everything to avoid doing sensible things that cost money - yes, of course the government has to step in and mandate things like this.
It's no different from safety standards for car manufacturers. Do you think it's ridiculous that the government tells them how to build cars?
And similarly here: If the company is big enough / important enough, then the cost to society if their IT is all fucked up is big enough that the government is justified in ensuring minimum standards. Including for backups.
Unfortunately the self-host documentation isn't great and the deployment options are quite limited.
Sure, it's at least dockerised, but it requires root privileges (so no running it in a secured kubernetes env) and forces you to use MSSQL as the db (so pay up for that or hope that express works).
It's also unfriendly to automated deployment, with several manual steps and regular rebooting requires.
No, Switzerland is at most a semi-direct democracy. We don't vote on every last decision the government takes, after all - we have a bicameral parliament and an executive branch for those!
It does for me, because his criticism (since shown to be wrong) never included the claim that KYBER was broken, just that it wasn't perfect and that he was unfairly treated.
Cranks and assholes occasionally are unfairly treated, but generally are fairly ignored - the effort of dealing with their claims aren't worth it.
As an outsider, "respected cryptographer makes a narrow technical claim and is brushed off by NIST" and "sore loser that no-one talks to complains that people aren't entertaining his latest complaint about the ref" are very different situations, from which I will take very different actions.
First off, thanks for the reply. It has since been pointed out to me elsewhere that there are now responses showing his central claim of a maths error to be false, which means all of this is now moot - KYBER is as secure as claimed.
It has also been pointed out to me that djb has been quietly ignoring another metric in which KYBER beats NTRU: implementation complexity.
Even accepting all other arguments about the tradeoffs between NTRU and KYBER (and I do take your point about size of keys being more important than CPU cycles), even then, KYBER is judged to have lower implementation complexity.
Having read about all the crypto libraries who produced broken output because they made a mistake in the implementation, that's something I immediately understand as a big benefit.
Again, thanks for the conversation and helping me understand!
Hm. Yeah, I really need to adjust my view on this - I found NIST's responses dodgy precisely because they seemed so unwilling to engage, and I still thought of him as respected enough to warrant better responses.
If he's turned so crank-y that his peers simply no longer engage with him beyond the strictly necessary, then this all looks a bit different.
I'd still love to see some of his specific criticisms addressed, but that becomes a minor point...
The last part I agree with - clearly KYBER isn't trivially broken if this is the best he can come up with.
What doesn't seem clear to me, and I'd appreciate if you could tell me why you think differently, is that KYBER-512 isn't as strong as it was targeted to be. I find djb's argument on this narrow point fairly convincing: KYBER-512 isn't as secure as AES-128 (by the methods used to measure "secure" in this competition).
Given that I already generally use AES-256, why shouldn't I treat this the same way as AES-128?
That is, "it's probably fine-ish, but if you have the power, just go one bigger".