Comment by BoppreH
7 hours ago
I have another comment[1] on this post with more practical instructions, but the `ssh-keygen` is a good question. The cryptography community is still focused on migrating encryption/key exchange algorithms, for fear of data being captured today and decrypted in the future. So OpenSSH 10.0+ already enables ML-KEM by default.
SSH keys, on the other hand, are authentication and would require an online Quantum Computer to break, so we have more time. Authentication is also (usually) more complicated, so there are still disagreements on what to do with the Web PKI for example. To give you a concrete target, Google, Microsoft, and CloudFlare have self-imposed deadlines of 2029 for their PQC migrations.
In practice, PQC migration means updating your software, bugging your vendors to ensure they have this on their roadmaps, and making sure your own code is flexible in respect to algorithms used.
Late edit: PQC migration also includes sometimes changing configuration files/library invocations to enable the new algorithms, and ensuring that your processes still work during the migration, where you might have both pure classical and PQC/hybrid at the same time.
I just went through some ~/.ssh/config files and realized that, along side the entries for ancient systems that need to be forced to use undesirable ciphers and Kexies, I also had some entries for current systems that stipulated only the "good" values, to "protect me from hypothetical future downgrade attacks". Which means that I wasn't getting the latest PQ Kex, because my entries hadn't been updated since ssh 9.x.
Maybe the best practice here is to have one or more Boppers on your team who send out periodic notifications to update not just algos in libraries but, more importantly, make sure those updates are reflected in the damned configs.
We also really need a cultural shift where it becomes expected that, for any given app, we have something like:
$ ssh --best user@host
which does that for us. Because this is a failure mode that shouldn't even be possible for most users and cases.
There are also scanners that you can deploy to identify vulnerable servers, like https://sshcheck.com/ . Clients are harder to check, but you can always observe your logs.
Cloudflare should have finished it's PQC migration already.
That's true for their CDN (https://blog.cloudflare.com/post-quantum-for-all/), but there's a lot more to do, with a 2029 target (https://blog.cloudflare.com/post-quantum-roadmap/).
Ah yep. Good callout.
On a separate note, I've definetly been hearing worried murmurs about "harvest and decrypt" attacks along with post-quantum TEE slightly before the GCP paper, and I definetly think it appears a couple nation states are on track for a "quantum leap" by 2030 given the rate at which I've been hearing it within my network.
1 reply →
We're almost done countering store-now/decrypt-later, but the biggest part of the job, post-quantum authentication, still remains. Like Google, we target 2029 to be done .