[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: change in isakmp/oakley
> Instead, the worry expressed is that the prf definition will allow key
> truncation. I'd never considered that a possibility, though I suppose
> that is why correct composition is such a hard problem --- incomplete
> specifications of the composition requirements.
Indeed, we are talking about providing complete specifications, and about
free-ing future implementers from understanding all the subtleties of these
protocols. Prf's can be implemented in a variety of ways (and that's
their advantage; in particular they include two fundamental classes of
cryptographic algorithms, keyd hash functions and block ciphers).
Their only requirement is that the output be cryptographically unpredictable
for whoever does not know the (random) key.
The specifications of the protocol need to guarantee that if the underlying
cryptographic functions are secure (including the prf) then the protocol is
secure. The mixing of Ni and Nr as I requested is needed to provide
this analytical property of the protocol.
Truncation is the easiest example to give, but other functions are possible
that do not use all the key bits in a symmetric way. For example,
there may be functions where the second half of the bits have a stronger
influence in the security of the function than the first half.
This could be, for example, the property of an excellent block cipher,
and consequently of an excelent prf. (Notice that in this
case the effective key length is shorter than the total key length;
so what? RSA has such a property and we keep using it.)
In any case, the initial mixing of Ni|Nr would prevent any weakness
resulting from a-symmetric properties of a key.
>Do the spec's allow the prf's to do key truncation? What do they do
>with keys longer than one block? My own opinion is that truncation
>is a severe bug in any case, and that it should be fixed. This makes
>their use for session key derivation moot.
The spec specifies which key to use with the prf in each case.
However, different prf's may require a diferent number of key bits.
While HMAC is defined for any length of key, 3DES-CBC-MAC (which is
my preferred candidate for use as a prf for key derivation) is defined
with *exactly* 168 bits of key. What do we do in order to use it
with another key length? Whoever specifies 3DES-CBC-MAC for use in
isakmp/oakley will need to define how to get the right number of key
bits in this case. Same for other prf's. Providing Ni|Nr as the initial
seed for the key when Nr can be chosen (under certain attacks) by the
adversary is not a good idea. Hashing it first prevents this
"malicious influence" by the attacker.
Hugo
Follow-Ups: