[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKE entropy issues with long keys
Does IKE preclude the use of SHA-256 or SHA-512 for AES?
Chris
> -----Original Message-----
> From: Andrew Krywaniuk [mailto:andrew.krywaniuk@alcatel.com]
> Sent: 06 February 2001 01:19
> To: 'Wes Hardaker'
> Cc: ipsec@lists.tislabs.com
> Subject: 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
>
This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
Follow-Ups: