4 ms·

I'm no crypto expert, but why is this sort of defense-in-depth not more widely deployed? It seems that standard practice is to choose a single cipher for a mess

I'm no crypto expert, but why is this sort of defense-in-depth not more widely deployed? It seems that standard practice is to choose a single cipher for a message, rather than multiply enveloping the message in different ciphers, perhaps employing different fundamental crypto ideas, so that some future compromise of one of them may not necessarily reveal the plaintext of the present message. Obviously performance considerations may answer this in many, or even most cases, but this seems to be the practice nearly always.

hannob 9y ago
This is rarely used because usually you don't have any realistic expectation that algorithm a may be secure while algorithm b may not be. To put it like this: AES is just good enough, there's no reason to combine it with anything. The post quantum + ecc combination is kinda unique here, because you have two classes of algorithms for which you have very different risk scenarios.
- CorvusCrypto 9y ago
  apples and oranges. With Key exchange algorithms you can get away with this kind of reinforcement. If you start combining encryption algorithms however, you may accidentally reduce the overall entropy of your crypto system by combining algorithms.
  - riffraff 9y ago
    I have often read this, but I don't understand it. Why would `cypherA(cypherB(plaintext))` reveal more than `cypherA(plaintext)` or `cypherB(plaintext)` ? If it did, an attacker might just perform the second encryption and obtain the same result. The only example I've seen is "if you rot13 twice you get back to the start", but that seems a trivially flawed analogy.
    - stouset 9y ago
      You're right that this is an oft-misstated reason for avoiding doing so. Layering encryption this way can only decrease security (in a theoretical sense) if the key and/or encryption algorithms aren't independent of one-another. If both are secure algorithms and you use two independent keys, the composition is at least as strong as the strongest of the two. The real reason is that the risk of a catastrophic AES break is less than the risk of you mis-implementing this feature. As a real world example, take this [bug in OpenSSL](https://marc.info/?l=openbsd-tech&m=144472550016118 https://marc.info/?l=openbsd-tech&m=144472550016118) that was intended to prevent DES weak keys. A more theoretical example of a buggy implementation might be actually a very narrow interpretation of the original point. If you reuse the same key between both algorithms (or, generally, using keys that aren't independent of one-another), it's possible for the second cipher to "undo" the work of the first. A trivial example is AES-CTR(k, AES-CTR(k, pt)), which undoes the original encryption. A less-silly but potentially problematic one might be ChaCha20(k, Salsa20(k, pt)). The two algorithms are different, but very similar in design. There's no known issue with combining them in this way, but it would make me extremely nervous to see such a construct in the wild. So in a sense we've come full circle. As I pointed out, the real reason is that you're more likely to introduce a bug implementing layered encryption than you are to prevent a catastrophic failure of your cipher. But ironically, one of the more likely instances of a buggy implementation is reusing the same key for both ciphers, which is something along the lines of what the grandparent poster indicated. As a postscript, one other reason is performance. AES is hardware-accelerated, but other algorithms aren't (though ChaCha20 is extraordinarily fast in general-purpose hardware). Layering means a performance penalty, which is a generally minor but still very valid reason to avoid layering.
      - madez 9y ago
        Of course you use different keys for the different layers. One uses layering not to compete directly with the underlying cipher but to add a fall-back security. This immediately demands that one must not reuse the key. Since this is simple to understand and to verify, it is far less important than what you make it seem. Also, you then do not get lower security! You still have the full security of the underlying cipher. Why all the scaremongering? Crypyography is a science and craft just like other sciences and crafts. One can do misstakes with severe consequences, but that is the case in other sciences and crafts, too. If more people understand cryptography, the better. We should encourage playing with it, not telling people not to touch it.
  - snakeanus 9y ago
    Only if you use the same keys.
colmmacc 9y ago
Unfortunately layering is not as simple as "defense in depth". Each layer may have its own vulnerabilities, and so the attack surface is increased. There is also a history of issues in mis-matches and side-channels arising in how layers are combined, which can be very subtle. So overall there's a trend to simplicity and as little code as possible.
madez 9y ago
I suggested on HN recently to try a layering approach to incorporate self-made cryptography, but was downvoted to hell for it. This made me aware that even people in tech can be dogmatic.

hannob 9y ago

This is rarely used because usually you don't have any realistic expectation that algorithm a may be secure while algorithm b may not be. To put it like this: AES is just good enough, there's no reason to combine it with anything. The post quantum + ecc combination is kinda unique here, because you have two classes of algorithms for which you have very different risk scenarios.

CorvusCrypto 9y ago
apples and oranges. With Key exchange algorithms you can get away with this kind of reinforcement. If you start combining encryption algorithms however, you may accidentally reduce the overall entropy of your crypto system by combining algorithms.
- riffraff 9y ago
  I have often read this, but I don't understand it. Why would `cypherA(cypherB(plaintext))` reveal more than `cypherA(plaintext)` or `cypherB(plaintext)` ? If it did, an attacker might just perform the second encryption and obtain the same result. The only example I've seen is "if you rot13 twice you get back to the start", but that seems a trivially flawed analogy.
  - stouset 9y ago
    You're right that this is an oft-misstated reason for avoiding doing so. Layering encryption this way can only decrease security (in a theoretical sense) if the key and/or encryption algorithms aren't independent of one-another. If both are secure algorithms and you use two independent keys, the composition is at least as strong as the strongest of the two. The real reason is that the risk of a catastrophic AES break is less than the risk of you mis-implementing this feature. As a real world example, take this [bug in OpenSSL](https://marc.info/?l=openbsd-tech&m=144472550016118 https://marc.info/?l=openbsd-tech&m=144472550016118) that was intended to prevent DES weak keys. A more theoretical example of a buggy implementation might be actually a very narrow interpretation of the original point. If you reuse the same key between both algorithms (or, generally, using keys that aren't independent of one-another), it's possible for the second cipher to "undo" the work of the first. A trivial example is AES-CTR(k, AES-CTR(k, pt)), which undoes the original encryption. A less-silly but potentially problematic one might be ChaCha20(k, Salsa20(k, pt)). The two algorithms are different, but very similar in design. There's no known issue with combining them in this way, but it would make me extremely nervous to see such a construct in the wild. So in a sense we've come full circle. As I pointed out, the real reason is that you're more likely to introduce a bug implementing layered encryption than you are to prevent a catastrophic failure of your cipher. But ironically, one of the more likely instances of a buggy implementation is reusing the same key for both ciphers, which is something along the lines of what the grandparent poster indicated. As a postscript, one other reason is performance. AES is hardware-accelerated, but other algorithms aren't (though ChaCha20 is extraordinarily fast in general-purpose hardware). Layering means a performance penalty, which is a generally minor but still very valid reason to avoid layering.
    - madez 9y ago
      Of course you use different keys for the different layers. One uses layering not to compete directly with the underlying cipher but to add a fall-back security. This immediately demands that one must not reuse the key. Since this is simple to understand and to verify, it is far less important than what you make it seem. Also, you then do not get lower security! You still have the full security of the underlying cipher. Why all the scaremongering? Crypyography is a science and craft just like other sciences and crafts. One can do misstakes with severe consequences, but that is the case in other sciences and crafts, too. If more people understand cryptography, the better. We should encourage playing with it, not telling people not to touch it.
- snakeanus 9y ago
  Only if you use the same keys.

colmmacc 9y ago

Unfortunately layering is not as simple as "defense in depth". Each layer may have its own vulnerabilities, and so the attack surface is increased. There is also a history of issues in mis-matches and side-channels arising in how layers are combined, which can be very subtle. So overall there's a trend to simplicity and as little code as possible.

madez 9y ago

I suggested on HN recently to try a layering approach to incorporate self-made cryptography, but was downvoted to hell for it. This made me aware that even people in tech can be dogmatic.