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]

Message-ID: <20081224085940.GA24830@gondor.apana.org.au>
Date:	Wed, 24 Dec 2008 19:59:40 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
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 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.

So what we should do is support both.

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.

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.

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.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html