Why triple encryption instead of split+encrypt?
Why do people do tripple DES and *shudder* tripple IDEA instead of doing some form of non-redundant secret splitting and then encrypting with multiple keys. For example, instead of triple DES, why not A) divide the compressed plaintext into blocks of n*64 (where n=2 in the simple example, higher in the overkill examples) B) Split each block into n parts such that: i) The splitting can be reversed. ii) During the inverse of the splitting each bit in the plaintext is dependent on several bits from each of the parts of the splittext. iii) The total number of bits in the splittext is the same as in the plaintext. The last point will make this form of secret spliting relatively insecure, but that's OK for this application (I think, this is really what I'm asking you.) C) Now, for each n*64 bit block you have n blocks of 64 bits. Hook these together in n chains and encrypt with DES with different keys in CBC, CFB or OFB mode. D) Unencrypt on the other end. You can make the key size arbitrarily large and it takes much less time than triple DES and its immune to meet in the middle attacks. So why do we use triple DES? If I am wrong about the security of point B-iii, am I correct that by switching to a secure secret splitting algorithm and setting n=2, we still get faster performance for the same cryptanalytical hardness as triple DES? Cheers, JWS
solman@mit.edu says:
Why do people do tripple DES and *shudder* tripple IDEA ^^^^^^^triple.
instead of doing some form of non-redundant secret splitting and then encrypting with multiple keys.
Because people like algorithms that work quickly and don't expand their data by a factor of two or three. As I've noted before, in spite of protestations, the evidence is good that splitting and encryption doesn't by you much over simple superencipherment. Perry
solman@mit.edu says:
Why do people do triple DES and *shudder* triple IDEA instead of doing some form of non-redundant secret splitting and then encrypting with multiple keys.
Because people like algorithms that work quickly and don't expand their data by a factor of two or three. As I've noted before, in spite of protestations, the evidence is good that splitting and encryption doesn't by you much over simple superencipherment.
Although I mentioned "true" secret splitting at the end of my post, I was refering to non-redundant secret splitting in most of the post. That is, for each 128 bit block, you split it into two 64 bit blocks. Obviously you have to make sure that in the inverse of the split, each bit of the 128 is dependent on multiple bits in both 64 bit parts. This is obviously not as secure as traditional secret splitting, but you don't need it to be because this isn't a threshold scheme. You just need to guarantee that knowing one half does not allow you to reassemble the other half. I am claiming that you can allow the crypt analyst to remove half of the entropy from the plaintext (did I phrase that right? probably not :( ) and the other half will still require successful cryptanalysis of DES and since you can't tell if you're right until you get both halves, meet in the middle does not work. So, is a secret splitting algorithm that does NOT increase redundancy followed by DES with different keys on both halves as secure as triple DES? I believe so, but I would like your opinions on the issue before I consider implementing this. If it works it would be especially nice because it allows arbitrary extension of keysize without substantially increasing the time required for computation. I have a hunch that if I'm wrong, its because the time required to do secure non-redundant secret splitting is as large as the time I'm saving. JWS
have you considered
des | tran | des | tran | des ?
My point is that you can get the same level of security with much less effort/computation. BTW, am I incorrect in my belief that the additional security provided by the 32 bit shifting TRAN operation suggested for the 3DEA hardly provides any additional security? (i.e. if they could break 3 IDEA operations or 3 DES operations, they can break them with 32 bit shifting TRAN operations interleaved in just about the same amount of time.) It looks like it would make meet-in-the middle attacks take up substantially more memory and make identifying successful decryptions slightly more difficult, but for security against nearly brute force there isn't much difference between 2^(47) and 2^(47.2) operations. JWS
participants (3)
-
Carl Ellison -
Perry E. Metzger -
solman＠MIT.EDU