3
$\begingroup$

I've encountered some papers online describing ciphers made through a combination of stream and block ciphers. (See this 2008 paper by Sandy Harris: https://eprint.iacr.org/2008/473.pdf) In a nutshell, the concept is to use the output of a stream cipher to add whitening and/or update the round keys of a block cipher. The paper referenced above describes a combination of AES and RC4. Other examples of this concept I've seen are a cipher called Eris, combining HC128 and Serpent, and a cipher called Enchilada, combining ChaCha and Rijndael. Enchilada was an entry in the Caesar authenticated cipher contest but was withdrawn in the initial rounds.

The security claims for these combination ciphers are impressive. Standard attacks against the stream cipher portion should be thwarted by the block cipher, and attacks against the block cipher should be complicated by the use of unique round keys for each block of cipher text. The speed of these combination ciphers can be comparable to (or even better than) the block cipher by itself, because the number of rounds in the underlying ciphers can be reduced. (For example, Enchilada runs 12 rounds of ChaCha versus the standard 20, and Eris uses 24 round Serpent, versus the standard 32 rounds).

What I have not been able to find is any cryptanalysis or research on these types of combination ciphers. On the surface, and with my limited knowledge, there appear to be more advantages than disadvantages to this approach. At the very least, it looks like a promising topic for research. Yet the fact that there is so little information in the literature suggests these combination ciphers have flaws I am unaware of. Which brings me to my question: what are the disadvantages or weaknesses of this combined approach?

$\endgroup$
3
$\begingroup$

The security claims for these combination ciphers are impressive. Standard attacks against the stream cipher portion should be thwarted by the block cipher, and attacks against the block cipher should be complicated by the use of unique round keys for each block of cipher text.

This might or might not be correct. You claim that if I combine two insecure ciphers I should get secure cipher. This will often be incorrect. Worse, flaws in one cipher can weaken security of other one. Or feeding random data instead of secure static data can weaken security, as some research shows, for example here.

The speed of these combination ciphers can be comparable to (or even better than) the block cipher by itself, because the number of rounds in the underlying ciphers can be reduced. (For example, Enchilada runs 12 rounds of ChaCha versus the standard 20, and Eris uses 24 round Serpent, versus the standard 32 rounds).

So now you combine two ciphers and reduce their strength, and claim that I should get double security. This is obviously wrong. Also, ChaCha12 is valid (and somewhat normal) choice of rounds, not a reduced version. Since they do more than just ChaCha12, they can't be faster than ChaCha12. And security might be improved or worsened.

what are the disadvantages or weaknesses of this combined approach?

  • Those ciphers are new and haven't had proper cryptoanalysis
  • Those ciphers are slower than their single (and unbroken) counterparts
  • Those ciphers have poor implementation support
  • Those ciphers seem to mess around with basic ciphers in hope of creating something secure and fast. In turn they seem to rely more on obscurity than security.

So to be honest, there is no reason to use those ciphers when we have many unbroken, fast and verified secure algorithms. Those multiciphers (or extended ciphers, like AES with 2048bit keys) often rely on scare that everything broken, and make unfounded promises that they can make it better. Truth is often opposite, because you can't extend key and improve speed at once, as that decreases confusion (and because of that security).

If you are scared of one of ciphers being broken (for example in next 50 years), use multiple ciphers with multiple keys (at cost of speed). Then you at least have security of last of ciphers. Don't combine their cores in hopes of making something secure, as this can reduce security. Messing with design without understanding why choices were made is easy way to reduce security.

$\endgroup$
  • $\begingroup$ > You claim that if I combine two insecure ciphers I should get secure cipher No, I'm not actually claiming anything. I'm just wondering if it's true, and if not, why not. $\endgroup$ – mcd0001 Dec 28 '16 at 22:17
  • $\begingroup$ I was hoping for something more concrete, along the lines of "this approach should not be used because of X, Y and Z". I just don't know what X, Y or Z might be. $\endgroup$ – mcd0001 Dec 28 '16 at 22:18
  • 1
    $\begingroup$ Well, if you expect at least partial analysis of each cipher, it would require team working for few months at least. I can only go with general rules and already published papers (and there aren't any proper papers on those because of reasons I provided). $\endgroup$ – axapaxa Dec 28 '16 at 22:53
  • 1
    $\begingroup$ Agree, the paper's approach is a bit far from the mainstream, and it is known that applying two ciphers in sequence can be as weak as the weakest of the two in the worst case, hence the lack of further examination of the claims in the paper. Perhaps this can be a research project for the OP. $\endgroup$ – kodlu Dec 29 '16 at 1:02
  • $\begingroup$ Such a research project would be beyond my meager capabilities. I haven't even been able to follow simple examples of differential attacks on toy ciphers! It just seems to me that a cipher using the same round keys for the life of the key would be much easier to break than a cipher where the round keys changed every block, and I was curious why real-world ciphers did not take such an approach. $\endgroup$ – mcd0001 Dec 29 '16 at 13:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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