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

Re: Generating 3DES keys from SKEYID_e

This form of derivation of long keys is a conscious design 
decision in IKE.
Nothing in IKE is stronger than the strength of the prf
as this prf is used to derive the basic SKEYID and authenticate
the exchanges.

If you want a stronger prf than, say, HMAC-SHA1 just use it.
This is why prf needs to be a negotiable parameter and not a fixed
one. Note that you can use any block cipher (including 3DES and
AES) as your negotiated prf.

Besides, 128 bits of security is more than necessary.
If I had an algorithm with *PROVEN* 90 bits of security I
would prefer it to 3DES or the best of AES candidates.
The reason we go for longer keys is because we need 
SAFETY MARGINS due to our very limited undersanding 
of cryptanalysis.

The best I can wish any IKE implementation is to have a 128-bit
secure prf as its weakest link...

Hugo

On Fri, 14 Jul 2000, Stephane Beaulieu wrote:

> 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: