From: J.D. on
> 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.

That is one way of preventing slide attacks, though it's by far the
slowest.

However, using DES is retarded. Brute forcing your 'scheme' as
described would take only slightly longer than brute forcing DES
itself. Please stop using DES as your example.
From: Mok-Kong Shen on
J.D. wrote:
>> 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.
>
> That is one way of preventing slide attacks, though it's by far the
> slowest.
>
> However, using DES is retarded. Brute forcing your 'scheme' as
> described would take only slightly longer than brute forcing DES
> itself. Please stop using DES as your example.

DES was first raised in this thread not by me but by Maaartin. You
may be right in not (indirectly) 'propagating' DES, though on the other
hand I am not clear of how 'only slightly longer' could be
substantially argued.

Thanks.

M. K. Shen

From: Maaartin on
On Mar 6, 12:58 am, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote:
> 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?

And what security guarantee do you have?

On Mar 6, 8:06 pm, "J.D." <degolyer...(a)yahoo.com> wrote:
> >    ....... using a master key
> >    and using a DES in counter mode to generate different keys for
> >    the different rounds.
>
> That is one way of preventing slide attacks, though it's by far the
> slowest.

As far I understand it (which really is not much), anything should
help. Changing the keys in any trivial way or doing something special
in a single round?

On Mar 6, 8:25 pm, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote:
> J.D. wrote:
> > However, using DES is retarded.  Brute forcing your 'scheme' as
> > described would take only slightly longer than brute forcing DES
> > itself.  Please stop using DES as your example.
>
> DES was first raised in this thread not by me but by Maaartin.

You're wrong, it was you ("I have omitted the swapping operation that
is present e.g. in DES, for that's irrelevant for security, if I
don't err.").

> You
> may be right in not (indirectly) 'propagating' DES, though on the other
> hand I am not clear of how 'only slightly longer' could be
> substantially argued.

Quite obvious: DES has only 56 bit key, and you're going to us it in
CTR more. So where is the problem, just try all the keys.
From: Mok-Kong Shen on
Maaartin wrote:
> Mok-Kong Shen wrote:
>> 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?
>
> And what security guarantee do you have?

As layman I am incapable of doing a formal proof. But, I believe
it is quite evident that, in order to crack one composite cipher that
is based on u copies of component ciphers having v independent keys,
the work needed is at least of the order of u larger than that of
cracking one component cipher.

M. K. Shen

From: J.D. on
> > That is one way of preventing slide attacks, though it's by far the
> > slowest.
>
> As far I understand it (which really is not much), anything should
> help. Changing the keys in any trivial way or doing something special
> in a single round?

Yes, for basic slide attacks. However you have to be careful. Not
all simple tricks can defeat a clever slide attacker. See e.g.
"Advanced Slide Attacks" by Biryukov and Wagner.

> > You
> > may be right in not (indirectly) 'propagating' DES, though on the other
> > hand I am not clear of how 'only slightly longer' could be
> > substantially argued.
>
> Quite obvious: DES has only 56 bit key, and you're going to us it in
> CTR more. So where is the problem, just try all the keys.

Indeed.