| 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 | expand |
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:
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
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
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
> -----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
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: