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 <herb...@gondor.apana.org.au> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
