Re: [PATCH] xfrm: fix hmac(sha256) truncation length

2012-03-09 Thread Herbert Xu
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 all

Re: [PATCH] xfrm: fix hmac(sha256) truncation length

2012-03-09 Thread Jarod Wilson
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 comp

Re: [PATCH] xfrm: fix hmac(sha256) truncation length

2012-03-07 Thread Herbert Xu
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. Users

[PATCH] xfrm: fix hmac(sha256) truncation length

2012-03-07 Thread Jarod Wilson
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 ea