[PATCH 0/4] Add MAC authentication support to the Babel protocol

[Toke Høiland-Jørgensen]

Ondrej Zajicek <santiago at crfreenet.org> writes:

> On Tue, Feb 25, 2020 at 07:30:46PM +0100, Toke Høiland-Jørgensen wrote:
>> Ondrej Zajicek <santiago at crfreenet.org> writes:
>> > For blake2s_bird_init(), IMHO it should behave like other keyed-hash,
>> > i.e. pad with zeroes (for shorter) or ignore rest (for longer).
>> >
>> > Perhaps we should have some hook or flag in MAC auth description
>> > structure that is used to validate keys based on used algorithm (so it
>> > would warn for bad-length keys for Blake2, but only for short keys for
>> > HMAC based ones.
>> 
>> The Blake2 implementation already 0-pads short keys. But I'm not sure if
>> it's a good idea to allow that; even if it's zero-padded it's still a
>> low amount of entropy, no?
>
> Yes, but such validation should be in independent function, applied
> during config-parse time. Functions computing MAC (including *_init())
> should just handle any key length to avoid corner cases and failures
> there.

Right, sure.

>> > It seems to me that in order to handle Blake2s MACs (and other MACs that
>> > require entropy-dense keys), the proper solution is to have a option to
>> > specify a key in some form of binary-to-text encoding (e.g. hexadecimal):
>> >
>> >   password 70:61:73:73:77:64
>> >
>> > instead of:
>> >
>> >   password "passwd"
>> 
>> Yes, I think this is a good idea (or, well, we could allow both).
>
> Yes, there should be both.
>
>> Should we use the colon-separated format, or a straight hex string for easy
>> copy-paste to babeld? E.g.,
>> 
>> password 0x7465737474657374746573747465737474657374746573747465737474657374
>
> I have no strong preference for specific format (but i would prefer
> hexadecimal based formats over Base64 / Base58 based ones).
>
> I think it is useful to have some separators (space, colon, or dash), but
> perhaps it could be optional.
>
> Also note that the key is not a number, but a byte sequence - initial
> zeroes are significant. So perhaps it should be a different token (and
> there is no reason for 0x).

Fine with me; I'll take a look at this for the next version. I'll hold
off on sending a v2 until you've had a chance to review the rest of the
patch, though :)

-Toke