[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.

[0xDEAFBEAD]

This is a great point. If layering encryption really does introduce new attacks, that suggests encrypting single-layer ciphertext could allow you to perform that layered-ciphertext attack anyways. So I find myself skeptical of chowells' claim here.

Here's Wikipedia: https://en.wikipedia.org/wiki/Multiple_encryption

I'm no expert here, but if I understand Wikipedia correctly:

* Be sure to use distinct keys and IVs for each individual layer.

* Be aware that encrypting ciphertext could lead to a known-plaintext attack on the outer cipher, if the inner ciphertext starts in a standard way (file header etc.)

[bawolff]

One thing you do have to be careful about is layering hash functions, which generally does not work.

[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.

[0xDEAFBEAD]

Curious why this is being downvoted.

[formerly_proven]

Clearly Big Pentest wants to have work in the future.

[chowells]

Almost certainly because of the inappropriately aggressive tone for what would otherwise be a nice clean clarification. I just said "split" and "combine", making it possible to believe I literally meant "put half the bits in each". That's so bad of an idea that I was sure no one would think I meant that. But I can see how I wasn't clear enough. An additional clarification is good info.

But the way it was posted is so inappropriately aggressive that I think people were downvoting based on tone alone.

[0xDEAFBEAD]

>That's so bad of an idea that I was sure no one would think I meant that.

Not everyone who reads these HN threads is a cryptographer. It didn't raise serious red flags for me when you mentioned that. I figured it should be OK as long as you make the size of the key twice as large. Is that wrong?

[chowells]

The problem is that no commonly-used symmetric cipher has been studied nearly as heavily with larger keys. 128 bits for a symmetric cipher is enough for all practical purposes barring a cryptographic break, and it gives the best performance. Their constructions aren't so trivial that you can just extend the existing study to larger key sizes mechanically. Using larger key sizes basically means using new ciphers. Unstudied ciphers.

It's much more conservative on your novelty budget to use a well-studied 128-bit cipher along with a well-studied key derivation function. In cryptography, you really should be as conservative as possible with your novelty budget.