Denial of facts usually starts with reasonable-sounding inquiry into the details, which makes nuanced discussion of data very hard. Asking if the real number was maybe 5.75 million puts you in company with deniers.
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.
Make sure you go into that eyes wide open, I misguidedly thought there was some communication between Bitwarden and the open source vaultwarden but there is not.
I've been burnt by things breaking as Bitwarden updates the client and vaultwarden tries to keep up without any advance notice of the changes until someone reports it's broken.
I prefer Vaultwarden because it’s much much easier to set up and had only minimal problems, the only one I could think of being some inconsistent behavior when syncing passwords for the clients inside organizations. I find the setting up of Bitwarden locally gruesome.
There was a breaking change when I updated to iOS 18, but by the time I’ve noticed that, it was already fixed in an update.
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!
> No, Switzerland is at most a semi-direct democracy. .. We don't vote on every last decision the government takes
Trotzdem nennt man das "direkte Demokratie". Wir hatten noch so etwas wie "Staatskunde" in der Schule. Die Jungen haben das heute anscheinend nicht mehr. Der Punkt ist, dass das Volk per Initiative etc. bei Bedarf eingreifen kann, also nicht nur dem Parlament aus der Ferne zusehen darf. Siehe auch https://www.eda.admin.ch/aboutswitzerland/de/home/politik-ge....
You can call it what you want but even Wikipedia makes a clear distinction between a "direct democracy" without representatives and "instruments for direct democracy in an other representative system": https://de.wikipedia.org/wiki/Direkte_Demokratie
Of course your "Staatskunde" lesson in school may have handwaved that distinction because the former by definition is stateless and the purpose is to distinguish between the Swiss governance model and other representative democracies, not doing a deep dive on all forms of governance.
We had "political science" lessons in school and they were largely about the structure of our own system (e.g. one exam literally involved adjusting the federal budget), maybe with some excursions to contrast it with e.g. the US but I don't think we ever learned about delegative democracy, let alone anarchist, minarchist or Marxist theories. Because it was a public school in Germany, the German model of the "social market economy" was never challenged and implied to be the best possible system because it is written into our constitution.
Saying a representative democracy that makes use of instruments for direct democracy is direct democracy is a bit like saying a social market economy (i.e. a market economy with a state-provided, limited, tax-funded social welfare system) is socialism. One may have political motivations to label it as such (either to make it more or less appealing) but it muddies definitions by conflating "pars pro toto", i.e. a part and the whole.
Yeah, the definition is one of several and I explained why it's not a good one, regardless of how widely it is used. That you prefer this definition over others does not invalidate them - that's literally just your own opinion.
That's a website of the Swiss government calling its system of governance a direct democracy. I'm talking about political theory, not the Swiss government's publications about itself nor the Swiss curriculum for "Staatskunde" lessons in schools.
I understand that Switzerland calls itself a direct democracy. I understand that many other representative democracies refer to the Swiss form of governance that way. I understand that this language may even have ended up in laws and legal interpretations, but that doesn't change that "direct democracy" means something very specific (i.e. literally everyone voting on every issue, often in the form of proxy voting or delegation) in political theory. I'm not saying Switzerland does not offer more voter participation than other representative democracies. It is a lot closer to direct democracy than any of its neighbors or fellow European democracies. But it's not a direct democracy.
Think of direct democracy like functional programming: there are plenty of programming languages that were originally conceived of as procedural or object-oriented or class-based that claim to support "functional programming" and some are actually very good at it but that does not make them functional programming languages in the same way as languages designed as functional programming languages from the start. Switzerland started out as a representative democracy and introduced and strengthened its participatory instruments over time to behave more like a direct democracy (check out the PDF at the end of the page you linked, it even uses the same narrative of Athens and the French revolution used by other representative democracies to explain their origins). That does not make it a direct democracy, it just makes it a representative democracy with exceptionally good participatory instruments.
It makes perfect sense for Switzerland to describe itself as a direct democracy when it wants to contrast itself with all the other representative democracies because those instruments borrowed from direct democracy set it apart. But that's like Ruby bragging about being a functional programming language by comparing itself to Python and Java because Haskell and Lisp are not part of the conversation.
These may all be interesting trains of thought, but they have little to do with the state treaties and processes at hand, which are based on agreed terminology (insofar as human language allows such a thing at all) and which are the reference for the assessment of the case at hand. If you are interested in the subject, you should study the works of established state theorists. Wikipedia is a rather dubious source for a scientific discussion of a topic.
State theory and specifically the state theory relating to legal practice like "state treaties and processes" is a very small subset of political theory, let alone political philosophy. There is a broad range of political theory outside that narrow subset and "direct democracy" has a specific meaning distinct from representative democracy.
Redefining it as a subset of representative democracy through the introduction of participatory processes makes sense when talking in a context where representative democracies are taken for granted but it is extremely unhelpful when talking in a broader scope where representative democracies are merely one of many categories of systems. There's a reason the PDF references the French Revolution rather than the Paris Commune and describes democracy merely in a (largely ahistorical TBH) European context informed by the Enlightenment era and limits the idea of decentralisation to the federalism of cantons rather than exploring it further: it's not about analysis, it's about creating a national mythology and a historical narrative that has the present system as an inevitable end state that can only be built upon but not fundamentally changed.
And all of this is really a red herring because the original argument was about whether the system Switzerland has makes it unnecessary to appeal to a super-national court in order to force a decision. And given that referendums and public initiatives still require a majority in order to pass the answer is clearly no.
Given that the claim is that the (in)action of the Swiss government accelerates/intensifies the climate catastrophe and that this effectively violates the human rights of a minority group (i.e. seniors are more likely to die from severe weather events like heatwaves) and that referendums have not helped change the (in)action of the government, a referendum is the wrong instrument as the question is not what the majority wants but whether a minority has their fundamental rights violated.
You can argue that the ECHR court was wrong to agree that this is a violation of the rights asserted by the ECHR. You can argue that Switzerland should leave the ECHR and replace it with a different human rights bill - and assuming you have the requisite legal status in Switzerland you can even attempt to force this question with a public initiative. You could also simply argue that they should have sued the Swiss government in a Swiss court of law first (I'm not sure how the Federal Supreme Court works but presumably the process would be a bit more involved) before taking this to an international level. But the ECHR court is ultimately the right addressee when arguing a signatory's violation of the ECHR, "direct" democracy or not.
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...
It actually doesn't, because NIST needs to speak to and be trusted by more than just a tiny clique. Djb crypto is widely known and used which means they have to deal with him whether they like it or not.
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.
You're making decisions based on trivial social factors instead of the only salient point, which is that NIST had proven itself to be corrupted in the past when it comes to setting cryptographic standards.
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.
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.
I’ve not followed the PQC competition very closely, but I don’t think djb’s arguments significantly impact whether you should use KYBER-512. From my reading, as someone with a decent amount of crypto knowledge, all the evidence suggests that it is more than secure enough. The rest of the stuff is at the level of “submit an erratum”, not “omg cancel the whole thing”.
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.
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".
It’s possible that in the specific sense that NIST defined, KYBER-512 isn’t as strong as AES-128. However, that doesn’t mean that it’s less secure in general. E.g. DJB himself wrote a good article[1] on how even though 128-bit AES and 256-bit elliptic curve crypto are thought of as same “security level”, actually there are attacks against AES that just don’t apply to ECC when you consider multi-target security models (i.e., when you consider a population of users not just one). I wouldn’t be surprised if similar things applied to lattice-based crypto, but I don’t know enough about it. And even if we take the reduced security level given by DJB, it still seems big enough to be out of reach to any realistic attack.
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).
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!
There's a valid point to be made about selecting key exchange parameters to match bulk encryption parameters, but before you gear up to make a stink about it, bear in mind that it's generally the case in modern cryptosystems (that aren't specifically designed to do that matching) that key exchange security levels are lower than those of block ciphers. The step functions for key exchange security levels are pretty abrupt, and you pay a pretty high price to select the next one up, so aiming for "roughly the vicinity" of 128 bits is pretty normal.
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.
PBKDF2 should only be used if compliance with government requirements is a concern. While it can be adjusted to be arbitrarily difficult by changing the iterations it's still not memory intensive and can still be fairly easily cracked with a GPU (when compared to scrypt or argon2id).
md5 was never supposed to even be used for passwords, it was designed to produce really fast checksums for files, a very bad property for a password hashing algorithm
