1
$\begingroup$

Why isn't data encrypted with multiple uncompromised (so far) ciphers? Feel free to answer for a single private key for both and separate private keys.

For example, encrypting data with TwoFish and then AES?

Is it a matter of doubling resource consumption vs a small security improvement? Can two ciphers together be weaker than either cipher separately (in practice or theory)?

If the latter, why not apply one cipher to the data and one to a one time pad and transmit both? ( Can a message and one time pad each encrypted with separate ciphers be weaker than the stronger of either cipher? )

If I understand 2DES doesn't give you nearly the bump in security you'd think it would vs 3DES. But IIRC 2DES is still stronger than DES.

Improve this question
$\endgroup$
7
  • $\begingroup$ Occam's razor $\endgroup$
    – fgrieu ♦
    Apr 16, 2020 at 18:47
  • $\begingroup$ VeraCrypt Order of multiple encryption algorithms $\endgroup$
    – kelalaka
    Apr 16, 2020 at 18:50
  • $\begingroup$ @fgrieu Fair enough. I was hoping for a more technical reason if there is one :-) $\endgroup$
    – Tyler Spaeth
    Apr 16, 2020 at 18:50
  • $\begingroup$ @kelalaka Since cipher do get broken over time (not always but it happens), for sufficiently important data, having twice (or more) ciphers that have to be broken seems like win unless it's easier to break composed ciphers or at least the added security is low compared to each individually. Just wondering if I'm missing something there. $\endgroup$
    – Tyler Spaeth
    Apr 16, 2020 at 18:53
  • $\begingroup$ Actually, in the cryptographical sense, If the cryptographers cannot make a secure cipher, they cannot make two secure ciphers. What you are talking about is risk analysis. I'm pretty sure that multiple encryptions with different algorithms are common around, $\endgroup$
    – kelalaka
    Apr 16, 2020 at 19:04

1 Answer 1

Reset to default
2
$\begingroup$

Why isn't data encrypted with multiple uncompromised (so far) ciphers?

  1. Since about 1980, when modern widely deployed symmetric encryption actually fails on the field, that's not due to a theoretical break of the cipher, because the art/science of making ciphers has matured¹,². Successful attacks are on compromised or leaking implementations, key management/generation, short keys (perhaps deliberately³), operating mode, and human factors, which are issues that multiple ciphers do not solve. Hence multiple ciphers would only guard against a risk that now fails to materialize.
  2. Before about 1990-2000, strong crypto was illegal for civilians or discouraged, including in many western countries. Thus multiple cascaded ciphers could not be widely⁴ used in commercial products when they where most useful: before the knowledge to make good crypto became commonplace.
  3. Multiple ciphers add complication, and complex systems fail more.
  4. Multiple ciphers increase the computational cost of encryption, and the cost of hardware when hardware is used (as is increasingly the case for AES, the de-facto standard for built-in-CPU cipher nowadays).
  5. If multiple cascaded ciphers use the same key, the security can become that of the weakest cipher, especially against side-channel attacks, which are among the ones that do happen. Therefore we need multiple keys for multiple ciphers, which goes against usability, or/and introduces more complexity.

¹ The closest thing to an exception is RC4, but most actual attacks against systems using RC4 are due to poor key management/operating mode. Also, RC4 was initially used for applications with 40-bit security.

² Asymmetric encryption, signature, and hashes matured later, say 2000.

³ That's why DES has a 56-bit keys, see this. Another example is GSM's A5/1, which is breakable mostly because it uses a small state, presumably because authorities wanted to be able to break it (though I lack a clear reference proving that assertion).

⁴ There are a few examples of cascaded encryption used in disk encryption products where it is an option to damp paranoia / an accessory for security theater. It's an option in TrueCrypt/VeraCrypt, and the successful attacks against this product work irrespective of use of this option.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Interesting point on complexity. Even if it means you have to break two ciphers, the software that implements and combines them is weaker per it being more complex. And the latter is tends to be lower hanging fruit if I understand correctly. $\endgroup$
    – Tyler Spaeth
    Apr 16, 2020 at 21:15
  • 1
    $\begingroup$ I would not quite so strongly discount the possibility of future breaks of cryptographic mechanisms. Nothing of what you say is wrong here (although there have been spectacular failures of symmetric-key crypto, e.g. see OCB2 mode which was for a long time believed by the community to have a security proof), but on the other hand 50 years of failure to do something do not show that it is impossible to do. For instance, the AI community has consistently failed to deliver general intelligence, and yet by the example of the human brain we definitively know it to be possible in a small machine. $\endgroup$
    – Polytropos
    Apr 16, 2020 at 22:30
  • $\begingroup$ @Polytropos: good points. Yes, there's OCB2, and other failures of standardization when it comes to crypto: ISO/IEC 9796(-1) for RSA/Rabin signature with message recovery, ISO/IEC 9797-1 for MACs based on block ciphers, countless examples in higher layers like Wifi. I note that the higher in the layers the mistakes are, the more they tend to be exploitable. And I see these as illustrations that the problem is not the crypto primitive / cipher itself; but rather, how it is used. Stacking ciphers would add security where there has been essentially no problem, and miss the actual weak points. $\endgroup$
    – fgrieu ♦
    Apr 17, 2020 at 5:08
  • $\begingroup$ @fgrieu Having thought about it more, passively stored data rather than active transmission would be where this sort of problem might apply the most. But if you know who's data it is, and they have the key somewhere... someone at that organization is either willing to trade their password for a Snickers or half the organization is using an old version of Outlook. I'm thinking attacking the keystore is much, much easier than attacking the algorithm OR library. $\endgroup$
    – Tyler Spaeth
    Apr 19, 2020 at 18:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.