On Tue, Feb 25, 2020 at 07:30:46PM +0100, Toke Høiland-Jørgensen wrote:
Ondrej Zajicek <santiago@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.
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). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."