lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 24 Dec 2008 11:33:55 -0700 From: Jason Gunthorpe <jgunthorpe@...idianresearch.com> To: Herbert Xu <herbert@...dor.apana.org.au> Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net> Subject: Re: [PATCH] [IPSEC]: Change the ICV length of sha256 to 128 bits On Wed, Dec 24, 2008 at 07:59:40PM +1100, Herbert Xu wrote: > On Tue, Dec 23, 2008 at 11:02:25PM -0700, Jason Gunthorpe wrote: > > The existing setting is 96 bits which does not match the RFCs and is > > not negotiable via IKEv2. RFC 4868 says the ICV should be 128 bits, > > and IKEv2 uses AUTH_HMAC_SHA2_256_128 = 12 to identify it. > > > > git blame says this setting was made before RFC 4868 was published, > > so I'm not sure that it was chosen with any standard in mind. > > > > NOTE: This 'breaks' the user space API, however at least StrongSwan > > 4.2.9's charon already associates AUTH_HMAC_SHA2_256_128 with > > the transform name 'sha256'. > > > > Signed-off-by: Jason Gunthorpe <jgunthorpe@...idianresearch.com> > The 96 bits is actually still correct for the auth algorithm IDs > 5, 6, and 7. The parameters in 4868 have been assigned new IDs > starting from 12. Oh? Ok, I didn't realize there was something that defined those usages on PF_KEY. They are not defined for use with IKEv2 at all.. BTW, is there some reason why SADB_X_AALG_SHA2_384HMAC and SADB_X_AALG_SHA2_512HMAC are absent from the table in xfrm_algos? > This is easy to do for af_key as it uses IDs to identify the > algorithms. To make this work for xfrm, we need to extend the > auth algorithm specification to include the truncation length, > just like AEAD. Yes, I was already thinking this was the best way to support the 128/160 bit ICV lens for MD5/SHA1 that are now defined. > So if you feel adventurous, please prepare a patch to create a > new xfrm attribute XFRMA_AUTH2 that uses xfrm_algo_aead instead > of xfrm_algo, and allow that in place of XFRMA_AUTH. Thats not too hard, I might have a little time to do that over the break. > After that we can restructure the auth algorithm list to be like > AEAD and then you can add a new set of SHA algorithms for RFC 4868. It seems like those can be added today, they already have unique names: hmac(sha384), hmac(sha512) BTW, Herbert, if this is the way to go can you fix StrongSwan? Mapping AUTH_HMAC_SHA2_256_128 to 'sha256' in src/charon/plugins/kernel_netlink/kernel_netlink_ipsec.c is not correct based on this discussion. It needs to be 'hmac(sha256)' and use this XFRMA_AUTH2 idea. Similarly for all the SHA-2 family of functions I guess. Thanks, Jason -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists