Schneier on Security

Clive Robinson • November 23, 2009 2:38 AM

@ Brad Conte,

“For those still interested in more on the definition of a tweakable block cipher”

Or to put it another way,

“when is a key not a key?

Or more poeticaly “A rose by anyother name would smell as sweet”

There are various answers to this depending on what you change and how.

Back with DES we had a fixed data transposition that gave rise to the idea of modifing the data into the block cipher either in a fixed or changable way (think about the Unix password system).

This gave rise to the idea of “whitening” where you xored the data with a changable value (equivalent of an IV). And also a progamable permutation has been touted for software only systems (the hardware takes up to much real estate). Neither method is in it’s self is a secure step but it significantly adds to other issues for cryptoanalysis in a cheap and easy way.

You could look on it as a “pre-ciphering” of the data. I and others at various points in time proposed using a stream cipher instead of a fixed IV to do the same thing but get real strength out of the process for little extra cost (the down side is syncing up the system but there are ways to making it self syncing).

Like wise you can “whiten the key” in various ways before, during and after key expansion. Again by permutation or substitution as a fixed IV or via a stream cipher (which again I and others have proposed at various points in time for both software and hardware implementations).

None of the above in the general case should overly effect the strength of the block cipher design (yes I know there are specific cases to prove the “Don’t do it Jim” rule 😉

Then you can look at the actual data ciphering and this is where it can get a bit dodgy on the strength of the cipher.

If you loosly assume that a block cipher is based on a Fiestel network of some kind then you have the one way functions and the reversable mixing functions.

You can “moderately” safely apply whitening in all it’s forms to the inputs and outputs of the one way and mixing functions.
You can also take reversable data flow switching (block permutation) on more complex Fiestel mixing as well as the number of rounds. These can and will in most cases effect the strength of the block cipher so considerable care has to be excersised in both the design and selection of the control input.

It is arguable (and has been) that this is a very desirable idea because if somebody copies your design without knowing what is good and bad then you have a system that is always strong for you. But has the highly desirable feature (in some circles) that on occasions it will be considerably weaker for those who’s traffic you might wish to look at.

This is kind of doing an end run around the
Kerckhoffs’ axiom (restated by Claude Shannon) of “The enemy knows the system”. Effectivly it gives your opponent what is occasionaly a “stealth” trojan horse…

You can then start to play with the way the oneway and mixer functions actually work for instance instead of XOR across a byte you might use add/subtract or even a more complex function (a reversable DSP MAD for instance).

One method that has been around for many years is “programable S-Boxes” or State arrays.

The problem is not so much what we call things (whitening, tweekable, programable, etc) but that in many respects they are to general to be specificaly meaningfull (concepts not actuality) except in a clear context.
And as we know from “software specs” this is where things go astray.

Perhaps the “concepts” need a taxonomy developed as a framework in which specific implementations can be pigeon holed.