Composing large block cipher from smaller ones
in [Cryptography]
|
Prev: No more conservation of telecommunication data in Germany
Next: Final: An obvious pattern found in the first 37Million Prime Sums using the log of the golden ratio Lp!
From: Tom St Denis on 4 Mar 2010 10:10 On Mar 4, 9:45 am, biject <biject.b...(a)gmail.com> wrote: > binary bwts or unbwts you pick with extra key bits or fix the pattern > of bwts unbwts > followed by the 8bit cypher pass with new key bits. The problem with that scheme is there are weak keys consider the key byte 10101010 or 11110000 or 00001111 or 01010101, etc.... they're all identity functions. Generally, it's undesirable for a cipher element to change the size of the message in an unpredictable fashion. That's usually left to the codec stage. Tom
From: Mok-Kong Shen on 4 Mar 2010 10:34 Tom St Denis wrote: > The general idea of a recursive Feistel is well established in the > Turtle paper. The fact you didn't see that doesn't surprise me. > > From Turtle you could make a 64-bit cipher with nothing but random 8x8 > PRFs, you'd have 4 rounds of a 32-bit function, 4 rounds of a 16, and > 4 rounds of a 8 [for 64, 32, and 16-bit feistels respectfully] netting > 4^3 = 64 8x8 functions or 16KB of tables. That's why I said Turtle is more general but is more complicated in implementation in my view. (Of course, I assume that one "already" has e.g. a 64 bit cipher, so the "simplicity" doesn't come from nowhere.) M. K. Shen
From: biject on 4 Mar 2010 11:01 On Mar 4, 8:10 am, Tom St Denis <t...(a)iahu.ca> wrote: > On Mar 4, 9:45 am, biject <biject.b...(a)gmail.com> wrote: > > > binary bwts or unbwts you pick with extra key bits or fix the pattern > > of bwts unbwts > > followed by the 8bit cypher pass with new key bits. > > The problem with that scheme is there are weak keys consider the key > byte 10101010 or 11110000 or 00001111 or 01010101, etc.... they're all > identity functions. > > Generally, it's undesirable for a cipher element to change the size of > the message in an unpredictable fashion. That's usually left to the > codec stage. > > Tom Tom in the basic thing I am not changing the size? 8 bit cipher key 1 8 bits size not changed loop 7 times binary bwts no change in size or binary unbwts 8 bit cipher using next 8 bit key no change in size end loop this doesn't change the file size the size in is the size out however its not wise to allow this for short messages say one byte in length. You should bijective at least force either a minimum size or your could even force some other block size bijectively before you start the encryption. David A. Scott -- My Crypto code http://bijective.dogma.net/crypto/scott19u.zip http://www.jim.com/jamesd/Kong/scott19u.zip old version My Compression code http://bijective.dogma.net/ **TO EMAIL ME drop the roman "five" ** Disclaimer:I am in no way responsible for any of the statements made in the above text. For all I know I might be drugged. As a famous person once said "any cryptograhic system is only as strong as its weakest link"
From: Tom St Denis on 4 Mar 2010 12:39 On Mar 4, 10:34 am, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote: > Tom St Denis wrote: > > The general idea of a recursive Feistel is well established in the > > Turtle paper. The fact you didn't see that doesn't surprise me. > > > From Turtle you could make a 64-bit cipher with nothing but random 8x8 > > PRFs, you'd have 4 rounds of a 32-bit function, 4 rounds of a 16, and > > 4 rounds of a 8 [for 64, 32, and 16-bit feistels respectfully] netting > > 4^3 = 64 8x8 functions or 16KB of tables. > > That's why I said Turtle is more general but is more complicated in > implementation in my view. (Of course, I assume that one "already" has > e.g. a 64 bit cipher, so the "simplicity" doesn't come from nowhere.) Yeah but making a cipher out of a 64-bit PRP is still in spirit just the Turtle cipher. Granted in the case of Turtle the proof of security comes from the difficulty of breaking Feistels with truly random PRFs as round functions. But for a modern example of exactly what you're talking about look at DEAL. Tom
From: Tom St Denis on 4 Mar 2010 12:43
On Mar 4, 11:01 am, biject <biject.b...(a)gmail.com> wrote: > On Mar 4, 8:10 am, Tom St Denis <t...(a)iahu.ca> wrote: > > > On Mar 4, 9:45 am, biject <biject.b...(a)gmail.com> wrote: > > > > binary bwts or unbwts you pick with extra key bits or fix the pattern > > > of bwts unbwts > > > followed by the 8bit cypher pass with new key bits. > > > The problem with that scheme is there are weak keys consider the key > > byte 10101010 or 11110000 or 00001111 or 01010101, etc.... they're all > > identity functions. > > > Generally, it's undesirable for a cipher element to change the size of > > the message in an unpredictable fashion. That's usually left to the > > codec stage. > > > Tom > > Tom in the basic thing I am not changing the size? To be honest I didn't read your entire reply once I saw the obvious flaw in the use of key bits to perform arbitrary bwts/ubwts. That's about as fair statement as you'll ever get from me so take it for what its worth. Tom |