[sehansen]

As a software engineer with a good amount of freedom to choose what tools I want to use, what can I do presently to move towards post-quantum cryptography? AFAIK the hashes and symmetric cyphers that are in wide use are already resistant, leaving mainly public-key cryptography as the problem. Is there, for instance, a drop in replacement for `ssh-keygen -t ed25519`?

[BoppreH]

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.

[1]: https://news.ycombinator.com/item?id=47959556

[BoppreH]

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_think_so]

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.

[BoppreH]

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.

[alephnerd]

Cloudflare should have finished it's PQC migration already.

[BoppreH]

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/).

[alephnerd]

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.

[alfiedotwtf]

How does that work when Diffie Hellman key exchange is ephemeral and so compliant servers couldn’t even roll back sessions if they wanted, to let a MiTM

[bwesterb]

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 .

[bwesterb]

SSH is working on a drop-in as we speak. TLS is further along: most stacks already support X25519MLKEM768 (by default!) to counter store-now/decrypt-later. PQ certs are not widely supported yet, but that's being sped up as we speak.

[alephnerd]

It's still being implemented or defined.

The worry about "harvest and decrypt" in a 5 year timeframe is primarily from a nation state/natsec perspective.

If you are being targeted by a nation state as a line level engineer, harvest and decrypt is the least of your worries.

[i_think_so]

I am reminded of a certain comedian who lost his job hosting an awards ceremony because he had once said something on stage that people didn't like....

...8 years previously.[1]

Long, long ago in a datacenter far away, breaking 3DES used to be the province of expensive bespoke hardware owned by only the elite nation states. Today it is so trivial that the gpu in your second hand laptop can do it "at scale".

5 years ago ChatGPT was a wet dream.

We should be very conservative in our planning where future security is concerned. The only thing we can be sure of is that Murphy's Law is looking for every chance to make us look foolish.

[1] https://www.bbc.com/news/entertainment-arts-46479017

[MattPalmer1086]

As far as I know, cracking 3DES is still not trivial, and requires a very large number of operations and/or a very large amount of data. But can just about be done in some situations.

If you have any link to trivially cracking it on your second hand laptop and doing it at scale, would be very interested.

[i_think_so]

Mea culpa! I must have had a brain fart and added the 3 in there. My sincere apologies!

Of course I can't find the link to whatever I read that discussed gpu accelerated des cracking now.

[MattPalmer1086]

Phew, thought I'd missed an important development there! The 3 makes the difference :)