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: Mok-Kong Shen on 4 Mar 2010 16:19 Tom St Denis wrote: > 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. Spirit or not, let me say that recursive use of something is actually a platitude in programming (if one knows some amount of programming at all). What I wanted to point out is simply the fact (which seems not to have been popularly shown) that one can "very simply" exploit an "already existing" block cipher, especially doing in the form of what I termed the "horizontal" case. "Simpler" pieces of codes are actually quite rare in practice. I have not yet managed to check with the detailed document of DEAL, but off-hand I highly doubt that the coding structure there could be "more simple" and straightforward than what I have in the original post. M. K. Shen
From: Tom St Denis on 5 Mar 2010 06:50 On Mar 4, 4:19 pm, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote: > Tom St Denis wrote: > > 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. > > Spirit or not, let me say that recursive use of something is actually > a platitude in programming (if one knows some amount of programming > at all). What I wanted to point out is simply the fact (which seems > not to have been popularly shown) that one can "very simply" exploit > an "already existing" block cipher, especially doing in the form > of what I termed the "horizontal" case. "Simpler" pieces of codes are > actually quite rare in practice. I have not yet managed to check with > the detailed document of DEAL, but off-hand I highly doubt that the > coding structure there could be "more simple" and straightforward than > what I have in the original post. No, see you don't get to invent terminology for things that already exist. That makes you sound more like a crank than you already are. Go read the damn DEAL paper. And the reason people don't do recursive ciphers is that they're normally horribly slow and inefficient. So stop barking up the wrong tree, specially if you're not going to actually read the existing literature on the subject. Tom
From: Mok-Kong Shen on 5 Mar 2010 17:34 Tom St Denis wrote: > No, see you don't get to invent terminology for things that already > exist. That makes you sound more like a crank than you already are. > Go read the damn DEAL paper. > > And the reason people don't do recursive ciphers is that they're > normally horribly slow and inefficient. So stop barking up the wrong > tree, specially if you're not going to actually read the existing > literature on the subject. I got yesterday this link: http://www2.mat.dtu.dk/people/Lars.R.Knudsen/newblock.html But my Adobe Reader claimed that the pdf-file was damaged and could not be opened. Further I failed to get stuff from: http://www.ii.uib.no/~larsr/newblock.html That's why I wrote in the previous post that I hadn't yet managed to read the document. Just now I accessed http://www.schneier.com/paper-deal.pdf. I see that DEAL has 128 bit block length and rests on 2 underlying DESs but with all different keys in the different rounds, with these round keys determined in a key schedule of DEAL's own. O.k. using different keys in different rounds may indeed be better, I don't know. In my post I use the same keys throughout the rounds and rely on having a sufficient number of rounds to achieve satisfactory result. On the other hand DEAL deals only with 128 bit block length and not larger block lengths. There seems to be no indication by DEAL's author how one would do with, say, 256 bit block length. To your last paragraph: Certainly, if one have and can spend enough resources (time and man power), then one could develop a new cihper with good efficiency. But, if for whatever reason, one wants to have a block cipher of very big block length but can't afford to design one from scratch, then using an already existing block cipher to do the desired work is very well a reasonable way to go in my view. Or what would you say to this? M. K. Shen
From: Maaartin on 5 Mar 2010 18:43 On Mar 5, 11:34 pm, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote: > I got yesterday this link:http://www2.mat.dtu.dk/people/Lars.R.Knudsen/newblock.html > But my Adobe Reader claimed that the pdf-file was damaged and could not > be opened. It's not damaged, it's gzip-ed (and transfered probable with a wrong mime type). > Further I failed to get stuff from:http://www.ii.uib.no/~larsr/newblock.html That's why I wrote in the > previous post that I hadn't yet managed to read the document. > > Just now I accessedhttp://www.schneier.com/paper-deal.pdf. I see that > DEAL has 128 bit block length and rests on 2 underlying DESs but with > all different keys in the different rounds, with these round keys > determined in a key schedule of DEAL's own. > > O.k. using different keys in different rounds may indeed be better, > I don't know. In my post I use the same keys throughout the rounds and > rely on having a sufficient number of rounds to achieve satisfactory > result. In the case of DES it is much better as the key length of DES of only 56 bits is AFAIK it's greatest weakness and the reason for AES. > To your last paragraph: Certainly, if one have and can spend enough > resources (time and man power), then one could develop a new cihper > with good efficiency. But, if for whatever reason, one wants to > have a block cipher of very big block length but can't afford to > design one from scratch, then using an already existing block cipher > to do the desired work is very well a reasonable way to go in my view. > Or what would you say to this? I've found some pointers to design of such a large block cipher http://en.wikipedia.org/wiki/All-or-nothing_transform http://en.wikipedia.org/wiki/BEAR_and_LION_ciphers
From: Mok-Kong Shen on 5 Mar 2010 18:58
Maaartin wrote: > I've found some pointers to design of such a large block cipher > http://en.wikipedia.org/wiki/All-or-nothing_transform > http://en.wikipedia.org/wiki/BEAR_and_LION_ciphers But how much work you would need that way as compared to the almost trivial coding in my original post? M. K. Shen |