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

RE: Length of pre-shared key



I disagree. It comes down to the same basic question of "What DH group do I
use with my cipher." The answer is not that you need to match the DH group
to the cipher exactly. The answer is that you need to choose an overall
system strength against attempts to derive the encryption key (X) and make
sure both variables meet or exceed that.

For IKE using preshared keys, the signature does not depend on g^xy, which
means that the preshared key can be cracked offline. The result is that you
need to choose an overall system strength against offline attacks to derive
the authentication key (Y), and ensure that both variables (entropy in the
key and the length of hash output) are greater than Y. Y does not
necessarily have to be as large as X because not many people are concerned
about 20 year secrecy for their authentication keys.

The original question asked if there were required lengths for preshared
keys. The answer is no there aren't. Using L is okay if you want to err on
the side of caution, but it's not a hard requirement. Let's say you want to
create an ASCII password using a random string of mixed case letters and
numbers and you want Y to be 90 bits. Each character contains about 5 bits
of entropy, so you will need to use passwords that are at least 15 bytes
long.

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.



> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@tibernian.com]
> Sent: Monday, February 25, 2002 6:39 PM
> To: andrew.krywaniuk@alcatel.com
> Cc: 'David Jablon'; juha.ollila@nokia.com; ipsec@lists.tislabs.com
> Subject: Re: Length of pre-shared key
>
>
>   Actually you're stretching it to the block size of the underlying
> hash algorithm not to the length of the output of the underlying hash
> algorithm. Here is the 1st paragraph of section 3.0 of RFC2104 where H
> is the underlying hash function, B is the block size of H, and L
> is the length of the output of H:
>
>    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.)
>
> Less than L is bad. Between L and B it doesn't matter as the
> key will be
> appended with zeros (and it doesn't significantly increase
> the function
> strength) and greater than B doesn't matter because the key
> will be hashed
> down to L and appended with zeros. So the answer to Juha's question is
> "not less than the length of the output of the underlying
> hash function."
>
>   Dan.
>
> On Mon, 25 Feb 2002 16:56:59 EST you wrote
> >
> >     (1) append zeros to the end of K to create a B byte string
> >         (e.g., if K is of length 20 bytes and B=64, then K will be
> >          appended with 44 zero bytes 0x00)
> >
> > It's not a very fancy stretching technique, and admittedly
> unrelated to the
> > length of the hash output (I meant to say block size).
> >
> > Sorry about using the word password instead of key. It's
> just that I speak
> > binary. :-)
> >
> > 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.
> >
> >
> >
> > > -----Original Message-----
> > > From: David Jablon [mailto:dpj@world.std.com]
> > > Sent: Monday, February 25, 2002 9:49 PM
> > > To: andrew.krywaniuk@alcatel.com
> > > Cc: juha.ollila@nokia.com; ipsec@lists.tislabs.com
> > > Subject: RE: Length of pre-shared key
> > >
> > >
> > > I don't see anywhere that RFC 2104 says anything about
> "stretch"ing
> > > a short input key into a longer one.  What it does is to hash
> > > (squeeze?)
> > > a key that's longer than 64 bytes into a hash block.
> > >
> > > Also, one should not confuse a password with a key in
> this context.
> > >
> > > At 02:17 PM 2/25/02 -0500, Andrew Krywaniuk wrote:
> > > >I don't think there is a specific limit. After all, HMAC
> > > tells you how to
> > > >stretch the input if it is less that the size of the hash
> > > output. But use
> > > >your common sense: the shorter the input, the easier it
> will be for a
> > > >cracking program to guess it. Also, it's the entropy in the
> > > password, not
> > > >the length, that matters.
> > >
> > >
> > >
> >
>