>> It is standard. If the key length is smaller than the output (block) >> size, then the key is padded with zeroes. If the key length is bigger, >> then it is pre-hashed. See https://tools.ietf.org/html/rfc2104#section-2
> Ah, good to know! It's also not a very good idea. MAC exposes large numbers of packets and their signatures to an attacker. It is therefore vulnerable to dictionary attacks. HMAC keys should either be drawn randomly using a cryptographic RNG, or generated using a hashing procedure that is resistant to dictionary attacks. This is expanded upon in the Security Considerations section of the draft. I am of a divided mind on whether babeld should implement the RFC 2104 procedure, as proposed by Antonin. On the one hand, the procedure in RFC 2104 Section 2 is extremely naive from a modern point of view, and implementing it might induce people into deploying MAC in an insecure manner. On the other hand, it is convenient, and inconvenient security protocols are less likely to be deployed in production (*cough*PGP*cough). On the gripping hand, MAC only secures Babel traffic -- it does nothing to protect neighbour discovery, let alone data traffic. One might therefore argue that Babel-MAC and Babel-DTLS are both pointless, and that Babel should be deployed over secure links. There is some merit to this position, and we should consider doing some work on integrating babeld with Wireguard. Please see the discussion on https://github.com/jech/babeld/issues/58 -- Juliusz _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
