On Wed, Sep 11, 2013 at 07:16:13PM +0000, Hsieh, Che-Min wrote: > Herbert: > > Can you confirm the following. Thanks. > > Rfc2404 - The Use of HMAC-SHA-1-96 within ESP and AH > > For the support, I can't find any algorithm to be specified in the .craname of ahash_alg for Rfc2404. > > From > http://www.freebsd.org/cgi/man.cgi?query=setkey&sektion=8 > it says the following : > > ALGORITHMS > The following list shows the supported algorithms. The protocol and algorithm are almost completely orthogonal. The following list of authentication algorithms can be used as aalgo in the -A aalgo of the protocol parameter: > > algorithm keylen (bits) comment > > hmac-sha1 160 ah: rfc2404 > > > That leads me to believe, from crypto driver stand point, there is no need to have a new algorithm for hmac-sha-1-96 support. Instead, the agent SW(such as ipsec) should use "hmac(sha1)", and do the truncation of digested data from 160 bits to 96 bits. > > I run a quick test. The input file to setkey command is defined as such ---- > > flush; > spdflush; > add 10.2.243.75 10.2.243.29 ah 0x604 -A hmac-sha1 0x8D967D88F6CAA9D714800AB3D48051D63F73A312; > add 10.2.243.29 10.2.243.75 ah 0x605 -A hmac-sha1 0x8D967D88F6CAA9D714800AB3D48051D63F73A314; > spdadd 10.2.243.75 10.2.243.29 any -P in ipsec ah/transport//use; > spdadd 10.2.243.29 10.2.243.75 any -P out ipsec ah/transport//use; > > > I use tcpdump. Clearly I can see 24 bytes of AH header of the ipsec packets. The header has 12 bytes of fixed information - Next (1), Ah len (1) ,Reserved (2), Spi (4) ,Sequence (4), and Auth result. (12 bytes) > > > Can you confirm the above? Thanks. Yes, see net/xfrm/xfrm_algo.c. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
