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

Re: IKE entropy issues with long keys

To: <andrew.krywaniuk@alcatel.com>
Subject: Re: IKE entropy issues with long keys
From: Wes Hardaker <wes@hardakers.net>
Date: 05 Feb 2001 21:27:25 -0800
Cc: "'Wes Hardaker'" <wes@hardakers.net>, <ipsec@lists.tislabs.com>
In-Reply-To: <002001c08fda$bfe8ee50$1e72788a@andrewk3.ca.alcatel.com>
Organization: Network Associates - NAI Labs
References: <002001c08fda$bfe8ee50$1e72788a@andrewk3.ca.alcatel.com>
Sender: owner-ipsec@lists.tislabs.com
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Notus)

>>>>> On Mon, 5 Feb 2001 20:18:43 -0500, "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com> said:

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

I'm not sure to which example you're referring, but thats ok...

Andrew> I (and others) have actually suggested before that we need an
Andrew> RFC which documents the implicit security properties of
Andrew> IKE.

Thats probably a really good idea.

-- 
Wes Hardaker
NAI Labs
Network Associates

References:

RE: IKE entropy issues with long keys

From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>

Prev by Date: Re: IKE entropy issues with long keys
Next by Date: Re: IKE entropy issues with long keys
Prev by thread: RE: IKE entropy issues with long keys
Next by thread: Re: IKE entropy issues with long keys
Index(es):
- Main
- Thread