# Cipher that interleaves rounds from other ciphers?

Is there a cipher that interleaves rounds from other ciphers (with the same block size)? For example, interleaving the rounds of AES/Twofish/Serpent/RC6?

• I guess that would require compatibility of the internal state and key schedule. – Maarten Bodewes Feb 23 '17 at 20:07
• @MaartenBodewes I was thinking it could be done by leaving each cipher's key schedule alone, just passing the intermediate ciphertext block from cipher to cipher. So the internal state size would be the sum of the internal state sizes of the constituent ciphers. – DepressedDaniel Feb 23 '17 at 20:10
• I have several such designs, only 2 of them are semi-public in design but not source code, and those are not suggested to use in practice – Richie Frame Feb 23 '17 at 21:32
• @RichieFrame I guess if you say "yes" and link to the two semi-public designs then this would automatically constitute the most complete answer; there aren't any other requirements listed by DepressedDaniel. – Maarten Bodewes Feb 23 '17 at 21:37

## 2 Answers

kodlu mentions the interactions of the key schedules; with such a design, I would worry far more about the interaction between the round functions themselves.

A single round of AES, Serpent, Twofish, RC6 has high probability linear and differential characteristics; there's a reason why we have multiple rounds. Now, the round functions within these ciphers are designed so that they play nicely with themselves; that while (say) a single round of AES has high probability characteristics, these high probability characteristics do no apply to multiple rounds. That is, while we can find a high probability characteristic for a single round, we cannot join these high probability characteristics across multiple rounds. This isn't by happenstance, the designers of these ciphers deliberately set things up this way.

This is not necessarily true while you mix-and-match round functions; while we can't find a high-probability characteristic that goes through several AES round functions in succession, there's nothing that says we can't find a characteristic that goes through an AES round function, followed by a Serpent round function, followed by a Twofish round function. I'm not saying there is such a characteristic; I am saying it would appear foolish without doing a whole lot of analysis first.

If you feel an absolute need to do this sort of thing, it would make a lot more sense to keep the round functions from the same cipher together; do a bunch of AES round functions, followed by a bunch of Serpent round functions, followed by a bunch of Twofish round functions. There, we can at least leverage some of the security proofs inherent within the separate ciphers.

• Being more of a hardware person and a self-declared novice at cryptography, does a cipher exist where the block logic changes everything round? Effectively, this is what you are describing describing here. Just from the standpoint of linear cryptanalysis, you could have an interesting progressive function. In hardware, I could implement this by just using the "round counter" to select a different mux for a bit in a Feistel network, or a different entry for a SPN. Are there any examples of this as I would love to see how it would be analyzed. – b degnan Feb 24 '17 at 14:15
• @bdegnan Such a thing exists. It is called a block cipher. From a hardware stance, you do want multiple, largely identical rounds, not one huge round. – Maarten Bodewes Feb 26 '17 at 14:19

I am not aware of any such design.

It would be complex (more complicated than just composing the ciphers, which is not of clear benefit either, by the principle of weakest link) and inefficient since you'd have 3 times as long keylength.

Worse, it would be much much harder to cryptanalyze than straight composition, and thus no one would take it up. You'd need to consider interactions of 3 key schedules, and different design philosophies of the components may introduce unforeseen weaknesses.

• Why "weakest link"? If we assume the keys are completely independent I don't see how a break of B allows you to break A(B(C()))). Certainly you can't expect 3k security if each cipher has k security, but you should get at least k security if up to two ciphers are broken. – DepressedDaniel Feb 23 '17 at 20:57
• That's just a general principle, from a conservative point of view. If you are assuming all the ciphers are secure what's the point of your inefficient design? – kodlu Feb 23 '17 at 21:13
• Well intuitively it ought to scramble things up better than more rounds of the same thing. – DepressedDaniel Feb 23 '17 at 21:17