Re: [babel] MAC and key size

[Antonin Décimo <[e-mail]>]

There is indeed confusion in OSPF RFCs about the upper bound for the
key in HMAC after which to start hashing. RFC 4634, 6234, Wikipedia,
Bird (quoting Toke), and babeld use the block size. Babel-MAC links to
RFC 6234. We are safe from that issue.

> HMAC is defined using two keys:
> - K' = H(K)  if |K| > block size

HMAC and blake2s are slightly different, in particular blake2s
*limits* the maximum size of the key and doesn't pre-hash it.

> Ben wants it to be K, while I would prefer it to be K', and any
> hashing should be done before the key is inserted into the
> management interface.

Note that reference implementations of hash algorithms take K as
parameter. But there's not much to worry about: for hmac-sha256 it
doesn't matter whether they are pre-hashed or not because of the HMAC
construct, and for blake2s it doesn't matter because the key isn't
hashed (and a pad is trivial).

I expect the user to be a bit confused to see the hashed key. If the
management delivers the hashed key, it also means that the key
derivation function is in the management interface. That would
simplify a bit a Babel implementation.

> the key SHOULD be no larger than the underlying hash's block size,

For blake2s the key cannot be larger than half the hash's block size.

I'd be in favor of using the limits enforced by the hashing algorithm
if they exist (the case of blake2s). If they don't, then use this
SHOULD, although for hmac-sha256 we've already accepted that keys
longer than 32 bytes (half the hash's block size) give no additional
security. But does it really matter, as HMAC already handles
arbitrary-sized keys?

> it SHOULD be at least the digest size

Seems like a good recommendation, but I think we're just guessing here.


What matters most and where we had troubles was the digest size to
use: it can be configured with blake2s, or generally the output can be
truncated. Implementations using the same hashing algorithm must agree
on a digest size beforehand, or verifying the signature of a packet
simply will fail (and you don't want to check if digests are prefixes
of each other). We are safe from that issue in Babel-MAC.


Regarding the input format of a key, I've seen a mail exchange that
flew a bit over my head, but remember that a key is just a big number,
and we're looking for a practical symbolic representation of that
number. An hexadecimal string seems to me the easiest human and
machine wise. I don't see babeld accepting a raw binary sequence as a
key (but I could be wrong).

Currently in babeld I enforce 32 bytes keys for both hmac-sha256 and
blake2s, but that could be relaxed. Babeld only understands
hexadecimal strings.

-- Antonin