Ondrej Zajicek <[email protected]> writes: > 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.
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
