-----BEGIN PGP SIGNED MESSAGE----- At 04:20 PM 10/27/00 -0400, Arnold G. Reinhold wrote:
At 1:00 PM -0500 10/27/2000, Carskadden, Rush wrote:
Are you guys still talking about the feasibility of a cipher that implements each AES candidate in turn with the same key? I don't really get this idea. Provided you were actually using the same key with each stage of the encryption, then your system is only gong to be as secure as the key of the first algorithm. In fact, it seems that if the key is compromised at any one point, then the entire system is shot, given that you know the algorithm (Kerckhoff's principle IIRC). Maybe I am misunderstanding.
Actually, it doesn't work this way. Nearly all block ciphers are product ciphers, which means you take some relatively short key, derive ``subkeys'' (often in some simple linear way) for each round, and apply the rounds in sequence to get a strong cipher. Each round is weak enough to be broken, usually pretty trivially. So the non-independence of keys for successive rounds isn't generally enough to make the cipher weak.
That is the theoretical question that I am asking. What you say appears to be the conventional wisdom, and I am claiming that it is wrong.
The conventional wisdom is not that it's bad, but that it *could* be bad. There are good reasons to expect that E = Twofish, F = Rijndael with the same key will be no weaker than the stronger of Twofish or Rijndael. But you can at least imagine choices of E and F so pathological that the result is weaker. (I know you understand this, but I think it's useful to state exactly what we mean with stuff like this, especially on a list.)
As long as there is some way to make sure that none of the ciphers in a chain are inverses of the others, or close to an inverse, in some sense, then I claim as long as one of the ciphers is strong, there is no way to get any information out about the keys from the other ciphers, even if they are all designed to reveal that information.
Hmmm. I'm trying to think of what condition you need to specify for this. You need something stronger than ``not the inverse,'' but I am not sure what. If you say ``not too close to the inverse,'' we need to figure out how to measure distance. For example, one way of considering the distance between two permutations E and F is to see what number of inputs x have the property that E(x)==F(x). In this case, you could then talk about E^{-1}(x) (inverse of E(X)) and F(x) needing to have a certain distance. But you have to be careful with that; what do you do when E(x) is Twofish without the whitening, and F(x) = inverse of Twofish without the whitening, and missing the last two rounds? F() and E^{-1}() won't be close at all in the sense of our distance metric.
As a practical matter, you may as well derive the sub keys from the master key using a one-way hash, but I am questioning the theoretical justification for doing that. Massey and Maurer base their paper on oracles that give you the key for all component ciphers but one. I am saying such oracles cannot exist if one of the ciphers is strong and "inverses" of the strong cipher are excluded.
I'll comment more on this from another note of yours. I think you're probably right, but that we need to figure out how to really nail that argument down, which means specifying exactly what's meant by ``close to an inverse,'' or whatever.
Arnold Reinhold
--John Kelsey, Counterpane Internet Security, kelsey@counterpane.com PGP Fingerprint: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use http://www.pgpinternational.com Comment: foo iQCVAwUBOft6CiZv+/Ry/LrBAQH7PwQAtqG0DsDfKxQllVQcWljBK8xjQePZeV4k Z40lMrsVHghwhsfyWqepISENrWJkepbIQ7ECc3TvYkVX4Yh13fZA/xnfoYX++sQx AfnVozmp2an/I0rKdxCB47UGmTqVsiOIVHIHlT18H4UAzOft9/Nu8FPEIwllp8yH aoHSwqS+4EE= =5AUg -----END PGP SIGNATURE-----