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

RE: IKE entropy issues with long keys



It's not that I think that 2^128 bits isn't enough. I just don't think it's
a good idea to hardcode a field based on that assumption or to arbitrarily
discard entropy such that it looks like you're getting 256 bits when you're
really only getting 128.

As Steve also pointed out, there is dubious value to using 256 bit AES for
matching matching the discrete log workload, although the impetus has
actually been the other way around (see the recent draft on bigger DH
groups).

I don't agree with the example you brought up about using PFS to generate
extra uncorrelated key bits. The fact that the key bits come out of a PRF
should mean that they are sufficiently uncorrelated. The real reason for
rekeying is to minimize the impact of a compromise, not to make the
compromise less likely.

I (and others) have actually suggested before that we need an RFC which
documents the implicit security properties of IKE. There is simply too much
unwritten knowledge out there, in the archives and in the brains of the list
members, which is not obvious to someone who is evaluating the protocol. I
would undertake this myself, except that these things tend to carry more
weight if you get someone with a bunch of letters after their name.

Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.


> -----Original Message-----
> From: Wes Hardaker [mailto:wes@hardakers.net]
> Sent: Monday, February 05, 2001 12:45 PM
> To: andrew.krywaniuk@alcatel.com
> Cc: 'Wes Hardaker'; ipsec@lists.tislabs.com
> Subject: Re: IKE entropy issues with long keys
>
>
> >>>>> On Fri, 2 Feb 2001 17:53:13 -0500, "Andrew Krywaniuk"
> <andrew.krywaniuk@alcatel.com> said:
>
> Andrew> Wes, some of these issues have been discussed
> recently on this list.
>
> Andrew> See: http://www.vpnc.org/ietf-ipsec/mail-archive/msg01288.html
> Andrew> and: http://www.vpnc.org/ietf-ipsec/mail-archive/msg01817.html
>
> Andrew> and the discussions surrounding them.
>
> I wasn't suggesting the problem be solved (since its too late).  It
> should, IMHO, be at least mentioned in the documents even if the
> problem itself is ignored and not solved.
>
> Also, IMHO, The "2^128 is large enough" response is a silly one.  If
> that were true, we wouldn't bother developing new algorithms with
> longer key lengths.  The AES requirements required longer key lengths
> for a reason.  Currently unknown attacks may reduce the functional key
> space of an algorithm to something that is computationally feasible.
> --
> Wes Hardaker
> NAI Labs
> Network Associates
>



Follow-Ups: References: