[PATCH 2.6.26rc5] xfrm: SHA-256/384/512 HMAC support for IPsec

[Martin Willi]

RFC4868 defines the use of SHA256, SHA384 and SHA512 in HMAC using 128,
192 and 256 bits truncation. This patch replaces the outdated SHA256
algorithm with 96 bits truncation by the 128 bit variant and adds the
SHA384/512 algorithms.

Signed-off-by: Martin Willi <mar...@strongswan.org>

---
Replacing the 96 bit truncation SHA256 algorithm might be problematic,
but it is obsolete in IPsec and I don't see a way to register two
different truncation lengths in XFRM.

--- a/net/xfrm/xfrm_algo.c 2008-06-05 14:01:01.000000000 +0200
+++ b/net/xfrm/xfrm_algo.c 2008-06-05 14:39:31.000000000 +0200
@@ -187,7 +187,7 @@

.uinfo = {
.auth = {
- .icv_truncbits = 96,
+ .icv_truncbits = 128,
.icv_fullbits = 256,
}
},
@@ -200,6 +200,42 @@
}
},
{
+ .name = "hmac(sha384)",
+ .compat = "sha384",
+
+ .uinfo = {
+ .auth = {
+ .icv_truncbits = 192,
+ .icv_fullbits = 384,
+ }
+ },
+
+ .desc = {
+ .sadb_alg_id = SADB_X_AALG_SHA2_384HMAC,
+ .sadb_alg_ivlen = 0,
+ .sadb_alg_minbits = 384,
+ .sadb_alg_maxbits = 384
+ }
+},
+{
+ .name = "hmac(sha512)",
+ .compat = "sha512",
+
+ .uinfo = {
+ .auth = {
+ .icv_truncbits = 256,
+ .icv_fullbits = 512,
+ }
+ },
+
+ .desc = {
+ .sadb_alg_id = SADB_X_AALG_SHA2_512HMAC,
+ .sadb_alg_ivlen = 0,
+ .sadb_alg_minbits = 512,
+ .sadb_alg_maxbits = 512
+ }
+},
+{
.name = "hmac(rmd160)",
.compat = "rmd160",

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Adrian-Ken Rüegsegger]

Martin Willi wrote:
> RFC4868 defines the use of SHA256, SHA384 and SHA512 in HMAC using 128,
> 192 and 256 bits truncation. This patch replaces the outdated SHA256
> algorithm with 96 bits truncation by the 128 bit variant and adds the
> SHA384/512 algorithms.
>
> Signed-off-by: Martin Willi <mar...@strongswan.org>
>
> ---
> Replacing the 96 bit truncation SHA256 algorithm might be problematic,
> but it is obsolete in IPsec and I don't see a way to register two
> different truncation lengths in XFRM.

You could register a new SADB algorithm id in pfkeyv2.h and add a new
entry to the aalg_list analogous to how GCM is doing that in the aead_list.

Adrian

[Martin Willi]

> You could register a new SADB algorithm id in pfkeyv2.h and add a new
> entry to the aalg_list analogous to how GCM is doing that in the aead_list.
>
> Adrian

We could do that, but SADB_X_AALG_SHA2_256HMAC (5) actually refers to
128 bit truncation. 96 bit truncation is a leftover of
draft-ietf-ipsec-ciph-sha-256-00 and has been replaced by 128 bit
truncation in draft-ietf-ipsec-ciph-sha-256-01.

draft-kelly-ipsec-ciph-sha2 and the resulting RFC4868 define 128 bit
truncation for SADB_X_AALG_SHA2_256HMAC (5), so 96 bit truncation is
really obsolete. We could define a new PF_KEY algorithm for 96 bit
truncation, but it is not really usable as it is not standardized.

Martin

[Adrian-Ken Rüegsegger]

Martin Willi wrote:
>> You could register a new SADB algorithm id in pfkeyv2.h and add a new
>> entry to the aalg_list analogous to how GCM is doing that in the aead_list.
>>
>> Adrian
>
> We could do that, but SADB_X_AALG_SHA2_256HMAC (5) actually refers to
> 128 bit truncation. 96 bit truncation is a leftover of
> draft-ietf-ipsec-ciph-sha-256-00 and has been replaced by 128 bit
> truncation in draft-ietf-ipsec-ciph-sha-256-01.
>
> draft-kelly-ipsec-ciph-sha2 and the resulting RFC4868 define 128 bit
> truncation for SADB_X_AALG_SHA2_256HMAC (5), so 96 bit truncation is
> really obsolete. We could define a new PF_KEY algorithm for 96 bit
> truncation, but it is not really usable as it is not standardized.

I agree that 96bit truncation is obsolete and 128 bit should be used.
However people might be using the current implementation and this patch
could cause trouble for them. The question is if anybody really depends
on the current behavior.

Adrian

[Herbert Xu]

On Thu, Jun 05, 2008 at 04:58:49PM +0200, Adrian-Ken Rüegsegger wrote:
>
> I agree that 96bit truncation is obsolete and 128 bit should be used.
> However people might be using the current implementation and this patch
> could cause trouble for them. The question is if anybody really depends
> on the current behavior.

I think the way we're currently representing the truncation length
is not ideal. We should move over to the way it's done for AEAD
algorithms, i.e., let user-space supply us with the truncation
length. That way the problem lies with them :) More importantly,
this would allows us to support multiple truncation lengths.

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <her...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt