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

RE: Some comments to draft-ietf-ipsec-ikev2-00.txt

Two comments on your questions at the end:

1) I repea Dave Wagner's accurate answer:
Why is this a problem?  Are you worried about 2^160 work attacks?

2) Note that other mechanisms based on HMAC to derive keys from g^xy (in
particular, as done in JFK) present the same issue. That is, when you
perform HMAC-SHA1{g^xy}(...)  what happens is that g^xy is FIRST hashed
via SHA-1 [1] and this hashed value is then used as the actual key to
HMAC. This is the case IF g^xy is longer than the hash output which is the
common case.

[1] See section 3 of RFC 2104. In particular:

   The key for HMAC can be of any length (keys longer than B bytes are
   first hashed using H).  However, less than L bytes is strongly
   discouraged as it would decrease the security strength of the
   function.  Keys longer than L bytes are acceptable but the extra
   length would not significantly increase the function strength. (A
   longer key may be advisable if the randomness of the key is
   considered weak.)

Hugo

PS: the above paragraph about the pre-hashing of long keys in HMAC also
gives you a partial answer on your other question
about what's the benefit of using nonces that are longer than the hash
output size: while the extra length is not strictly needed, and can
even be considered a "waste" if the nonce bits are TRULY random,
the extra length may potentially help in the typical case that these bits
are generated out of a weaker source of (pseudo) randomness.


On Tue, 11 Dec 2001, Andrew Krywaniuk wrote:

> > As a general pricniple,
> > if you have two keys k and k' where k' was derived from k
> > then applying prf(k', k) (here k' is the key to the prf and k
> > the input)
> > may be insecure even if prf is an excelent pseudorandom
> > function family
> 
> Okay, I believe you.
> 
> But both of these issues deal with key stretching, although in one case the
> input is public information and in one case the input is private
> information.
> 
> If SKEYSEED = prf(Ni | Nr, g^ir) and we use the generic stretching algorithm
> then it does no good to make Ni and Nr any bigger than the output of the
> hash. If that is the case then many of us ought to be changing our code to
> use smaller nonces, since large nonces are merely wasting entropy and
> bandwidth. (And the draft ought to talk about how to choose an appropriate
> length nonce.)
> 
> 
> In the case of:
> 
>        K1 = prf(SKEYSEED_e, 0)
>        K2 = prf(SKEYSEED_e, K1)
>        K3 = prf(SKEYSEED_e, K2)
> 
> The problem is that no matter how large you make your DH exponent, the
> entropy in your key(s) is limited by the output of your hash. This was
> brought up a couple of times in reference to IKEv1 and I had assumed that we
> would be fixing it in IKEv2. Isn't there a way to get around this problem,
> or do we all need to go and implement SHA-2 solely for the purpose of key
> stretching?
> 
> Andrew
> -------------------------------------------
> There are no rules, only regulations. Luckily,
> history has shown that with time, hard work,
> and lots of love, anyone can be a technocrat.
> 
> 
>
Follow-Ups: References: