myrion

I don't use old Reddit, and haven't noticed this behaviour either.

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).

Schweissen und löten. Has nothing to do with Switzerland (Schweiz) ;)

Because politicians make laws, and those affect the "legal hurdles" that companies need to deal with.

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.

There's no much difference between the two positions, and the former is very much a lead-in to the latter.

FIDO authenticators. If the "autofill" doesn't work, you can't be tricked into overriding it.

Great and simple UI, synced across all your devices (which is what ended up killing RSS in f.ex. Thunderbird for me).

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.

Show me that law, because as far as I can tell, that's complete nonsense.

I know of a bunch of people who legally purchased and installed aircon in their homes.

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!

We just also have votations on a lot of things.

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.

This is looking more and more like the latter!

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".

At least for myself, I disagree that NIST could only win by not running the competition.

The impression I have right now is that they made some mistakes and in response to having those pointed out went "well, that's just like, your opinion, man" instead of explaining why it's not a mistake, or fixing it, or something.

That's what makes me suspicious, anyway.

Here's my honest shot at it:

In between a bunch of conspiratorial hinting, djb argues that KYBER-512 is weaker than NIST claims.

To make that argument, he points out a fairly egregious math mistake (the whole "2^40+2^40" bit) and then shows that NIST was inconsistent in applying the rules of the contest it refereed.

He also offers an explanation for why NIST would be so inconsistent about it, namely that they were influenced to pick KYBER, even if it wasn't the best candidate.

--

My personal takeaway was that he was both being a sore loser but also that KYBER-512 is weaker than it should be, weaker than it is claimed to be and that for some reason NIST still wanted it to win.

Makes me skeptical about KYBER-512 (but not larger sizes) and reinforces my worry that NIST can be influenced to pick less-than-optimal algorithms.

But then, I'm not a cryptographer and in the lucky situation where for any application I encounter, I can just go for KYBER-768 or 1024 or NTRU and just be fine - I don't have to understand this situation perfectly.

Hope you get some value from this outside perspective.

That's if hashed by md5, which really shouldn't be the case anymore. SHA-1 isn't much better, aiui, but would still be a more reasonable reference today - at least as far as I can see.

I wish it were scrypt, PBKDF2 or argon2id - but I realize those are still rare.

Incidentally, Lego and Duplo are compatible!

So eventually you can use the Duplo blocks as large building blocks under more intricate Lego designs.

The NYT is in no way far left. It's a fairly centrist, vaguely middle-right publication. They have the occasional leftist essay, but far more often their op-eds are very strangely right-wing.

I say strangely, because it's not very typical, afaict, but just occasionally someone feels the need to throw something really bizarre out there. Which is why there's several variations on things like the "NYT pitchbot" out there, making fun of how bizarre those are.

It might make tradeoffs that make it unacceptable in other situations, particularly ones that are focused on being resource constrained in some way.

For example it could have low RAM usage, but become exponentially slower with message size, so it's fine for encrypting short messages only.

Or it could have a constant overhead somewhere that's fine for an IoT device that sends a report once a day, but not if you wanted to make thousands of connections per second.

Stuff like that, is my naive understanding.

Indeed.

I enjoyed it a lot too. It was a different take, but I thought that apart from the very first episode, it was very good and really wanted more.

I wish Pinterest were less effective at making google image search useless, not more efficient...