Re: Summary of key derivation thread

[Uri Blumenthal <uri@bell-labs.com>]

Ran Canetti wrote:
> Thanks for summing things up.
> I agree that we shouldn't change  the current key derivation
> mechanism. But my argument is not that "this is how it is so let's not
> bother changing". Rather, the argument is that "from an analytic point of view,
> this method is superior to other methods." See mre details below.

Absolutely.
 
> >  But I think the possibilities are:
> >
> > a) leave it as it is
> > b) replace HMAC with SHA-1, thereby increasing performance, but not
> >    changing the security properties
> 
> I strongly disagree with this statement..........
> It is true that today we don't know of any attack on the protocol
> that would be made possible by replacing the PRF in the key derivation with
> simple SHA1. However, by making this transition you "in one blow" lose much
> of the analytical and mathematical basis for the security of IKE.
> We will no longer be able to claim that "the design of IKE is provably
> secure under reasonable and standard assumptions on the hash function in use".

Ran, I think you're mixing two independent properties: secure MAC
which
is proven for HMAC as long as keyed SHA is a secure MAC, and secure
PRF.
Basically what HMAC proof does (as fas as I understand) is linking the
security properties of SHA-1 to chained operations (multi-block).


Now, the analysis (as far as I know) was done for the MAC case. There
was no analysis done for PRF, and in any case in order to use HMAC as
a secure PRF you'd need to assume that SHA is a secure PRF. But if it
is so (i.e. if SHA is a secure PRF) - then you don't need the extras
that HMAC provides.

> I don't think we can allow ourselves to lose this analytical basis in a
> standard that is indended for wide use.

I don't think that analytical basis is applicable to HMAC as PRF.

 
> BTW, regrading going over 160 "bits of security". I agree that this is a
> non-issue from a practical point of view. But for the paranoids who insist
> on doing it, the best way would be to use a PRF with more security, such as
> HMAC-SHA2, or any block cipher with long enough keys and block-size.

It is an issue of convenience and of entropy loss. Regarding the
latter - it
doesn't make sense to expensively negotiate a kilobit of keying
material and
then reduce its entropy to 160 bits.