[BoppreH]

Interesting development. Merkle Tree Certificates throw away decades of cruft, but also decades of battle testing and ancillary tools. I trust the teams involved, but this will be a hell of a project.

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

[throwaway01632]

Is there any value in first encrypting with a battle tested algorithm, and then encrypt again with the new algorithm?

[BoppreH]

Yes! It's called a hybrid cryptosystem, and what most projects are planning to use.

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.

[mswphd]

worth clarifying that you're both right that this is often referred to as a "hybrid", and there is the exceedingly unfortunate naming collision that "Hybrid Encryption" can also mean something separate, namely using a PKE encryption scheme (or KEM) to solely encrypt a secret key, and then using the secret key for bulk encryption. See for example the Hybrid Public Key Encryption (HPKE) RFC

https://datatracker.ietf.org/doc/rfc9180/

the unambiguous way to describe what you're talking about (not only for encryption) is the notion of a combiner, though it is admittedly mostly used in theoretical circles.

Also, your comparison between ML-KEM and ECC isn't right. ML-KEM is a KEM built from the Module Learning with Errors assumption, a lattice-based assumption. Part of how ML-KEM is built is by building a PKE scheme. This is an internal implementation detail though, and the FIPS standard explicitly states that they are only approved as part of building ML-KEM.

You can additionally build signatures from MLWE. For example, the ML-DSA scheme (which is a FIPS standard as well) does this. The issue is that lattice-based KEMs and signatures are atypically large compared to ECC precursors (this is what the blog post refers to).