Any disadvantages of using multiple encryption algorithms on same data?

[kbns]

My aim is to encrypt data using multiple encryption algorithms using different encryption keys in a layered fashion for future proof.

I'll use 1. AES-256-CBC 2. RSA with > 8192 key 3. Triple DES 4 Blowfish 5. Twofish 6. CHACHA20

I'm still not sure in which order to use them but please list disadvantages of using this method except size of cypher text.

[zgs]

Another example of "roll your own crypto". Just don't.

Honestly, just stick to one algorithm and use that. Choose something modern. There is no evidence that AES-256 has problems. CBC mode allows some alteration of the plaintext but it's limited and noticeable, best to include an integrity check (HMAC or CMAC).

You really don't want to encrypt bulk data using RSA, it's simply not designed for that.

[brudgers]

One of the stories at the beginning of Volume 2, of The Art of Computer Programming tells of Knuth's early attempt to generate random numbers.

It's a story of a clever kid, relying on intuitions and getting it wrong, because it's mathematics.

Thus he devotes one of his twelve chapters entirely to random numbers.

Unfortunately, it is well established by internet forums that nobody should read Knuth.

[kbns]

"roll your own crypto" means writing a new encryption scheme. But here i'm just using multiple schemes without connection to one another by using different encryption keys.

What if AES-256 gets compromised?

Basically i'm storing my encrypted data online. Anyone can see it but only i can decrypt it.

[zgs]

You *are* inventing a new crypto algorithm.

A symmetric cipher is a permutation, multiple symmetric ciphers in sequence is still a permutation. There has been no analysis done on the latter to determine if the sequence you use hides a weakness. I'd much prefer a well analysed system to an unanalysed one.

[kbns]

> multiple symmetric ciphers in sequence is still a permutation.

No its not. The data feeding to the next algorithm is an already encrypted data from the previous algorithm. Theres 0 connection b/w them.

For example . step 1 . encrypt message (M) with key (K1) using AES to produce cipher text (C1) step 2 . encrypt message C1 with key K2 using TripleDES to produce C2. step n . and so on using all algorithms with different Keys.

I don't see any connections b/w them. 0 entropy. Please correct me if i'm wrong.

[zgs]

It's still a permutation: shuffling a deck of cards again doesn't make it any more random (apologies to Diaconis). A symmetric cipher is just a shuffle -- no more, no less. Sure, it "feels" unlikely that there would be a problem but can you prove that or prove at least some level of confidence in it?

The bottom line is just AES is good enough. Your data almost certainly isn't worth the effort involved for an attacker even if there was a substantial breakthrough against AES. If it was worth enough, there are far cheaper and easier ways to get access than breaking the crypto: https://xkcd.com/538/

Modern symmetric crypto is secure enough: any problems you hear about are not in the algorithms. Cracking crypto as seen in movies is a complete fiction, it doesn't work like that.

I suggest reading some introductory texts on cryptography to fill knowledge gaps.

[kbns]

Thank you. i will learn more about it.

[crapto]

It will be slower to encrypt and decrypt, and a bit more complicated due to the multiple layers and managing the keys to encrypt and decrypt it all.

There's no disadvantage in terms of algorithmic secrecy.

[mitchellpkt]

I agree. There are various complexity downsides (implementation, key management, etc) but it should be fine from a practical cryptographic security perspective.

While I can't offer you a formal cryptanalysis, I do have a handwave-y thought experiment & proof by contradiction for intuition:

Consider two encryption algorithms A[...] and B[...] that are "good" in the standard ways (adversary cannot decrypt messages without keys, keys cannot be leaked by chosen plaintext attack, etc).

If putting A inside of B like B[A[...]] renders the system insecure, it would imply that B[...] was not a "good" encryption function! (if it was good, it would not break just because the input message happens to be the output of A[...]).

Therefore by handwave-y proof by contradiction, if A[...] and B[...] are "good", then A[B[...]] should be OK.

(Disclaimer: Again, this is a casual thought experiment and not real cryptanalysis. This result may not be true under formal cryptanalysis.)

[kbns]

Thank you. Since i'm using this to encrypt backups, speed is not a problem.

[tkiolp4]

One disadvantage is that now you have N keys instead of 1, plus you need to remember the deciphering order.

[hknmtt]

it's pointless. just use strong key(32 bytes) for aes which has native hw support everywhere these days.