netdev - Re: [PATCH] [IPSEC]: Change the ICV length of sha256 to 128 bits

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Dec 2008 14:05:19 +0100
From:	Martin Willi <martin@...ongswan.org>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>, netdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] [IPSEC]: Change the ICV length of sha256 to 128 bits

Hi,

> > > 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'.

We already discussed this in
http://kerneltrap.org/mailarchive/linux-kernel/2008/6/5/2039114 ,
but it was too much effort for me to fix this properly then.

> > 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..

In PF_KEY, SADB_X_AALG_SHA2_256HMAC (5) was defined in
draft-ietf-ipsec-ciph-sha-256-00 to 96 bit truncation (what is currently
implemented). draft-ietf-ipsec-ciph-sha-256-01 defined it to 128 bit
truncation (what is now RFC 4868).
Those numbers starting from 12 are IKEv2 algorithm identifiers and are
never passed to the kernel.

> 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?

Yes, it was not specified in draft-ietf-ipsec-ciph-sha-256-00, but is
defined in RFC 4868.

> 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.

Yes I'm aware of that. I'll fix it a soon as it is available in the
kernel. 

Regards
Martin


--
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