[3/4] linux-generic: crypto: add SHA-1 authentication support

Message ID 1493758812-21347-3-git-send-email-odpbot@yandex.ru
State New
Headers show
Series
  • [1/4] validation: crypto: add HMAC-SHA-1-96 test cases
Related show

Commit Message

Github ODP bot May 2, 2017, 9 p.m.
From: Dmitry Eremin-Solenikov <dmitry.ereminsolenikov@linaro.org>


Signed-off-by: Dmitry Eremin-Solenikov <dmitry.ereminsolenikov@linaro.org>

---
/** Email created from pull request 10 (lumag:crypto-update)
 ** https://github.com/Linaro/odp/pull/10
 ** Patch: https://github.com/Linaro/odp/pull/10.patch
 ** Base sha: 0b1dbf37b4030c6da4c6f13645c63fd4ac8ff923
 ** Merge commit sha: 72489ef29ea4586f487b1c806cf37fab63272c7a
 **/
 platform/linux-generic/odp_crypto.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

Comments

Peltonen, Janne (Nokia - FI/Espoo) May 3, 2017, 2:17 p.m. | #1
Hi,

I think there is a problem or ambiguity in the ODP API spec regarding
the truncation of the HMAC output.

According to RFC 2104 the terminology goes so that HMAC-{hash-func} (e.g.
HMAC-SHA-512) means the HMAC with the full, non-truncated output and
HMAC-{hash-func}-{bits} (e.g. HMAC-SHA-512-256) means the HMAC output
truncated to {bits} bits.

The existing implementation (and this patch too) calculates the
truncated output, even though the algorithm names do not indicate
it. The deprecated names did indicate the output length (but not
that the algorithms were HMACs).

Now it is not possible to get the non-truncated output, which are
used at least in IKE PRFs.

	Janne


> -----Original Message-----

> From: lng-odp [mailto:lng-odp-bounces@lists.linaro.org] On Behalf Of Github ODP bot

> Sent: Wednesday, May 03, 2017 12:00 AM

> To: lng-odp@lists.linaro.org

> Subject: [lng-odp] [PATCH 3/4] linux-generic: crypto: add SHA-1 authentication support

> 

> From: Dmitry Eremin-Solenikov <dmitry.ereminsolenikov@linaro.org>

> 

> Signed-off-by: Dmitry Eremin-Solenikov <dmitry.ereminsolenikov@linaro.org>

> ---

> /** Email created from pull request 10 (lumag:crypto-update)

>  ** https://github.com/Linaro/odp/pull/10

>  ** Patch: https://github.com/Linaro/odp/pull/10.patch

>  ** Base sha: 0b1dbf37b4030c6da4c6f13645c63fd4ac8ff923

>  ** Merge commit sha: 72489ef29ea4586f487b1c806cf37fab63272c7a

>  **/

>  platform/linux-generic/odp_crypto.c | 12 +++++++++++-

>  1 file changed, 11 insertions(+), 1 deletion(-)

> 

> diff --git a/platform/linux-generic/odp_crypto.c b/platform/linux-generic/odp_crypto.c

> index 0670755..79e582e 100644

> --- a/platform/linux-generic/odp_crypto.c

> +++ b/platform/linux-generic/odp_crypto.c

> @@ -54,6 +54,9 @@ static const odp_crypto_cipher_capability_t cipher_capa_aes_gcm[] = {

>  static const odp_crypto_auth_capability_t auth_capa_md5_hmac[] = {

>  {.digest_len = 12, .key_len = 16, .aad_len = {.min = 0, .max = 0, .inc = 0} } };

> 

> +static const odp_crypto_auth_capability_t auth_capa_sha1_hmac[] = {

> +{.digest_len = 12, .key_len = 20, .aad_len = {.min = 0, .max = 0, .inc = 0} } };

> +

>  static const odp_crypto_auth_capability_t auth_capa_sha256_hmac[] = {

>  {.digest_len = 16, .key_len = 32, .aad_len = {.min = 0, .max = 0, .inc = 0} } };

> 

> @@ -561,7 +564,7 @@ int odp_crypto_capability(odp_crypto_capability_t *capa)

> 

>  	capa->auths.bit.null         = 1;

>  	capa->auths.bit.md5_hmac     = 1;

> -	capa->auths.bit.sha1_hmac    = 0;

> +	capa->auths.bit.sha1_hmac    = 1;

>  	capa->auths.bit.sha256_hmac  = 1;

>  	capa->auths.bit.sha512_hmac  = 0;

>  	capa->auths.bit.aes_gcm      = 1;

> @@ -635,6 +638,10 @@ int odp_crypto_auth_capability(odp_auth_alg_t auth,

>  		src = auth_capa_md5_hmac;

>  		num = sizeof(auth_capa_md5_hmac) / size;

>  		break;

> +	case ODP_AUTH_ALG_SHA1_HMAC:

> +		src = auth_capa_sha1_hmac;

> +		num = sizeof(auth_capa_sha1_hmac) / size;

> +		break;

>  	case ODP_AUTH_ALG_SHA256_HMAC:

>  		src = auth_capa_sha256_hmac;

>  		num = sizeof(auth_capa_sha256_hmac) / size;

> @@ -740,6 +747,9 @@ odp_crypto_session_create(odp_crypto_session_param_t *param,

>  	case ODP_AUTH_ALG_MD5_96:

>  		rc = process_auth_param(session, 96, 16, EVP_md5());

>  		break;

> +	case ODP_AUTH_ALG_SHA1_HMAC:

> +		rc = process_auth_param(session, 96, 20, EVP_sha1());

> +		break;

>  	case ODP_AUTH_ALG_SHA256_HMAC:

>  	     /* deprecated */

>  	case ODP_AUTH_ALG_SHA256_128:
Dmitry Eremin-Solenikov May 3, 2017, 2:54 p.m. | #2
On 03.05.2017 17:17, Peltonen, Janne (Nokia - FI/Espoo) wrote:
> Hi,

> 

> I think there is a problem or ambiguity in the ODP API spec regarding

> the truncation of the HMAC output.

> 

> According to RFC 2104 the terminology goes so that HMAC-{hash-func} (e.g.

> HMAC-SHA-512) means the HMAC with the full, non-truncated output and

> HMAC-{hash-func}-{bits} (e.g. HMAC-SHA-512-256) means the HMAC output

> truncated to {bits} bits.

> 

> The existing implementation (and this patch too) calculates the

> truncated output, even though the algorithm names do not indicate

> it. The deprecated names did indicate the output length (but not

> that the algorithms were HMACs).


Output is truncated up to the length specified in
param->auth_range.length. However you are right that digest capabilities
should be updated to reflect full digest length. If I have time, I'll
take a look on it.

-- 
With best wishes
Dmitry
Peltonen, Janne (Nokia - FI/Espoo) May 4, 2017, 6:34 a.m. | #3
Dmitry Eremin-Solenikov [mailto:dmitry.ereminsolenikov@linaro.org] wrote:
> 

> On 03.05.2017 17:17, Peltonen, Janne (Nokia - FI/Espoo) wrote:

> > Hi,

> >

> > I think there is a problem or ambiguity in the ODP API spec regarding

> > the truncation of the HMAC output.

> >

> > According to RFC 2104 the terminology goes so that HMAC-{hash-func} (e.g.

> > HMAC-SHA-512) means the HMAC with the full, non-truncated output and

> > HMAC-{hash-func}-{bits} (e.g. HMAC-SHA-512-256) means the HMAC output

> > truncated to {bits} bits.

> >

> > The existing implementation (and this patch too) calculates the

> > truncated output, even though the algorithm names do not indicate

> > it. The deprecated names did indicate the output length (but not

> > that the algorithms were HMACs).

> 

> Output is truncated up to the length specified in

> param->auth_range.length.


No, output (i.e. the digest) is truncated to the length hard-coded for
each algorithm. param->auth_range.length specifies the range of input
data to be authenticated.

	Janne
Dmitry Eremin-Solenikov May 4, 2017, 11:47 a.m. | #4
On 04.05.2017 09:34, Peltonen, Janne (Nokia - FI/Espoo) wrote:
> 

> Dmitry Eremin-Solenikov [mailto:dmitry.ereminsolenikov@linaro.org] wrote:

>>

>> On 03.05.2017 17:17, Peltonen, Janne (Nokia - FI/Espoo) wrote:

>>> Hi,

>>>

>>> I think there is a problem or ambiguity in the ODP API spec regarding

>>> the truncation of the HMAC output.

>>>

>>> According to RFC 2104 the terminology goes so that HMAC-{hash-func} (e.g.

>>> HMAC-SHA-512) means the HMAC with the full, non-truncated output and

>>> HMAC-{hash-func}-{bits} (e.g. HMAC-SHA-512-256) means the HMAC output

>>> truncated to {bits} bits.

>>>

>>> The existing implementation (and this patch too) calculates the

>>> truncated output, even though the algorithm names do not indicate

>>> it. The deprecated names did indicate the output length (but not

>>> that the algorithms were HMACs).

>>

>> Output is truncated up to the length specified in

>> param->auth_range.length.

> 

> No, output (i.e. the digest) is truncated to the length hard-coded for

> each algorithm. param->auth_range.length specifies the range of input

> data to be authenticated.


Hmm. True. auth.bytes gets set in setting auth param from hardcoded
values. I'd propose to change auth capabilities to have min and max
digest lengths and add auth_digest_len to session creation params.
What do you think?

These patches will concern api-next anyway, so we can get them in after
SHA-1/SHA-512.

-- 
With best wishes
Dmitry
Savolainen, Petri (Nokia - FI/Espoo) May 4, 2017, 12:57 p.m. | #5
> -----Original Message-----

> From: lng-odp [mailto:lng-odp-bounces@lists.linaro.org] On Behalf Of

> Dmitry Eremin-Solenikov

> Sent: Thursday, May 04, 2017 2:47 PM

> To: Peltonen, Janne (Nokia - FI/Espoo) <janne.peltonen@nokia.com>; Github

> ODP bot <odpbot@yandex.ru>; lng-odp@lists.linaro.org

> Subject: Re: [lng-odp] [PATCH 3/4] linux-generic: crypto: add SHA-1

> authentication support

> 

> On 04.05.2017 09:34, Peltonen, Janne (Nokia - FI/Espoo) wrote:

> >

> > Dmitry Eremin-Solenikov [mailto:dmitry.ereminsolenikov@linaro.org]

> wrote:

> >>

> >> On 03.05.2017 17:17, Peltonen, Janne (Nokia - FI/Espoo) wrote:

> >>> Hi,

> >>>

> >>> I think there is a problem or ambiguity in the ODP API spec regarding

> >>> the truncation of the HMAC output.

> >>>

> >>> According to RFC 2104 the terminology goes so that HMAC-{hash-func}

> (e.g.

> >>> HMAC-SHA-512) means the HMAC with the full, non-truncated output and

> >>> HMAC-{hash-func}-{bits} (e.g. HMAC-SHA-512-256) means the HMAC output

> >>> truncated to {bits} bits.

> >>>

> >>> The existing implementation (and this patch too) calculates the

> >>> truncated output, even though the algorithm names do not indicate

> >>> it. The deprecated names did indicate the output length (but not

> >>> that the algorithms were HMACs).

> >>

> >> Output is truncated up to the length specified in

> >> param->auth_range.length.

> >

> > No, output (i.e. the digest) is truncated to the length hard-coded for

> > each algorithm. param->auth_range.length specifies the range of input

> > data to be authenticated.

> 

> Hmm. True. auth.bytes gets set in setting auth param from hardcoded

> values. I'd propose to change auth capabilities to have min and max

> digest lengths and add auth_digest_len to session creation params.

> What do you think?

> 

> These patches will concern api-next anyway, so we can get them in after

> SHA-1/SHA-512.

> 

> --

> With best wishes

> Dmitry


Sent patches as proposal for adding digest and AAD parameters to the API. All necessary capabilities are in place already.

-Petri

Patch

diff --git a/platform/linux-generic/odp_crypto.c b/platform/linux-generic/odp_crypto.c
index 0670755..79e582e 100644
--- a/platform/linux-generic/odp_crypto.c
+++ b/platform/linux-generic/odp_crypto.c
@@ -54,6 +54,9 @@  static const odp_crypto_cipher_capability_t cipher_capa_aes_gcm[] = {
 static const odp_crypto_auth_capability_t auth_capa_md5_hmac[] = {
 {.digest_len = 12, .key_len = 16, .aad_len = {.min = 0, .max = 0, .inc = 0} } };
 
+static const odp_crypto_auth_capability_t auth_capa_sha1_hmac[] = {
+{.digest_len = 12, .key_len = 20, .aad_len = {.min = 0, .max = 0, .inc = 0} } };
+
 static const odp_crypto_auth_capability_t auth_capa_sha256_hmac[] = {
 {.digest_len = 16, .key_len = 32, .aad_len = {.min = 0, .max = 0, .inc = 0} } };
 
@@ -561,7 +564,7 @@  int odp_crypto_capability(odp_crypto_capability_t *capa)
 
 	capa->auths.bit.null         = 1;
 	capa->auths.bit.md5_hmac     = 1;
-	capa->auths.bit.sha1_hmac    = 0;
+	capa->auths.bit.sha1_hmac    = 1;
 	capa->auths.bit.sha256_hmac  = 1;
 	capa->auths.bit.sha512_hmac  = 0;
 	capa->auths.bit.aes_gcm      = 1;
@@ -635,6 +638,10 @@  int odp_crypto_auth_capability(odp_auth_alg_t auth,
 		src = auth_capa_md5_hmac;
 		num = sizeof(auth_capa_md5_hmac) / size;
 		break;
+	case ODP_AUTH_ALG_SHA1_HMAC:
+		src = auth_capa_sha1_hmac;
+		num = sizeof(auth_capa_sha1_hmac) / size;
+		break;
 	case ODP_AUTH_ALG_SHA256_HMAC:
 		src = auth_capa_sha256_hmac;
 		num = sizeof(auth_capa_sha256_hmac) / size;
@@ -740,6 +747,9 @@  odp_crypto_session_create(odp_crypto_session_param_t *param,
 	case ODP_AUTH_ALG_MD5_96:
 		rc = process_auth_param(session, 96, 16, EVP_md5());
 		break;
+	case ODP_AUTH_ALG_SHA1_HMAC:
+		rc = process_auth_param(session, 96, 20, EVP_sha1());
+		break;
 	case ODP_AUTH_ALG_SHA256_HMAC:
 	     /* deprecated */
 	case ODP_AUTH_ALG_SHA256_128: