Bitsize of the MAC output of blake3

[elichai]

The crate provides https://docs.rs/blake3/latest/blake3/fn.keyed_hash.html as a MAC function, which returns 256 bits.
while:

• siphash is considered a somewhat secure MAC, even though outputting 64 bits.
• The HMAC RFC(2104) says:

5. Truncated output
A well-known practice with message authentication codes is to
truncate the output of the MAC and output only part of the bits
..... We recommend that
the output length t be not less than half the length of the hash
output (to match the birthday attack bound) and not less than 80 bits
(a suitable lower bound on the number of bits that need to be
predicted by an attacker).

So, is 256 bits necessary under the MAC security game? (where the attacker doesn't know the key, so he needs to attack not not blake3 but all family of blake3_key, so it sounds like some birthday attack between key space and output space) but I'm really not a crypt-analyst :)

[lulcat]

I mean the RFC you link to, states clearly in Section 2, that the key should definitely be minimum "L" bytes, or 32 Bytes in hmac-b3's case.

[oconnor663]

Truncating the MAC to 128 bits / 16 bytes is a reasonable choice for a lot of applications. Like you mentioned, MACs don't usually need collision resistance, so a 128-bit MAC is good enough for the typical 128 bits of security that most designs shoot for. That's why we see 128-bit MACs in common authenticated ciphers like AES-GCM and ChaCha20.

That said, if you don't mind paying the extra 16 bytes on the wire, using the full 32-byte output does have some benefits, like "key commitment" (which is related to collision resistance). That comes up in for example https://github.com/oconnor663/bessie/blob/main/design.md. For a protocol like TLS, 16 bytes is an unacceptable cost for a feature they don't need, but for use cases like general-purpose file encryption, it's a negligible cost for a feature that might be "nice to have".