The algorithms at risk are the asymmetric part (RSA, ECC, DH), not the symmetric parts (AES, ChaCha), so what is done for encryption is "generating" a secret with ML-KEM and another with ECC, combining them, and using that as key for AES or another symmetric algorithm for the actual encryption. So if you break only ECC or only ML-KEM, you don't get the combined secret. ML-KEM keys/ciphertext are small and efficient enough that this overhead is generally a non-issue.

Note that ECC can be used in many ways: asymmetric encryption, key encapsulation, or signatures. ML-KEM, the new post-quantum standard, is only a Key Encapsulation Mechanism. Hence the "generate an AES key" step, instead of "encrypt a random AES key".

For signatures, like in the announcement in the post, things are more complicated. The post is a very good introduction to the problem.

Still better than the alternatives that would saddle us with worse performance for ~ever.

And even if there was only a 10% chance of QC breaking crypto, the community is not comfortable with a 10% chance of such a catastrophic scenario.

This is part of my day job, so here's another interesting fact: for migrating encryption use cases, you have to consider that attackers can capture your encrypted data today to break in the future. So, as a rule of thumb, your migration timeline is much shorter for encryption than for signatures.

I don't see a way back, but it does feel like abandoning public transportation because we all own electric bikes now.

All of the "positive" items I listed come with drawbacks. I didn't realize I might be in the minority for this one, since I genuinely prefer the new workflow.

It'd be a very jumpy bar, but it helps develop intuitions. "The first part is always slower on this machine", "when it gets stuck on this spot I need to reset my router", "this part will be slow because the request is large", etc.

But we did gain some nice things!

- Tabs.

- Titlebar buttons and other space-saving measures.

- Document editors remembering unsaved changes.

- Forms that validate on focus lost, instead of submission.

- Ctrl+P menus to fuzzy-search all actions and settings (we need more of those).

- Easy syncing (if I open Spotify on any device I'll see the same playlists, my clipboard is shared between phone/desktop/notebook, Immich integrates local and remote media, etc).

- Program-specific URL protocols, so that you can click on a link and have it open in a separate program (like `steam://open/games`).

- Map widgets, a small miracle we take for granted.

- Package managers/app stores that cleanly install and uninstall applications.

But it wasn't? TFA is describing a technical issue that kept cancelling a subscription. This is not a "we've noticed that you haven't been using the service and paused billing" situation.

It's worse than that, the combined availability is the product of all components in the critical path. If your software, the authentication layer, and the cloud provider each have 99% availability, and any one of them can bring your service down, then your final availability is just 97%. With eleven components like that you have zero nines of availability.

That's why reducing components and going for reliable solutions is so important. I'm happy that the team took this path.

In Brazil "ethanol" is sold separately from normal gasoline, and as far as I know it's entirely made from sugar cane, without fossil fuels. It's why flex cars are so popular there, since they can use either fuel depending on what's cheaper.

Meanwhile, you can't buy 100% corn-based fuel in the US.

Could it be just the illustrations? I'm not knowledgeable enough to judge the text contents.

If I send you a document encrypted with classical crypto today, an attacker could grab a copy, wait a few years, then decrypt with a quantum computer (Harvest-Now-Decrypt-Later). The contents of the document I sent today are exposed in the future.

For documents/transmissions that must remain confidential for 10 years, assuming a quantum computer available in 2030, you should have been encrypting them with PQC since 2020! And if deploying PQC for your clients and servers takes two years, you should have started migrating in 2018!

But if I send you a signed document, it's safe because you're verifying the signature today and there are no quantum computers available today to forge a new signature. The same goes for SSH authentication and web certificates, for example. They're safe right until the moment quantum computers arrive (and by then you better have a good solution!).

That's why so many open-source projects already support ML-KEM for key exchange/encryption, but signatures are still under discussion. The former is more urgent.

There's a good consensus that for key exchange/encryption (TLS, SSH, age, etc) the way forward is ML-KEM 768 together with some classical algorithm, like X25519. The public keys are larger (1 KB), but that's usually ok unless you're working on very small microcontrollers. And you should migrate quickly because of harvest-now-decrypt-later attacks.

For signatures, things are harder because there are tradeoffs. Some algorithms have large signatures (10+ KB), others require keeping state and have catastrophic consequences if subkeys are reused. And the systems around it are also more complicated: in a certificate, should you put a classical and a PQC signature together? Or should the PQC signature go in an extension? Should the extension be marked as critical and fail loudly on old clients, or should new clients have a special case to always check it if PQC signature validation is available? Or should we abandon the certificate chains and move to Merkle Tree Certificates[1]?

So signatures/authentication are still up for debate. Unless your team is on the bleeding edge of either crypto research or security risks, then there's not much to do than wait for better consensus to form.

[1] https://postquantum.com/security-pqc/googles-merkle-tree-mtc...

The problem is that we're not trying to predict the exact future, we're hedging against possible developments. If there's a 50/50 chance of quantum computers being widely deployed for cryptoanalysis, then there's a 50% chance of this migration being useless. But you don't want to bet your security on a coin toss! So, we migrate.

That's the unfortunate truth of security, sometimes the protections are never triggered. But you still need them.