1

The crypto_auth function produces a 256-bit HMAC, with a 512-bit version also available. But the crypto_onetimeauth function (and the Box and SecretBox constructions that use it) only produces a 128-bit authenticator. Is there any particular reason NaCl doesn't include a 128-bit HMAC function?

Jack O'Connor
  • 637
  • 6
  • 13

1 Answers1

2

There are two things to consider.

First is that the security models differ: crypto_onetimeauth only has to be secure for one message, while crypto_auth needs to be secure for any (practical) number of messages. The reason crypto_secretbox gets away with using the Poly1305 authenticator internally is that it generates message-specific authentication keys based on the nonce.

Second is the size of the authenticator. There is no very secure 128-bit hash function – using MD5 would be iffy even if it is not known to be broken in HMAC. You could still truncate HMAC-SHA256 and get a 128-bit authentication tag, but that would require assuming more than just the security of SHA-256.

Community
  • 1
otus
  • 32,132
  • 5
  • 70
  • 165
  • It makes sense that truncating a hash would make more assumptions about it's properties than using it unaltered, but it seems like everyone is comfortable making those assumptions about SHA2. NaCl's HMAC-SHA512-256 is just a simple truncation of HMAC-SHA512. – Jack O'Connor Dec 30 '15 at 16:39
  • @JackO'Connor, yes, truncation is all right, and even approved by NIST. OTOH, the user of NaCL could handle the truncation if they want. (BTW, SHA-512/256 is not just truncation, it also has a different IV, but that's not really relevant here.) – otus Dec 30 '15 at 17:31
  • Would you consider it kosher to truncate a crypto_auth MAC to 16 bytes? – Jack O'Connor Dec 30 '15 at 17:38
  • @JackO'Connor, NIST says (pdf, section 5.3.3) you can even take it down to 32 bits! I'd prefer to keep as much as space constraints allow, but 128 bits should be fine. – otus Dec 30 '15 at 17:47