[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: change in isakmp/oakley



A correction and a couple of additional examples:

Michael Richardson noted the following typo in a previous message of mine:

>>think of 3DES with two keys, i.e ENC(K1, DEC(K2, ENC(K2, data))), as
>
>  Surely, you mean:
>	ENC(K1, DEC(K2, ENC(K1, data)))
>
>  because DEC(K2, ENC(K2, data)) is the identity function.
>

Of course, Michael, you are right. Thanks!

Dave Wagner (thanks Dave!) has pointed out to me the relevance of 
related-key attacks (see his paper with Kelsey and Schneier in Crypto'96) 
to the scenario that we are discussing in isakmp/oakley.
In common use of block-ciphers for encryption many of these attacks 
are impractical since they can easily be avoided by a reasonable choice of keys.
However, when part of the key might have been chosen by the attacker
the story is a very different one. That's the story that we need to solve
here. As Dave notices some of these attacks (in particular for 3DES)
become applicable here.

I can add a similar remark concerning weak keys. Recently there was a
discussion as for whether one needs to check for weak keys in 3DES.
Many pointed out that such a check is unnecessary since the probability 
to pick such a key is negligible. They were right, since the assumption
was that the party interested in the security chooses them at random. 
But what about the attacker choosing part of the key?

As an example consider an extremely secure block cipher
(or keyed hash for this ppurpose) that uses 256 bit keys,
but it has a "negligible" set of weak keys: whenever the 128 
right-most bits of the key are zeros the function becomes the 
identity function. 
Is this a problem?
Usually not. For a randomly chosen key to fall in that set the probability 
is 2^{-128}. 
However, what if the first half is Ni and the second half is Nr?
Clearly, the attacker can choose Nr=0!

Well, hope this adds some clarity to my previous sketchy arguments.
Hope also that it convinces somebody to make the (small) 
required change to the spec.

Hugo



Follow-Ups: