Re: Length of pre-shared key

[Dan Harkins <dharkins@tibernian.com>]

  You can disagree but you better take it up with the authors of RFC2104.
It specifically says that you "stretch" the key to the block size of the
hash algorithm, not, as you said, to its output.

  And using a "password" that is 15 bytes long as the key to a either
HMAC-SHA or HMAC-MD5 (the two mandatory to implement algorithms for IKE)
would be bad as the authors of RFC2104 have said. It is "strongly
discouraged". That doesn't mean that you can enter the length into some
nebulous equation of strength and maybe use it if the output from that
equation is satisfactory. It means you shouldn't use a "password" that is
15 bytes long as the key to either one of those HMACs. Period. Full stop.
Doing otherwise would be misusing this cryptographic primitive.

  Dan.

On Mon, 25 Feb 2002 19:31:17 EST you wrote
> 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.
> > > >
> > > >
> > > >
> > >
> >
>