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
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