logoalt Hacker News

sehansentoday at 7:58 AM3 repliesview on HN

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`?


Replies

BoppreHtoday at 8:12 AM

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

show 2 replies
bwesterbtoday at 9:45 AM

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.

alephnerdtoday at 8:10 AM

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.

show 1 reply