[Swan-dev] HMAC_BUFSIZE

[Andrew Cagney]

Did you consider deleting most of the macros (and instead in-lining
the values used to constructing 'struct hash_desc' entries)?
It would help take away some of the temptation to use those macros
when code should be using 'struct hash_desc' fields.

I guess MAX_HMAC_BLOCKSIZE (paired with passert(hash_desc->xxx <=
MAX_HMAC_BLOCKSIZE)) is a convenience we live with.

BTW,  I've only found one case where a specific hash algorithm is
called for: when detecting NAT.  In IKEv1 MD5 is specified, in IKEv2
it's SHA1.  But even there 'struct hash_desc' can be used (and from
memory it is).

Either way, a definite improvement.

On 19 July 2015 at 00:08, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
> 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
>         HMAC_RFC2104_BLOCKSIZE,
>         HMAC_SHA256_BLOCKSIZE, or
>         HMAC_SHA512_BLOCKSIZE.
>
> 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
> overrun.
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev