D. Hugh Redelmeier hugh at mimosa.com
Sun Jul 19 07:08:15 EEST 2015

There is a macro called HMAC_BUFSIZE, defined to be 64.  It is a number of 
bytes to be used somehow in HMAC.  The comment before its definition says 
to see RFC 2104.

In RFC 2104, the 64-byte size is used as "B" for all of the listed hashing 
functions (but nothing constrains future hashing functions).  B is 
described here:

2. Definition of HMAC

   The definition of HMAC requires a cryptographic hash function, which
   we denote by H, and a secret key K. We assume H to be a cryptographic
   hash function where data is hashed by iterating a basic compression
   function on blocks of data.   We denote by B the byte-length of such
   blocks (B=64 for all the above mentioned examples of hash functions),
   and by L the byte-length of hash outputs (L=16 for MD5, L=20 for
   SHA-1).  The authentication key K can be of any length up to B, the
   block length of the hash function.  Applications that use keys longer
   than B bytes will first hash the key using H and then use the
   resultant L byte string as the actual key to HMAC. In any case the
   minimal recommended length for K is L bytes (as the hash output
   length). See section 3 for more information on keys.

HMAC_BUFSIZE seems to be a bad name for B.  It should be HMAC_BLOCKSIZE.

But it is incorrect for some SHA2 HMACs defined in RFC 4868.
For those, our code used HMAC_BUFSIZE * 2 -- pretty odd.
These were introduced in commit 6ed03ba7959f5c224a07866ab55f5f6f41280636.

I've replaced each use of HMAC_BUFSIZE with one of

The one other use is include/secrets.h:61:
	unsigned char ckaid[HMAC_BUFSIZE];	/* ckaid for use in NSS */
I've used HMAC_RFC2104_BLOCKSIZE but have no idea how to figure out if
that is a reasonable bound.  I've put in passerts to check for buffer

More information about the Swan-dev mailing list