Change Details

HMACs do not actually have any limit on key sizes. Transforms should compact keys larger than the block size by using the transform (hash) on the long key. (Short keys are padded out with zeros to the HMAC block size.) Still, not all drivers necessarily handle longer-than-blocksize keys appropriately, so leave a maximum key length of the block size in place for auth_hashes that previously expressed a specific key size requirement. Zero values are left as-is (no constraint on key size). I believe the hardcoded keysizes were committed in the original import of opencrypto from OpenBSD and are due to specific protocol requirements of IPSec. The hardcoded keysizes totally break the SHA tests in cryptotest.py; none of the NIST-KAT example inputs have keys sized to opencrypto's previous expectations.

Theoretically, HMACs do not actually have any limit on key sizes. Transforms should compact input keys larger than the HMAC block size by using the transform (hash) on the input key. (Short input keys are padded out with zeros to the HMAC block size.) Still, not all FreeBSD crypto drivers that provide HMAC functionality handle longer-than-blocksize keys appropriately, so enforce a "maximum" key length in the crypto API for auth_hashes that previously expressed a requirement. (The "maximum" is the size of a single HMAC block for the given transform.) Unconstrained auth_hashes are left as-is. I believe the previous hardcoded sizes were committed in the original import of opencrypto from OpenBSD and are due to specific protocol details of IPSec. Note that none of the previous sizes actually matched the appropriate HMAC block size. The previous hardcoded sizes made the SHA tests in cryptotest.py useless for testing FreeBSD crypto drivers; none of the NIST-KAT example inputs had keys sized to the previous expectations. The following drivers were audited to check that they handled keys up to the block size of the HMAC safely: Software HMAC: * padlock(4) * cesa * glxsb * safe(4) * ubsec(4) Hardware accelerated HMAC: * ccr(4) * hifn(4) * sec(4) (Only supports up to 64 byte keys despite claiming to support SHA2 HMACs, but validates input key sizes) * cryptocteon (MIPS) * nlmsec (MIPS) * rmi (MIPS) (Amusingly, does not appear to use key material at all -- presumed broken)

Theoretically, HMACs do not actually have any limit on key sizes. Transforms should Transforms should compactt input keys larger than the HMAC block size by using the transform (hash) on the longusing the transform (hash) on the input key. (Short input keys are padded out with zeros to the HMAC block size.) Still, not all drivers necessarily handle longer-than-blocksize keysFreeBSD crypto drivers that provide HMAC functionality handle longer-than-blocksize keys appropriately, so leavso enforce a "maximum key length of the block size in place for" key auth_hashes that previously expressed a specific key size requirement. Zerolength in the crypto API for auth_hashes that previously expressed a values are left as-is (no constraint on key size)requirement. (The "maximum" is the size of a single HMAC block for the given transform.) Unconstrained auth_hashes are left as-is. I believe the previous hardcoded keysizes were committed in the original import of import of opencrypto from OpenBSD and are due to specific protocol requirements of IPSecdetails of IPSec. Note that none of the previous sizes actually matched the appropriate HMAC block size. The previous hardcoded keysizes totally breakmade the SHA tests in cryptotest.py; none of the NIST-KAT example inputs have keys sized to opencrypto's previoususeless for testing FreeBSD crypto drivers; none of the NIST-KAT example expectations.inputs had keys sized to the previous expectations. The following drivers were audited to check that they handled keys up to the block size of the HMAC safely: Software HMAC: * padlock(4) * cesa * glxsb * safe(4) * ubsec(4) Hardware accelerated HMAC: * ccr(4) * hifn(4) * sec(4) (Only supports up to 64 byte keys despite claiming to support SHA2 HMACs, but validates input key sizes) * cryptocteon (MIPS) * nlmsec (MIPS) * rmi (MIPS) (Amusingly, does not appear to use key material at all -- presumed broken)