symm/hmac-def.h: Base key sizes on the hash size, not state size.
authorMark Wooding <mdw@distorted.org.uk>
Sat, 12 Oct 2019 20:49:48 +0000 (21:49 +0100)
committerMark Wooding <mdw@distorted.org.uk>
Sat, 9 May 2020 19:57:33 +0000 (20:57 +0100)
Back in c850c0da81ad9f72315f8e6e26bdfbd98daf9d89 (`Support HMAC mode for
hash functions which need to store more state than the hash output
size'), there was only a single key-size specification shared between
HMAC and NMAC.  This nearly makes sense, because an NMAC key is a /pair/
of hash states, for the outer and inner hash applications, but the key
size at this time was only the size of /single/ state.  At this time,
only HMAC had a `gcmac' definition, so the key size had to be right for
HMAC, which may explain this, but it seems rather unconvincing.

Later, 2a62e96dc602cf6ec0e5a489b18262ae6abb29be (`Provide correct key
sizes for NMAC, HMAC and SSLMAC') splits this single key-size
specification into three, and adds a `gcmac' definition for the NMAC
variant.  The new key-size specification for NMAC correctly reports
double the state size, and uses `KSZ_SET' rather than `KSZ_ANY'.  I
think the other two should have been based on the hash size at this
point, but weren't: I suspect that I just propagated the previous
mistake without thinking about it very hard.

Even later, c148759dc94794db3faa3ed556583b65d40ae799 (`symm/hmac-def.h:
Report key sizes as 16-bit quantities') changes the key-size
specifications to use the new 16-bit format, but shies away from fixing
the HMAC and SSLMAC key sizes.

I'm now going to bite this bullet and declare that the HMAC and SSLMAC
key sizes should be based on the hash size.  This changes the default
key sizes for: MD2, SHA224, SHA384, SHA512/224, SHA512/256, SHA3 (all
variants), and Whirlpool256.  I think it's probably a mistake to have
used any of these hash functions with HMAC: MD2 is slow and weak; the
SHA2 variants are all worse than truncating SHA256 or SHA512; similarly,
using Whirlpool256 rather than truncating plain Whirlpool is
bizarre (and Whirlpool is slow and rarely used anyway); and SHA3 is just
a terrible fit for HMAC, and you should be using KMAC instead.

This will break interoperability in `catcrypt' if HMAC based on any of
the above hash functions is used as the `mac'.  TrIPE (sensibly) doesn't
use the default key size, so isn't affected by this change.

symm/hmac-def.h

index e3f12ce..9ac8fb9 100644 (file)
 /* --- Useful constants --- */                                         \
                                                                        \
 const octet pre##_hmackeysz[] =                                                \
-  { KSZ_ANY | KSZ_16BIT, PRE##_STATESZ/256, PRE##_STATESZ%256 };       \
+  { KSZ_ANY | KSZ_16BIT, PRE##_HASHSZ/256, PRE##_HASHSZ%256 };         \
 const octet pre##_sslmackeysz[] =                                      \
-  { KSZ_ANY | KSZ_16BIT, PRE##_STATESZ/256, PRE##_STATESZ%256 };       \
+  { KSZ_ANY | KSZ_16BIT, PRE##_HASHSZ/256, PRE##_HASHSZ%256 };         \
 const octet pre##_nmackeysz[] =                                                \
-  { KSZ_SET | KSZ_16BIT,                                               \
-    2*PRE##_STATESZ/256, 2*PRE##_STATESZ%256, 0, 0 };                  \
+  { KSZ_SET | KSZ_16BIT, 2*PRE##_HASHSZ/256, 2*PRE##_HASHSZ%256, 0, 0 }; \
                                                                        \
 /* --- @pre_nmacinit@ --- *                                            \
  *                                                                     \