Chinh Nguyen wrote:
Looking at the source http://lxr.linux.no/source/net/xfrm/xfrm_algo.c, it seems to confirm that this is true. In fact, sha-384 and sha-512 are not supported at this time and sha-256 is truncated to 96-bit.
That's normal. HMAC usage in IPsec specifies that we only use 96-bits of the result. This is a tradeoff in space in the packet vs absolute "security" In addition should you be able to cause a collision in 96-bits by some method other than brute force, you can not be sure if you guess the key properly.
However, the following ietf draft, which I believe is very closed to ratification (it has already been assigned iana numbers), specifies sha-256 to use 128-bits as hmac (page 18): http://www.ietf.org/internet-drafts/draft-kelly-ipsec-ciph-sha2-01.txt
Yes, but that's the key, not the result. It is keyed with various sizes of bits, but the results are truncated. - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
