He is not wrong on the main claim, which is “All ECC (X25519-P521) will be broken by private sector quantum chips before RSA-2048 due to the physical limitations of stabilizing qubits.”
Shor’s algorithm is polynomial, however the number of qubits required is in order of O(log(n)^2), where n is the length of the key. Because ECC keys are much shorter (e.g., 256 to 521 bits) than RSA (2048 to 4096 bits), a smaller quantum computer would be needed to attack ECC.
RSA needs 4k (or 16k) keys because, with index calculus, these sizes reduce to a subproblem where you effectively need only 2^128 (or 2^256) time rather than the 2^{4k} for brute-force.
I think, but I may be misremembering, that you could apply Shor's algorithm to speed up index calculus by going for the subproblem directly? In this case RSA would fall too.
I note that the NSA recommendations are "move to post-quantum crypto", not "go back to RSA" so I infer that they think RSA-4096 might still be vulnerable.
I am not NSA, but I think their idea is something along the “once Shor’s algorithm is practical for key sizes of hundreds of bits, it’s only a matter of a few years of engineering effort to make it feasible for thousands bits long keys”. In other words, there is no sufficient safety margin for larger keys.
This is the first time in nearly 30 years I've ever heard the claim that you only need 18-20 qubits for something like a 256 bit key.
I've only ever seen the claims of 1:1 key bit to qubits. Aren't there existing claimed quantum computers with 20 qubits? Isn't Canada's machine an order of magnitude more qubits?
I think it matters not only how many qubits you have, but how they are "connected". As far as I know, it's a far easier problem to put N qubits in a chain with O(N) connections, than it is to have N qubits with O(N^2) connections to form a complete graph. And I believe the second example is what you need to do Shor's algorithm.
I am sorry, I should’ve read it twice before posting. I meant, QC to attack longer keys should be bigger proportionally. Number of operations is logarithmic. Silly me.
I'm not sure this is true anymore. There are recent improvements in quantum factoring algorithms, which significantly reduce the number of qubits required. See eg https://eprint.iacr.org/2024/222
IPv6 + transport mode IPsec + opportunistic encryption with TOFU or other topologies of trust (including WoT, DNSSEC and PKI). All that is standard, most of it is available and only requires configuration (and, ideally, being turned on by default).
There is very little use for companies like Tailscale in this setup, it’s scalable and works.
I acquainted with a guy at a conference in US and he was genuinely surprised I had no idea, how long US mile is. I explained him, we use metric system and his response was “but don’t you learn *the standard* system in ache school?” I did not know, how to respond.
AFAIK USA people learn both systems in school. So it understandable if they are not aware that the rest of the world don't know about their system, miles, inches, feet, gallons, pounds, etc, unless they are into American culture (books, movies).
One of the things that USians are taught in school when they learn these two systems is that everyone else uses metric. We're typically taught it in our science classes, because even in the US, scientists still use predominantly (exclusively?) metric. It follows that there's no parallel reason for most foreigners to learn US imperial units, especially in an institutional setting like public school.
> If you aren’t talking across continents there is no need to speak two languages
Continents have nothing to do with this. If you live in the UK and need to talk to people in the USA and Australia, you can be monolingual and still speak with people in three continents. If you live in Switzerland, you may need to speak 3 languages just to be able to talk with all your neighbors.
There is also an abundance of people who don't speak English, or prefer not to, right here in North America. The Canadian province of Quebec, for instance, legally mandates bilingual signage and generally prefers French. And Mexico is right there too.
There are also a great many families in the US whose first-generation members have limited English.
Languages as in knowing two systems. Sort of like how most people don’t need to know international date or thousands/decimal separator conventions, but those functioning internationally—whether due to being well travelled or senior enough to conduct international trade and/or relations—do.
My going to a conference in India and arguing over the lakh/crore system isn’t useful to anyone [1].
Even then, continents have little to do with it. The Indian numbering system is indeed used in much of Asia - but it's not used in Russia for example. If you live in Vladivostok, you might need to learn these two systems even if you never do business with anyone farther than 300km from you.
And in Europe there are numerous differences between countries of this kind - Germans and a few others use different number separators (1,000 is 1000 in France or the UK or Spain, but 1 in Germany or Romania). Several places drive on opposite sides of the road. The UK uses many imperial units. I'm sure there are others I haven't even come across yet.
> (1,000 is 1000 in France or the UK or Spain, but 1 in Germany or Romania)
No, France and Spain follow the same standard as Germany: dots as thousands separators, a comma as the decimal separator. Actually most of Europe does the same, the only exceptions being the UK and Ireland:
> You will probably spent some time "teaching" them first
SELinux works well out of the box in RHEL and its derivatives since many years. You comment shows, you did not actually try it.
> fight with them every time you install something or make other changes in your system
If you install anything that does not take permissions into account, it will break. Try running nginx with nginx.conf permissions set to 000, you will not be surprised, it does not work.
I'm glad SELinux works better than in the past and at the same time I'm sorry it didn't from the start as many people were frustrated by it at that time (e.g. [0]). On the other hand, it looks like some people still get upset by it[1].
> disallow users to choose a password they used previously (never understood that one)
That’s because you never responded to an incident when user changed their compromised password because they were forced to only to change it back next day because “it’s too hard to remember a new one”.
Disallow the use of breached passwords - whenever a password change occurs check against e.g haveibeenpwned.
No need to remember past passwords (which is another security risk btw if you ever get breached it will leak all passwords the user ever had).
Dear user with password “password11111111111” logging in from a random computer with two password stealers active, from a foreign country, and not willing to use MFA, incident response team will thank you and prepare a warm welcome when you are back to office.
Honestly, this comment shows, that user education does not work.
You choose to have Google spying devices at home. You choose to have Gmail. You may have no choice for Internet search for quite some time, but you certainly choose your browser.
Disagree with this. self hosting email is notoriously difficult. Gotta give the data to somebody. Plus, your work email is either going through MSFT or GOOG, 99% of the time
The numerous other email providers are... numerous. Every discussion like this ignores, to an absurd extent, how hard it is for non-tech people to gather information on these topics and make an informed choice: Information about which email providers are care about which aspects of privacy, which aspects of privacy and information security even exists, which email providers even exist, what they are doind with your data, what parts of what they are doing is a problem...
You can't even ask tech people to make a choice for you because they all say different things.
Other domains like cars, medicine, construction, whatever have established standards because they have recognized that individuals simply _cannot_ make an informed choice, even if they want. I'm eager to say that only information technology likes to call the user "unwilling" and "lazy" instead, but actually individuals from other domains do that too. Luckily, the established standards are mandatory, so their opinion doesn't count.
Rounding error that doesn't matter, because the recipients of any e-mail sent from those providers are likely on mailboxes backed by Google or MSFT anyway.
It kinda does, though. It's why I stopped self-hosting. I bet if you emailed my gmail address it wouldn't come through, even through no fault of your own.
You can have DMARC, SPF and DKIM all correctly configured on a clean IP and some mail server at Microsoft will still drop your mails because it's having a hard day and it feels like it.
This makes it something that the average person cannot do; you're suggesting something that already requires more time and resources than 75% of the population has access to.
If you're serious about this than go talk to a non-tech person and tell them to self-host email and see how they do. Look at their challenges, build a solution and then offer it.
Please don't try changing the goal posts by introducing "non-tech" people into this.
That's not at all what the conversation is about, and routing through an external place removes a whole bunch of hassle compared to setting up and maintaining outbound email.
You might not like it for some reason, but that's on you.
If you need a third party to deliver your mail on your behalf, are you really self hosting?
What's the point? At that stage you've already conceded the deliverability problem so now you're just wasting time administrating dovecot and keeping up with security patches.
Nope. Non-resident keys work differently. You register the public key with the service, then you encrypt the private key (via wrapping but that’s beyond the point here) with private key stored on your hardware token and send the encrypted blob to the service, too.
When you need to authenticate, service sends you the encrypted blob, you decrypt it using the key on hardware token and obtain the private key. Than you do (more or less traditional) public key authentication.
So, you don’t need to manage your private keys. Services do it for you.
The point is many players are trying to find ways for your private key to be portable, too? Yes, it is a basic public key share to the services you are authenticating with, but it is how to maintain convenience at the user's side that is posing difficulties.
Indeed, the first real criticism in the post is "For example, if you create a passkey on your iPhone, it easily syncs to Mac devices but is incredibly difficult to use on a Windows device." It is the private key that they are syncing to all of your devices. And they do that for you because they control all of the places that they sync.
I think you can make the case that they should not sync this off device for you, but then you are in the "what happens when my device is lost/broken/stolen?"
You could also argue that they should let you export the key. But then you are back into the "credentials are easily stolen."
Proton Pass allows you to export and reimport passkeys. An industry-wide standard for exports is not yet finalized, but as soon as it is, we'll support that too.
Regarding passkey implementation, it's up to individual websites whether they use passkey or passkey + 2FA, etc..
For our corp environment we initially embraced software-backed FIDO authenticators (aka passkeys), but now I am almost ready to start enforcing only hardware authenticators via attestation.
The worst offender is (of course!) Google. In Chrome they bend the interface as much as they could to lure people into using Android as a key holder (and to sync it later on) even when platform authentication is available. Apple was very unfriendly by making their WebAuthn API private, so Safari used Keychain, Chrome did not have access to it (and forced Android) and Firefox only could use Yubikeys.
And now password managers are jumping into this, so when a user tries to enroll the device in a browser with password manager extension (looking at you, Bitwarden) on a platform with software authenticators good luck finding the right combination of clicks to choose Yubikey.
Enshittification of FIDO auth happened unbelievably fast.
Shor’s algorithm is polynomial, however the number of qubits required is in order of O(log(n)^2), where n is the length of the key. Because ECC keys are much shorter (e.g., 256 to 521 bits) than RSA (2048 to 4096 bits), a smaller quantum computer would be needed to attack ECC.