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 <[email protected]>
CC: Herber Xu <[email protected]>
CC: David S. Miller <[email protected]>
CC: Martin Willi <[email protected]>
CC: [email protected]
CC: [email protected]
Signed-off-by: Jarod Wilson <[email protected]>
---
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
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 <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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
[email protected].
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 <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt