2

The common wisdom is that increasing the number of rounds of a block cipher can make it more secure. This is quite true if we consider the linear and differential attacks.

The Tiny encryption algorithm supports this theory. It has a simple round, and it becomes secure after 32 rounds. Even Schneier et. al has the support this theory in their TwoFish Paper.

However, with enough rounds, even bad round functions can be made to be secure.

Even some of last round AES candidates wanted a higher round (32 rounds) [Rijndael].

All of these (and more) support this theory:

$$\text{More round is more secure.}$$

  • Is there any proof of this claim? or
  • Has somebody built a counterexample block cipher that is secure for $n$ rounds but not secure for $n+m$ rounds?
kelalaka
  • 48,443
  • 11
  • 116
  • 196
  • Surely anecdotal evidence proves this? Virtually all cipher attacks are done incrementally versus the number of rounds. You can mathematically generalise the avalanche effect of a primitive (thus prove), but I think you'll struggle to generalise a cryptographic attack against unspecified constructs. – Paul Uszak Jul 07 '21 at 12:35
  • 2
    You might be able to build a dodgy key schedule that nullifies itself when repeated. – Paul Uszak Jul 07 '21 at 12:36
  • @PaulUszak Yes, those are all some thoughts, not proof. Considering against known attacks is not proof either. Looking for some work on this.. – kelalaka Jul 07 '21 at 12:51
  • 3
    Could such a cipher be created? Yes, simply have the rounds mirror earlier rounds after a pivot point - so 16 rounds work normally, next 16 are the reverse of the first 16. So 17 rounds would be equivalent to 15 rounds, 32 rounds to 0 rounds etc. As noticed by another commenter a purposely bad key schedule would be one way to do this. – Brian Jul 07 '21 at 13:57
  • 3
    I'd dispute the "more rounds is more secure" notion entirely. It's better (absent weird self-negating cycles) for the Confidentiality and (in AEADs) Integrity parts of CIA, but it slows the system down and thus reduces Availability. So once the C and I are "good enough" any additional rounds reduce overall security, by increasing the vulnerability to denial-of-service through excessive resource use. Or they discourage people from using the cipher in the first place. TLS being "slow" was a major problem with getting it deployed for decades. – SAI Peregrinus Jul 07 '21 at 14:19
  • @SAIPeregrinus doesn't the main reason for the TLS was slow was the computing power and arithmetic algorithms? In AES, people wanted to be conservative since they feared that Rijndael has less round than common and over the years we may some more attacks. They have insisted that since they were sure about their design and it seems that they are right. – kelalaka Jul 07 '21 at 16:17
  • @Brian do you have any such design somewhere? – kelalaka Jul 07 '21 at 16:18
  • Yes, TLS was slow because the allowed algorithms were slow. Part of that was that early versions (SSL included) only had slower algs available (pre-ChaCha20), part of it was that there was no hardware acceleration for slower algs (AES, DES, etc). These days there's usually either a fast software alg (ChaCha) or a hardware-accelerated alg (AES). Combined with protocol improvements like 0RTT session resumption TLS 1.3 is actually sometimes faster than bare HTTP. But that's recent, and when it was always slower and there was less overhead it lead to people not using it, reducing security. – SAI Peregrinus Jul 07 '21 at 17:06

1 Answers1

6

While more rounds generally increases resistance to attacks (known ones, at least), Biham and Chen showed that 82-round SHA-0 is actually weaker than 80-round SHA-0 [PDF].

(Read "weaker" as meaning "easier to find collisions." And, while you asked about block ciphers, we often consider hash functions as housing internal block ciphers, so I thought it was still a fitting example.)

  • Kudos for the reference. As others have put in comment, it's easy to construct ciphers or hashes where the premise that more rounds help is false to arbitrary degree; but it's a different thing to see it happen in something that used to be promoted as a standard. – fgrieu Sep 04 '21 at 10:44
  • @fgrieu this is what I was wonder. Thanks to Justin to bring this. We learned that it is possible even for the standard and secure systems. – kelalaka Sep 05 '21 at 13:10