There are tables at the end describing the algorithms key sizes. be mindful of "(Size in bytes)" not bits. They cover that these algorithms use bigger keys, but it is 4 kilobytes.

Thank you for the update. This is really useful. It would be really great, if you could commit to an update a few years down the road at the latest. E.g. "I will release an update no later than August 15th 2027". 3 years in the fast-changing world shouldn't be such a burden and it would help to settle many discussions somewhat reasonably with appeal to authority :-D No seriously, having something that can be considered current advice would be great.

Good list of early supporters near the bottom of the post text - Chrome, OpenSSH and iMessage are relevant for me.

As I understand it, the only reason pqc is of "practical" concern is the issue of "store now, decrypt later".

Is it possible to defend against this attack in a classical way? Some sort of time limit on decryption? Or an argument that it's impossible?

Excellent post, I've always recommended people to this series.

I'm curious what's the general opinion on the production-readiness of these solutions. Open Quantum Safe, for example, discourages it's use in production, and recompiling nginx to use PQC-BoringSSL feels risky since I'm not intimately familiar with both projects ("did I miss a --enable-security flag?").

> the PQ keys are 4 orders of magnitude larger

For McEliece, perhaps, but the algorithms in the tables are "only" 2 orders of magnitude larger.

“Classical cryptography” used to refer to historical ciphers, Vigenère and the like, tapering off after the World War 2-era cipher machines and definitely not used to describe asymmetric algorithms. There should be a different term for pre- (non-?) quantum cryptography from the modern era. We already suffered the redefinition of “crypto”.

NIST announcement:

* https://www.nist.gov/news-events/news/2024/08/nist-releases-...

See

* FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM / CRYSTALS-KYBER)

* FIPS 204, Module-Lattice-Based Digital Signature Standard (ML-DSA / CRYSTALS-Dilithium)

* FIPS 205, Stateless Hash-Based Digital Signature Standard (SLH-DSA / SPHINCS+)

From:

* https://csrc.nist.gov/News/2024/postquantum-cryptography-fip...

* https://www.federalregister.gov/documents/2024/08/14/2024-17...

Hostly, most cryptographic vulnerability today are because things are stuck in the NIST and FIPS regulation. Most vulnerable building blocks are still shipped to have their certification to begin with. Why there's still excitement to their work?

I've always found it a bit disquieting how many times people feel the need to update these "cryptographic right answers" blog posts.

This is what, a fourth or fifth version since 2009?

Meanwhile everything from ubuntu's apt-get to my connection to HN is secured with 2048-bit RSA - an algorithm invented in 1977 and in widespread use since at least 1995.

Am I getting crypto advice that will keep my data safe for 30+ years, if the advice changes every 3 years?

>Avoid: HMAC-MD5, HMAC-SHA1 and such. The underlying hash function has to be safe.

Interestingly enough, there is a proof out there that more or less states the opposite for HMAC-MD5 and HMAC-SHA1:

* https://eprint.iacr.org/2006/043.pdf

The issue here is that MD5 and SHA1 are broken for collisions. But no one could figure out an actual attack for HMACs based on them. The linked paper is an attempt to explain that.

Great post! I was worried for a long time about this thing as I'm also working in DeFi field. It's great that governments are taking the quantum computer threat seriously

Yes. It's past time for this concept to be put to rest. It started out as a joke and has taken on a life of its own; moreoever, it has looped back over onto itself, to the point where it's advocating a sort of DIY SOTA vibe that is going to get people hurt --- the opposite of what the joke was going for originally.

> Meanwhile everything from ubuntu's apt-get to my connection to HN is secured with 2048-bit RSA - an algorithm invented in 1977 and in widespread use since at least 1995.

That’s a bit misleading, considering RSA is only used for certificate verification. Key exchange and symmetric encryption is handled by somewhat more recent algorithms (ECDH / AES-GCM).

The right answer is not always about straight-out security: 2048-bit RSA is not broken and won't be broken for the foreseeable future, but we know that it is much less efficient and more error-prone than e.g. ECDH. So why suggest the former when the latter is a better alternative?

You should consider these "right answers" as if the question were, "I want to develop a new product today. What cryptographic primitive should I use?"

Perhaps the meta-message here is that you absolutely have to design for cryptographic agility.

You may not need to jump to the next best thing every 3 years, but as certain constructs are proven weak, you’ll need to start migrating systems and data off of them to modern equivalents.

> Am I getting crypto advice that will keep my data safe for 30+ years, if the advice changes every 3 years?

If you drill into the details a lot of things haven't changed. Eg, the key size and HMAC recommendations go back to the original version (among others).

The “right answer” also depends on attack vector. If you are trying to protect against nation-state-level tampering or data leaks for two full generations, the enemy moves much quicker, and so you will need to advance much more quickly, to outpace what you think they might do to outpace you in the future.

If you are only trying to prevent your ISP from seeing your traffic, which they are not trying particularly hard to do, then that level of protection would be overkill.

On one side, there is good in "This is the best prediction of the future we have right now and we update it as our knowledge changes".

They also have a consulting product to sell you. When you build your entire society on "greed as a virtue", it is reasonable to assume it as a primary motivation for a profit seeking entity.

an algorithm publicly published in 1977.

The Ellis, Cocks and Williamson algorithm has existed since at least 1973.