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