From: Mok-Kong Shen on
Maaartin wrote:
> Mok-Kong Shen wrote:
>> 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.

However, developing one's own keyschedule like in the case of DEAL
demands high expetise. The scheme I suggested is sort of "poorman's"
solution of the problem, simply using the same keys throughout the
rounds (the different component DESs have different keys, though).
One could compensate for disadvantage in security in comparison with
DEAL's approach by employing more rounds (this is a tradeoff, of
course). Conceivable is certainly also the way via using a master key
and using a DES in counter mode to generate different keys for
the different rounds.

Thanks.

M. K. Shen


From: unruh on
On 2010-03-06, Mok-Kong Shen <mok-kong.shen(a)t-online.de> wrote:
> Maaartin wrote:
>> Mok-Kong Shen wrote:
>>> 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.
>
> However, developing one's own keyschedule like in the case of DEAL
> demands high expetise. The scheme I suggested is sort of "poorman's"
> solution of the problem, simply using the same keys throughout the
> rounds (the different component DESs have different keys, though).
> One could compensate for disadvantage in security in comparison with
> DEAL's approach by employing more rounds (this is a tradeoff, of
> course). Conceivable is certainly also the way via using a master key
> and using a DES in counter mode to generate different keys for
> the different rounds.

This is getting away from you. Another good reason for abandoning des is
that it is slow. Your system is slow. Why in the world use a slow, home
baked system when there are lots of fast, well studied systems out
there? And they are free. Your "poor man" is an idiot as well. It is
were a matter of learing, one could perhaps understand, but to advertise
it as a "poorman's" solution to a problem which has already been solved
far better and more elegantly is silly.

>
> Thanks.
>
> M. K. Shen
>
>
From: J.D. on
>The scheme I suggested is sort of "poorman's"
> solution of the problem, simply using the same keys throughout the
> rounds (the different component DESs have different keys, though).
> One could compensate for disadvantage in security in comparison with
> DEAL's approach by employing more rounds (this is a tradeoff, of
> course).

If you use the same key for all the rounds then this will be breakable
by slide attacks, no matter how many rounds you use. There is a very
simple and cheap improvement that would prevent slide attacks, but I'm
not going to tell you what it is. It's more fun to figure these
things out for yourself.

From: Mok-Kong Shen on
unruh wrote:
> Mok-Kong Shen wrote:
>> Maaartin wrote:
>>> 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.
>>
>> However, developing one's own keyschedule like in the case of DEAL
>> demands high expetise. The scheme I suggested is sort of "poorman's"
>> solution of the problem, simply using the same keys throughout the
>> rounds (the different component DESs have different keys, though).
>> One could compensate for disadvantage in security in comparison with
>> DEAL's approach by employing more rounds (this is a tradeoff, of
>> course). Conceivable is certainly also the way via using a master key
>> and using a DES in counter mode to generate different keys for
>> the different rounds.
>
> This is getting away from you. Another good reason for abandoning des is
> that it is slow. Your system is slow. Why in the world use a slow, home
> baked system when there are lots of fast, well studied systems out
> there? And they are free. Your "poor man" is an idiot as well. It is
> were a matter of learing, one could perhaps understand, but to advertise
> it as a "poorman's" solution to a problem which has already been solved
> far better and more elegantly is silly.

DES was only an example used in the particular discussion here with
Maaartin. So we should discuss on an arbitrary existing good block
cipher. Why would one need a "poorman's" or even more appropriately
said "quick but inefficient" solution? There could be two situations
that this may be applied in my humble view. One is (just to illustrate),
for instance, when my boss for whatever reasons desires to have a
cipher of block length much bigger than 128 bits. I could adequately
respond to his (reasonable or not) demand with the code indicated
in my original post very quickly and, what is more decisive, even
though I don't have the expertise to design good ciphers at all. The
second reason is akin in nature to one which I mentioned in a post of
today in the thread "Introducing dynamics into block encryptions",
namely: Imagine that it is suddenly revealed that some scientist has
succeeded to invent a novel analysis technique that breaks one's block
cipher in use, then, by suitably choosing a larger block length to
compose a cipher from the hithto employed one, one could at least
manage to satisfy one's security needs in the "interim" period before
experts devise efficient and good means of defending against the novel
attack, including, of course, designing a new cipher that is immune to
it.

BTW, you as expert are sincerely requested also to comment to the
issues stated in my post of today (15:50) in the other thread mentioned
above.

Thanks,

M. K. Shen


From: Mok-Kong Shen on
J.D. wrote:
>> The scheme I suggested is sort of "poorman's"
>> solution of the problem, simply using the same keys throughout the
>> rounds (the different component DESs have different keys, though).
>> One could compensate for disadvantage in security in comparison with
>> DEAL's approach by employing more rounds (this is a tradeoff, of
>> course).
>
> If you use the same key for all the rounds then this will be breakable
> by slide attacks, no matter how many rounds you use. There is a very
> simple and cheap improvement that would prevent slide attacks, but I'm
> not going to tell you what it is. It's more fun to figure these
> things out for yourself.

Many thanks for the hint. So one should do like, to quote myself:

....... using a master key
and using a DES in counter mode to generate different keys for
the different rounds.

The point is that doing this way is quite evidently secure and also
very simple, while devising one's own key schedule like waht is done
in DEAL is difficult and demands high expertise.

M. K. Shen