Subject: HMACs

From: Sami Lehtinen <[email-masked]>
Date: Fri, 1 Sep 2000 13:25:02 +0300 (EEST)

The transport draft doesn't specify key lengths to the
hmac-algorithms. Only the digest length is shown.

According to RFC-2104:
--snip--
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.
--snap--

So, a key longer or shorter than the digest is considered bad. I think
this should be fixed in the draft.

Would this sound ok:

The key length used by the hmac MUST be the same as the digest length.

Reason I bumped into this is that OpenSSH uses the digest lengths as
key lengths, and our implementation just gave the hmac a 128-bit
key. An interoperability problem, that is.

Bill, what's up with the notes from the Pittburgh IETF?

-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]

---

From: Markus Friedl <[email-masked]>
Date: Fri, 1 Sep 2000 14:58:41 +0200

> this should be fixed in the draft.
s/should/MUST/

> The key length used by the hmac MUST be the same as the digest length.

yes, this is what i have been asking before, both on this list
and on [email-masked] but it seems that noone did care before.

-markus

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 01 Sep 2000 12:05:49 -0400

> Bill, what's up with the notes from the Pittburgh IETF?

working on it now..  sorry for the delay.

					- Bill

---

From: Ken Raeburn <[email-masked]>
Date: 02 Sep 2000 16:34:10 -0400

> length would not significantly increase the function strength.

As an aside, I think the quoted text only applies if the key space is
dense, at least for certain attack modes.  More to the point, it'd be
the number of possible keys (up to 2**L), not the number of bits in a
particular representation.  (Would spelling out the numerical value of
a 4-byte key as English text really improve the key strength just by
making it longer?)

> The key length used by the hmac MUST be the same as the digest length.

Why require that it can be no longer?  Even if the HMAC strength
levels off somewhat (completely?) after a certain number of bits, is
that reason to disallow longer keys?

"...MUST be at least as long as..." ?

Ken

---

From: Sami Lehtinen <[email-masked]>
Date: Sun, 3 Sep 2000 04:22:32 +0300 (EEST)

Ken Raeburn, on September 2. 2000, wrote:
  : > The key length used by the hmac MUST be the same as the digest length.
  : 
  : Why require that it can be no longer?  Even if the HMAC strength
  : levels off somewhat (completely?) after a certain number of bits, is
  : that reason to disallow longer keys?
  : 
  : "...MUST be at least as long as..." ?

You must state the key length somewhere, otherwise you end up with
uninteroperable implementations (as it is now). We can't just say
("SHOULD be something like...") as everyone would implement that
differently.

RFC-2104 has some points on the key length being longer than the
digest length, I suggest you read it.

---

From: Markus Friedl <[email-masked]>
Date: Sun, 3 Sep 2000 12:07:15 +0200

On Sun, Sep 03, 2000 at 01:09:36AM +0300, Tero Kivinen wrote:
> Markus Friedl writes:
> I don't think it is MUST. Changing it does not really offer any more
> security, as the key length is already long enough and the
> Diffie-Hellman doesn't provide that much entropy.
> 
> Changing it is again incompatible change to the protocol that will
> break implementations which have implemented the SHA1 HMAC as defined
> in the drafts.
> 
> The current draft quite clearly says that if we have algorithm that is 
> using variable length keys then we use 128 bits for the key. The HMACs 
> do have variable length keys, so currently it would be agains the
> draft to use any other key length for HMACs. 

so why does twofish use 256 bits? why specfify the size?  why use
a hmac in a way that is against current practice? rfc2104 clearly
states: "The key for HMAC can be of any length ...  However, less
than L bytes is strongly discouraged ..." (L=160 bits for sha1).

---

From: Ken Raeburn <[email-masked]>
Date: 04 Sep 2000 03:15:50 -0400

> ("SHOULD be something like...") as everyone would implement that

I just looked at the context further than I did before.  I was
thinking key exchange, but that's not the case here, looks like you're
talking about the keys generated by both parties from the exchanged
data.  So yes, the key length needs to be specified somewhere, in the
protocol data or the protocol spec.

> digest length, I suggest you read it.

I did look at it before sending my comments, and it says relatively
little on this point that I could find.

The first paragraph of section 3 says longer keys "would not
significantly increase" the HMAC strength, not that they "would not at
all increase" it, and doesn't go into any details of what the
difference might be, if any.  It then goes on to indicate
circumstances -- weak randomness in the key data, which I would think
would include any structure or predictability to the values, say if
not all 2**N values could actually be generated because K is computed
using a modulus slightly less than 2**N -- in which longer keys *can*
improve the strength.  Hence my question about allowing longer keys
than the minimum.

I'm not a cryptographer, though, and I'm still familiarizing myself
with the paper by Bellare, Canetti, and Krawczyk that RFC 2104 refers
to.  And I haven't figured out anything about just how weakness in the
random number generators used in implementations might affect the
quality of the key exchanged, or whether generating longer keys
through multiple hashes would help the HMAC at all in such a case.
Hence my phrasing of my original comments as questions. :-)

If longer keys don't help at all, fine.  But RFC 2104 doesn't say
that.

Ken