Changing algorithms during encryption

Question

Inspired by "Guarding against cryptanalytic breakthroughs: combining multiple hash functions", I am curious if there is a cryptographic reason to use only one algorithm during encryption.

For example, start with Blowfish, move to AES, switch to DES, etc, in a defined, but semi-unpredictable fashion (maybe basing which one to choose next off the last 4 bits of the most-recently-encrypted block's original plantext).

Would changing algorithm (but keeping the key identical, for sake of argument) have any cryptographic value? Could such a scheme be more resilient to cryptanalysis?

Answer 1

As many of the other answers have said the proposed method above is only as strong as the weakest cipher used (this is especially dangerous if the same key is used for all the ciphers).

Furthermore, basing the cipher transitions on the plaintext opens up the door to a range of timing side-channel attacks if any of the ciphers are faster or slower that each other.

One way you could guard against cryptanalytic breakthroughs is to use secret sharing to split a message $m$ into $n$ plaintexts ($p_i$) that must be combined to recover the original message. $$ m = p_0 \oplus p1 ... \oplus p_n $$ These $n$ plaintexts could then be enciphered by $n$ ciphers.

$$ciphertext = cipher_0(key_0, p_0)|cipher_1(key_1, p_1) ... |cipher_n(key_n, p_n)$$

The size of the ciphertext increases with the number of ciphers (size of message $\times n$), but you could ensure that even if $n-1$ of the ciphers were broken the message would remain secret. This also requires $n$ keys.

One could try some sort of key expander to expand a $key$ to a different key for each cipher:

$$key_0 = cipher_0(cipher_1( ... cipher_n(key, key)), cipher_1( ... cipher_n(key, key)))$$ $$key_1 = cipher_n(cipher_0( ... cipher_{n-1}(key, key)), cipher_0( ... cipher_{n-1}(key, key)))$$

but I don't have much faith its security (theoretically it is probably as weak as it's weakest cipher) and when one is so concerned with cryptanalytic breakthrough it would be foolish to introduce a "trusted" key expander (why not then introduce a trusted cipher and use that). I have asked the key expander issue as a separate question ( Designing a key expander out of ciphers ).

Answer 2

What you are effectively doing here is creating a new algorithm somehow composed of all these individual algorithms.

In effect you'll have something that is really complicated, and thus hard to analyze - which does not mean hard to break, but hard to estimate the strength.

It is not really clear whether it would be any better than the weakest of the combined algorithms, and even less whether it would be better than the strongest of them. Also, it most likely will be slower than any single algorithm (since each of them has a different kind of key schedule).

Don't do it.

If you really feel you need to combine multiple algorithms to guard against one of them having been broken, encrypt the data with both (one after the other), preferably with different keys. (Though this will not give you ($2·n$)-bit security, I think, only guard against attacks against one of the algorithms, it will take double the computing power.)

Answer 3

Seems to me that it makes it easier on the attacker; that way, if he knows of any weakness in one of the ciphers you use, he can recover that part of the plaintext. And, the fact that "he doesn't know which parts are encrypted by what" doesn't really hinder him, he can guess.

In addition, basing it on the plaintext means that if the attacker knows the plaintext (say, you're transmitting boilerplate), that means that he knows which cipher you're using, and so he doesn't have to guess.

Using the same key for all the ciphers makes things even worse; that means that if he does recover (say) the 56 bit DES key, he then knows 56 bits of your AES key.

Using N different ciphers makes sense only if you're secure if any of them are secure (and there are ways to do that). What you proposed means that you're secure only if they're all secure -- you'd be better off picking one, and sticking with that.

Answer 4

As you've proposed it, it's a pretty lousy idea.

To have any hope of gaining security, start with a separate key for each cipher, and apply the ciphers serially to to every block -- i.e., encrypt block 1 with cipher A, then with cipher B, then with cipher C (but I reemphasize, using a separate key for each).

With that, unless the ciphers form a group (unlikely, at least if they're worth anything) the attacker will have to break all three ciphers to recover any part of the plaintext.

The disadvantage, of course, is that encryption and decryption require (roughly) triple the resources. OTOH, given the availability of quad-core processors, it would be fairly easy to set it up as a pipeline that ran about the same speed as the slowest individual cipher (at the expense of using more cores to do it).