[MJGrzymek]

Isn't that trivial in a sense? Encrypt with layer 1, then use that encrypted channel to send layer 2 (and so on). Not sure about the performance.

Signal has a post about using pre and post-quantum together: https://signal.org/blog/pqxdh/

> The essence of our protocol upgrade from X3DH to PQXDH is to compute a shared secret, data known only to the parties involved in a private communication session, using both the elliptic curve key agreement protocol X25519 and the post-quantum key encapsulation mechanism CRYSTALS-Kyber. We then combine these two shared secrets together so that any attacker must break both X25519 and CRYSTALS-Kyber to compute the same shared secret.

[chowells]

You generally don't want to layer encryption like that. It apparently really does introduce new kinds of attacks, which has been observed in the real world.

The pattern typically used for this is that the key for the high-speed symmetric encryption is split into multiple parts, each of which is encrypted with a separate public key system. One classical, one (or two, now?) with a post-quantum algorithm. As long as each part of the key is big enough, this still means you'd need to crack all the separate public key algorithms, but doesn't introduce any of the layering weaknesses.

[immibis]

Running TLS over TLS is fine, or ssh over ssh, or ssh over TLS, or so on. Otherwise the bad guy would just put the TLS traffic they intercepted from you, through their own TLS tunnel and somehow acquire more information.

In the early days of SSL there were cross-protocol information leaks if you used the same key or related keys for different protocols or protocol versions. In the DROWN attack, I can get some ciphertext from you in TLS, then feed related ciphertexts back to you in SSLv2 (an ancient version) if you're using the same key for both and have both enabled. With enough tries - a practical number of tries, not 2^64 - I can find the decryption of that ciphertext, and then I can calculate the key for the TLS session I intercepted.

Well, I can't because I'm not a leading cryptographer, but some people can.

[api]

Layering independent crypto is safe, otherwise one of the layers has some nasty vulnerability. Security should not depend on the type of traffic. If it does something is wrong.

In fact it’s common practice in high security government use cases to mandate two layers built by two different vendors for defense in depth. That way a nasty bug in one doesn’t compromise anything, and the odds of a nasty exploit in both at once are quite low.

You might be thinking of bespoke combinations of algorithms at the cryptographic construction level where the programmer is trying to be clever. Being clever with crypto is dangerous unless you really know what you are doing.

[formerly_proven]

Do not! Use a combiner / KDF.