From b67d9ed16d9ef4e4254b8d813237342b40f54f00 Mon Sep 17 00:00:00 2001 From: Mark Wooding Date: Sat, 12 Oct 2019 21:49:48 +0100 Subject: [PATCH] symm/hmac-def.h: Base key sizes on the hash size, not state size. 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 | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/symm/hmac-def.h b/symm/hmac-def.h index e3f12ced..9ac8fb9b 100644 --- a/symm/hmac-def.h +++ b/symm/hmac-def.h @@ -68,12 +68,11 @@ /* --- 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@ --- * \ * \ -- 2.11.0