Prev: Double encryption method
Next: File Handling in Ada -95.- Demonstartion.
From: Tran Ngoc Duong on 19 Jun 2010 21:31
On Jun 20, 2:19 am, Maaartin <grajc...(a)seznam.cz> wrote:
> On Jun 19, 6:10 pm, Tran Ngoc Duong <tranngocdu...(a)gmail.com> wrote:
>
> > On Jun 19, 1:01 pm, Maaartin <grajc...(a)seznam.cz> wrote:> Anyway, the precomputation may or may not help.
> > > In you algorithm you need Z[i][0] and Z[i][3] to be
> > > odd, and there's no reason not to assure it in the key schedule.
>
> > No, I neeedn't. Since x.y is a group operation, every 32-bit number no
> > matter odd or even is invertible. For example, the inverse of 0 is 0
> > and the inverse of 2 is 1717986918.
>
> You wrote
> x1 += Z[i][0] * (2*x1 + 1);
> and not
> x1 += Z[i][0] . x1
> so I assumed you replaced the IDEA operation by a standard
> multiplication, didn't you?
>
No, I didn't. I replaced the IDEA multiplication by x.y = 2*x*y + x +
y. Indeed, I wrote
x1 +== Z[i][0] * (2*x1 + 1);
which is equivalent to
x1 = x1 + Z[i][0] * (2*x1 + 1);
or
x1 = x1 + 2*x1*Z[i][0] + Z[i][0];
or
x1 = x1 . Z[i][0];
or
x1 .= Z[i][0];

The last form is shorter but less explicit so I wrote in the form with
only standard symbols (* and +) instead.

I believe I've seen at least two IDEA-like ciphers for 32-bit machines
using either standard multiplication or multiplication mod p (p
prime). They didn't attract me as the relevant groups do not have
exactly 2^32 elements.

> > > By switching to 64 bit you can get an algorithm working on 256-bit
> > > blocks which takes on AMD64 about the same time per block.
>
> > For 256-bit blocks we must reconsider key length and number of rounds.
> > It is very likely that we'll get double key length, double number of
> > rounds, double time per block, which is the same clock cycles per
> > byte, at best.
>
> I'm afraid, any change invalidates most of the analysis done, and we
> can't redo it. I believe that for the same security level no doubling
> of rounds is necessary. All operations with 64 bits work as good as
> for the ones with 32 bits,
>
I agree.

> the multiplication mixes even better. It
> may take longer until all bits diffuse into all others, but IMHO you
> only need each bit to diffuse into as many bits as for the 32-bit
> version in order to get the same security.
>
The complication is with the key length. Subkeys in every reasonably
large area in the computational graph must be statistically
independent in order to difuse completely over the ciphertext block.
For IDEA's computational graph I believe that such a "reasonably
large" area must contain at least 5 subkeys. That's why I've proposed
a cipher with 160-bit key. I see no easy way to double the block
length without doubling the key length which, undesirably, is also the
required level of security.
From: Maaartin on 20 Jun 2010 02:09
On Jun 20, 3:31 am, Tran Ngoc Duong <tranngocdu...(a)gmail.com> wrote:
> On Jun 20, 2:19 am, Maaartin <grajc...(a)seznam.cz> wrote:

> No, I didn't. I replaced the IDEA multiplication by x.y = 2*x*y + x +
> y. Indeed, I wrote
> x1 +== Z[i][0] * (2*x1 + 1);

I see I was blind.I always prefer writing a += b to a = a+b, so I
really can't understand how could I overlook it.

> The last form is shorter but less explicit so I wrote in the form with
> only standard symbols (* and +) instead.

Sure, without having a fancy symbol for the operation it's better to
be more explicit.

> I believe I've seen at least two IDEA-like ciphers for 32-bit machines
> using either standard multiplication or multiplication mod p (p
> prime). They didn't attract me as the relevant groups do not have
> exactly 2^32 elements.

Could you maybe recall their names?

> > the multiplication mixes even better. It
> > may take longer until all bits diffuse into all others, but IMHO you
> > only need each bit to diffuse into as many bits as for the 32-bit
> > version in order to get the same security.
>
> The complication is with the key length. Subkeys in every reasonably
> large area in the computational graph must be statistically
> independent in order to difuse completely over the ciphertext block.
> For IDEA's computational graph I believe that such a "reasonably
> large" area must contain at least 5 subkeys. That's why I've proposed
> a cipher with 160-bit key. I see no easy way to double the block
> length without doubling the key length which, undesirably, is also the
> required level of security.

Longer key doesn't imply requiring or promising higher security, e.g.,
DJB claims only 128 bit security for his Salsa20/8 although it has a
256 bit key. Bit I probably misunderstood you.
From: Tran Ngoc Duong on 21 Jun 2010 08:19
On Jun 20, 1:09 pm, Maaartin <grajc...(a)seznam.cz> wrote:
> Could you maybe recall their names?
>
I can't remember. I've searched the Web but was unable to find them.

> Longer key doesn't imply requiring or promising higher security, e.g.,
> DJB claims only 128 bit security for his Salsa20/8 although it has a
> 256 bit key.
>
Salsa20/8 is a reduced version of Salsa20 which is with full 256-bit
security. Baton has 320-bit key, half of which is derrived from the
other half so it is often referred as a cipher with 160-bit key. We
may define a cipher with very long key at lower security level but
this would render it less efficient, thus less attractive.
From: Maaartin on 22 Jun 2010 05:59
On Jun 21, 2:19 pm, Tran Ngoc Duong <tranngocdu...(a)gmail.com> wrote:
> > Longer key doesn't imply requiring or promising higher security, e.g.,
> > DJB claims only 128 bit security for his Salsa20/8 although it has a
> > 256 bit key.
>
> Salsa20/8 is a reduced version of Salsa20 which is with full 256-bit
> security. Baton has 320-bit key, half of which is derrived from the
> other half so it is often referred as a cipher with 160-bit key. We
> may define a cipher with very long key at lower security level but
> this would render it less efficient, thus less attractive.

I don't see why. Salsa20/8 is about 2.5 faster than Salsa20/20, uses
key of the same length and provides "half as much" security. Doesn't
it show that the key length itself has no effect on efficiency?
From: Tran Ngoc Duong on 24 Jun 2010 17:02
On Jun 22, 4:59 pm, Maaartin <grajc...(a)seznam.cz> wrote:
> On Jun 21, 2:19 pm, Tran Ngoc Duong <tranngocdu...(a)gmail.com> wrote:
>
> > > Longer key doesn't imply requiring or promising higher security, e.g.,
> > > DJB claims only 128 bit security for his Salsa20/8 although it has a
> > > 256 bit key.
>
> > Salsa20/8 is a reduced version of Salsa20 which is with full 256-bit
> > security. Baton has 320-bit key, half of which is derrived from the
> > other half so it is often referred as a cipher with 160-bit key. We
> > may define a cipher with very long key at lower security level but
> > this would render it less efficient, thus less attractive.
>
> I don't see why. Salsa20/8 is about 2.5 faster than Salsa20/20, uses
> key of the same length and provides "half as much" security. Doesn't
> it show that the key length itself has no effect on efficiency?

Salsa20/8 is more efficient than the full Salsa20 (if only 128-bit
security is required, of course). On the other hand, it is less
efficient than an imaginary block cipher X that is the same fast and
promising the same (128-bit) security but using shorter (say, 128-bit)
key.

First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: Double encryption method
Next: File Handling in Ada -95.- Demonstartion.