netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] xfrm: fix hmac(sha256) truncation length
@ 2012-03-07 20:12 Jarod Wilson
  2012-03-08  0:37 ` Herbert Xu
  0 siblings, 1 reply; 4+ messages in thread
From: Jarod Wilson @ 2012-03-07 20:12 UTC (permalink / raw)
  To: linux-kernel
  Cc: Jarod Wilson, Paul Wouters, Herber Xu, David S. Miller,
	Martin Willi, netdev, linux-crypto

Commit bc74b0c8af17458ecae77f725e507ab5fd100105 added proper hmac sha384
and sha512 variants with truncation lengths of 192 and 256 respectively,
per RFC4868:

http://www.ietf.org/rfc/rfc4868.txt

The already-present hmac sha256 variant was left as-is, with a truncation
length of 96 bits, per an earlier draft of the RFC, as I understand it (it
predates 2.6.12-rc2, didn't look further back). This doesn't play well out
of the box with various other ipsec devices that properly implement the
current RFC value of 128-bit truncation for hmac sha256. Easy fix,
assuming there's not some reason I'm not clued into about why this might
have intentionally been left as-is.

CC: Paul Wouters <pwouters@redhat.com>
CC: Herber Xu <herbert@gondor.apana.org.au>
CC: David S. Miller <davem@davemloft.net>
CC: Martin Willi <martin@strongswan.org>
CC: netdev@vger.kernel.org
CC: linux-crypto@vger.kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
---
 net/xfrm/xfrm_algo.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index 791ab2e..f2b3ce2 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -203,7 +203,7 @@ static struct xfrm_algo_desc aalg_list[] = {
 
 	.uinfo = {
 		.auth = {
-			.icv_truncbits = 96,
+			.icv_truncbits = 128,
 			.icv_fullbits = 256,
 		}
 	},
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] xfrm: fix hmac(sha256) truncation length
  2012-03-07 20:12 [PATCH] xfrm: fix hmac(sha256) truncation length Jarod Wilson
@ 2012-03-08  0:37 ` Herbert Xu
  2012-03-09 13:41   ` Jarod Wilson
  0 siblings, 1 reply; 4+ messages in thread
From: Herbert Xu @ 2012-03-08  0:37 UTC (permalink / raw)
  To: Jarod Wilson
  Cc: linux-kernel, Paul Wouters, David S. Miller, Martin Willi, netdev,
	linux-crypto

On Wed, Mar 07, 2012 at 03:12:37PM -0500, Jarod Wilson wrote:
> Commit bc74b0c8af17458ecae77f725e507ab5fd100105 added proper hmac sha384
> and sha512 variants with truncation lengths of 192 and 256 respectively,
> per RFC4868:

No, it was done deliberately to maintain backwards compatibility.
Userspace should set the truncbits explicitly from now on.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] xfrm: fix hmac(sha256) truncation length
  2012-03-08  0:37 ` Herbert Xu
@ 2012-03-09 13:41   ` Jarod Wilson
  2012-03-09 13:45     ` Herbert Xu
  0 siblings, 1 reply; 4+ messages in thread
From: Jarod Wilson @ 2012-03-09 13:41 UTC (permalink / raw)
  To: Herbert Xu
  Cc: linux-kernel, Paul Wouters, David S. Miller, Martin Willi, netdev,
	linux-crypto

Herbert Xu wrote:
> On Wed, Mar 07, 2012 at 03:12:37PM -0500, Jarod Wilson wrote:
>> Commit bc74b0c8af17458ecae77f725e507ab5fd100105 added proper hmac sha384
>> and sha512 variants with truncation lengths of 192 and 256 respectively,
>> per RFC4868:
>
> No, it was done deliberately to maintain backwards compatibility.
> Userspace should set the truncbits explicitly from now on.

Okay, I suspected that might be the case. No plans to ever invert that, 
so that userspace has to explicitly set the shorter truncbits for 
backwards compat?

-- 
Jarod Wilson
jarod@redhat.com.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] xfrm: fix hmac(sha256) truncation length
  2012-03-09 13:41   ` Jarod Wilson
@ 2012-03-09 13:45     ` Herbert Xu
  0 siblings, 0 replies; 4+ messages in thread
From: Herbert Xu @ 2012-03-09 13:45 UTC (permalink / raw)
  To: Jarod Wilson
  Cc: linux-kernel, Paul Wouters, David S. Miller, Martin Willi, netdev,
	linux-crypto

On Fri, Mar 09, 2012 at 08:41:10AM -0500, Jarod Wilson wrote:
>
> Okay, I suspected that might be the case. No plans to ever invert that,  
> so that userspace has to explicitly set the shorter truncbits for  
> backwards compat?

That's up to the userspace implementation.  If its configuration
allows explicit trunc bits then just use whatever the user says.
Otherwise it'll have to make a policy decision.  For example, a
big warning when upgrading and changing the default to the correct
value.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-03-09 13:45 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-07 20:12 [PATCH] xfrm: fix hmac(sha256) truncation length Jarod Wilson
2012-03-08  0:37 ` Herbert Xu
2012-03-09 13:41   ` Jarod Wilson
2012-03-09 13:45     ` Herbert Xu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).