The RC6 symmetric block cipher is parameterized with three parameters :

  • W : The number of bits in a machine word (8 , 16 , 32 , 64)
  • B : The number of bytes specifying key length (0 to 255)
  • R : The number of rounds to execute (1 to 255)

A data block is specified as 'uint_t data [4]' where 'uint_t' can be 8, 16, 32, or 64 bits resulting in a 32, 64, 128, or 256 bit data block size respectively.

These parameters allow the end user to select block size, key size, and to trade off performance for security.

The question I have is : Given parameters W and B, along with a desired security strength (not sure how to specify this exactly, but it depends on R), how does one determine the minimum value of R to ensure this minimum security bound?

ie: I desire to parameterize an instance of RC6 for a 256 bit data block (W = 64) and a 256 bit key (B = 32). I would like the cipher to have 256 bits of security (that of the key B) which clearly depends on the value of R. Assuming a full 256-bit key is used, what is the minimum number of rounds (R) required to ensure full diffusion and security equivalent to a brute-force search of the 256 key?

I have researched the original RC6 specification, alternative research papers that I could find which discuss various attacks on RC6, etc. but I have not yet seen any summary, equation, or guidelines on how to select values of R for tailored instances of RC6.

It seems to me that without an equation or clear instructions on how to select R, the specification is not 100% complete and layman implementing the cipher for a practical application will be left guessing, which will cause bad things to happen.

Note : I am not an expert cryptographer, but I do know enough not to "roll my own" and follow a standard to-the-letter. This standard, while awesome, seems to be missing a letter... :)


In the case of AES, they had a lower bound on the highest probability differential (and the analogous linear hull), and they were able to use that information to determine at how many rounds would be required for a differential (and analogous linear) attack of a specific cost.

Ideally, that is how you would proceed.

However, Rijndael (later AES) has some specific properties that enable such a calculation to be made. All of the constituent operations are very cleanly and precisely defined, and they operate on sizes that are small enough to enable such analysis to take place.

With ciphers built from bitwise and arithmetic operations ad-hoc*, especially when those operations function on large words, finding the worst-case differential probability is more challenging, if/when it is possible.

You can find the sort of average worst-case probability (which is not really the worst-case) and make the calculation for rounds using that, but that does not prove that no attack costs less then the desired amount, because there could be some higher probability differentials you don't know about yet.

Still, that is probably the best strategy you have.


You can only perform this type of process for attacks that you know of already. You could prove that no basic differential attack costs less than $\frac{1}{2^n}$, but that does not mean that no attack costs less than $\frac{1}{2^n}$.

* Technically the operations in Rijndael are built from bitwise and a certain type of arithmetic operations - but all circuits are powered by these, at the circuit level.


I think that unwittingly you are "rolling your own". You have to consider:-

  1. The purpose of RC6 was to win the AES competition, set to block sizes of 128 bits and key sizes of 128, 192, and 256 bits. All of Ron's paper implies that in every mention of RC6-w/r/b.

  2. He said "While the submission of RC6 for consideration as the forthcoming AES is based around the use of 32-bit words (giving a block size of 128 bits), future developments and market demand might encourage an extension of RC6 to other block sizes."

  3. All his security analysis is based on a 32/20/16 configuration. See Table 12, Differential Cryptanalysis of RC6. It only considers rs of 8 to 24.

  4. Ron repeatedly recommends 20 rounds, clearly with an eye on competitive performance but nevertheless maintaining security.

The inevitable conclusion is that he specifically worked towards the competition entry, and extended modes might be future work. That's fair considering his situation. So expanding to 64/?/32 strays into unknown territory. This explains your failure to find detailed analysis of tailored configurations.

But also consider that AES at a block width of 128 bits is probably the best there is in the world currently. It's certainly been hacked, dissected and analysed to the very edge of death but still survives. No one is screaming that AES is insecure.

This then leads to two final recommendations:-

One, if you accept that AES is world beating at 128 bits, use RC6 in Ron's recommended 32/20/16 configuration. Apparently the NSA use it as well.

And two, Luby /Rackoff proved that secure Feistel functions only need three rounds without mention of block width. So that proof is block independent. If RC6 is recommended at 20 rounds, I personally would double that and go with a round count of 40 for a block width of 256 if you want to try a custom job. I can't mathematically prove that's secure, but I'm willing to bet there's few folk in the world that can prove otherwise.


The number of rounds is determined by statistical analysis such as differential, linear and others. The default number of rounds of RC6 is 20. According to The Twofish Team’s Final Comments on AES, the safety factor (number of rounds/number of broken rounds) of RC6 is 1.18 (20/17) while it is higher for serepent and twofish. in engineering , the safety factor is generally range from 1.2 to 3.

the differential and linear analysis is search-based of minimum differential/linear trails process and it is not easy for RC6 because of the ARX structure and the variable rotation value. you also need to take into consideration while you increase the number of rounds , the performance time will degrade.


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.