Readit NewsWhich forms of 2FA would be resistant to the attack Troy faced?
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.
The issue is that Switzerland outlawed air conditioning for private homes (still allowed in shopping centres though!)
I know of a bunch of people who legally purchased and installed aircon in their homes.
Switzerland is a direct democracy, not just a representative (i.e. indirect) democracy. In the present case the ECHR is obviously misused with very dubious arguments. The fact that the ECHR does not put a stop to such abuse will not exactly improve its acceptance among the Swiss voters.
We just also have votations on a lot of things.
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!
But by all means feel free to go one bigger and pick KYBER-768, and I believe lots of people do recommend this. Obviously, there is a performance penalty (as there is when moving from AES 128 to 256), and for PQ schemes there is also more importantly also a big increase in the size of bytes on the wire when public keys have to be exchanged (e.g. in TLS) - in this case a jump from 800 bytes to 1,184 bytes (a 48% increase). (Compare this to ECC public keys which are typically around 32-65 bytes, depending on encoding).
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!
I do believe he has increasingly argued in bad faith and alienated his peers to the point that they're (we're) unwilling to engage with him, which from the outside can look like his points are unrefutable.
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...
If anything, this reinforces my belief that KYBER is a good design. If this is the best he can come up with to try and discredit it, then it must be pretty solid.
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".