Are Two Ciphers Better Than One? i.e. RC4 and AES

Question

OK It's cringe time (or hopefully not)

I know this is probably a variation of an old and dragged out question or so you may think but let me ask away and hopefully get some insight.

Google a while ago famously changed from AES to RC4 because of BEAST. RC4 however, is riddled with all kinds of leaks and problems that are well studied. RC4 can reveal a lot of information to somebody who does not know the key. In theory this can be done. In practice this has been done. WEP being the example that springs to mind strongly.

If we use the same 128 bit key to form some kind of AES (block cipher) encryption. In any mode whatsoever, whether that's ECB or more advisably CBC, CFB or whichever (you get the idea). Then we also run the same data through the RC4 (stream cipher) algorithm: do we have a distinctly stronger, much harder to break cipher-text in effect?

It then goes without saying to decrypt, we just decrypt with RC4 then AES.

Would we solve any weakness issues this way? Or is this just a waste of computing time? Any thoughts really appreciated.

Answer 1

There exist several ways to combine multiple, distinct encryption schemes. Applying one after the other as you propose is one option but you could for example do a secret sharing first and then encrypt the shares with different algorithms. Each of those has its advantages and disadvantages. I am not aware of a combiner for this that provably amplifies security but you can manage to build a scheme that is guaranteed to be as strong as the weakest cipher used in the combiner (as long as you use independent keys of course). The drawback is obvious: You need to do about twice the work when combining two schemes and so on. Depending on the combiner you might also pay in bandwidth (See the secret sharing combiner). These are the reasons why folks hesitate to use this in practice although it would give far stronger long-term security guarantees if key sizes are chosen appropriately.

Answer 2

Cascading ciphers with independent keys is a standard way to hedge against cryptanalytic advances against one but not the other; see, e.g., the Tahoe-LAFS 100-year cryptography design. For two stream ciphers $S$ and $T$ respectively under keys $h$ and $k$ independently chosen uniformly at random, the $i^\text{th}$ ciphertext is $C_i = P_i \oplus S_h(i) \oplus T_k(i)$. You could generically cascade more elaborate things, such as AEAD schemes from CAESAR, in the obvious way.

It has always been foolish to use RC4 since it was broken days after its publication in 1994, but if for some reason you didn't know about that, then in principle if you had combined it with, e.g., AES-CTR using an independent key in your system, learning that RC4 is hopelessly broken wouldn't be so nasty a shock for your system.

However, it wouldn't be very fast to use RC4 and AES-CTR. It would be a lot faster, and provide much higher security, to use Salsa20 instead!

With the exceptions of pathetically broken ciphers known to be bad soon after their publication like RC4, the cipher is unlikely to be the weak point in your system. Beyond picking a sensible widely vetted choice that has withstood over a decade of cryptanalysis like Salsa20 or ChaCha, it's practically guaranteed to be a waste of your time to focus on cascading ciphers instead of the rest of your system's engineering.

For example, the standard attacks on WEP do not rely on weaknesses in RC4 itself; rather they rely on reuse of key streams due to sheer idiocy in the design of WEP to use 24-bit nonces, which, when you use more than a few thousand of them, rapidly become more properly called nwices.

See also https://crypto.stackexchange.com/a/10332/49826 whose conclusion is that cascading ciphers fixes a problem that doesn't exist, and https://crypto.stackexchange.com/a/6498/49826 for some further discussion on the use of cascaded ciphers in TrueCrypt.