[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Generating 3DES keys from SKEYID_e
It's higher than I can count, I know that. :)
----- Original Message -----
From: "Glawitsch, Gregor" <Gregor_Glawitsch@nai.com>
To: "'Stephane Beaulieu'" <stephane@cisco.com>; "ipsec-list"
<ipsec@lists.tislabs.com>
Sent: Friday, July 14, 2000 5:11 PM
Subject: RE: Generating 3DES keys from SKEYID_e
> Stephane,
>
> do you realize how large 2^128 is?
>
> Greg Glawitsch
> Network Associate, Inc.
>
> -----Original Message-----
> From: Stephane Beaulieu [mailto:stephane@cisco.com]
> Sent: Friday, July 14, 2000 1:56 PM
> To: ipsec-list
> Subject: Generating 3DES keys from SKEYID_e
>
>
> Hi All,
>
> In RFC 2409, Appendix B, there's some text on how to generate keying
> material for a cipher that requires a key larger than SKEYID_e.
>
> <begin insert>
> Encryption keys used to protect the ISAKMP SA are derived from
> SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long
> enough to supply all the necessary keying material an algorithm
> requires, the key is derived from feeding the results of a pseudo-
> random function into itself, concatenating the results, and taking
> the highest necessary bits.
>
> For example, if (fictitious) algorithm AKULA requires 320-bits of key
> (and has no weak key check) and the prf used to generate SKEYID_e
> only generates 120 bits of material, the key for AKULA, would be the
> first 320-bits of Ka, where:
>
> Ka = K1 | K2 | K3
> and
> K1 = prf(SKEYID_e, 0)
> K2 = prf(SKEYID_e, K1)
> K3 = prf(SKEYID_e, K2)
>
> where prf is the negotiated prf or the HMAC version of the negotiated
> hash function (if no prf was negotiated) and 0 is represented by a
> single octet. Each result of the prf provides 120 bits of material
> for a total of 360 bits. AKULA would use the first 320 bits of that
> 360 bit string.
> <end insert>
>
> This probably comes from the same idea presented in RFC 2412, section 2.6,
> which uses similar formulas:
>
> Don't these methods limit the effective keyspace for 3DES?
>
> Someone wanting to guess the 3DES key, could start by simply guessing
> SKEYID_e. SKEYID_e is only 128 bits long (assuming md5 is used for the
> hmac).
>
> The attacker then runs every one of those 2^128 SKEYID_e through the
> algorithm above (requiring 3*2^128 md5 computations), and ends up with
2^128
> possible 3des keys.
>
> So, effectively, the strength of the cipher could only ever be as strong
as
> the size of the output of the hash algorithm. Is this correct?
>
> If this is correct, then it could be fixed by including g^xy in K1, K2 and
> K3
>
> K1 = prf(SKEYID_e, g^xy, 0)
> K2 = prf(SKEYID_e, g^xy, K1)
> K3 = prf(SKEYID_e, g^xy, K2)
>
>
> I searched through the archives, and haven't seen this discussed.
>
> Stephane.
>
> ------
> Stephane Beaulieu
> S/W Engineer
> VSEC Business Unit, Enterprise Line of Business
> Cisco Systems.
> email: stephane@cisco.com
> phone: (613) 271-3678
>
>
>
>
References: