Concerns with SHA512/t

[Valerie Fenwick <valerie.fenwick@oracle.com>]

Hi FOlks -

While reviewing some other content in this area, a member of my
team brought up this concern. Any opinions?

thank you,

Valerie


-------- Forwarded Message --------
Subject: Re: Fwd: [pkcs11] SHA-1 and SHA2 information in v2.40
Date: Wed, 14 Sep 2016 16:14:31 +0200
From: Ferenc R.
Organization: Oracle Corporation
To: Valerie Fenwick <valerie.fenwick@oracle.com>

Hi, Valerie,

  what I noticed is the following, please forward it to whom it
might concern:

there is a digest mechanism, called SHA-512/t where t is a parameter,
the length in bits of the produced hash.

there are HMAC mechanisms, each based on a particular hash function,
called General-length <hash_function>-HMAC.

Now, at the description of the mechanisms involving SHA-512/224,
SHA-512/256 and SHA-512/t (sections 2.22, 2.23 and 2.24) there are
some obvious copy/paste/edit errors, but with the general-length
SHA-512/t-HMAC (2.25.3 - even the name is wrong in the standard)
there is a fundamental problem: this mechanism has two parameters,
one for t and another for the desired output length (in PKCS#11
terms it means a parameter that is a pair of numbers, not just
one number as for the other general mechanisms). I think it also
adds to the confusion that the t parameter of the SHA-512/t digest
mechanism is defined as CK_MAC_GENERAL_PARAMS, although it is
not a MACing mechanism.

I think the remedy can be one of two things:

1. do not allow a general-length SHA-512/t-HMAC mechanism
   (based on the argument that if you want a k-bit MAC, you
   can always just use the HMAC based on SHA-512/t where t=k)
2. define  new parameter types CK_SHA_512_T_PARAMS
    and CK_SHA_512_T_MAC_GENERAL_PARAMS and use those for
    the mechanisms described in 2.25
    (based on the argument that a k-bit MAC truncated from the
    output of the HMAC based on SHA-512/t for t>k is not the same
    as the HMAC based on SHA-512/t where t=k, so this allows
    more flexibility)

I would vote for #2 above.

In the meantime, I am implementing #1 as it is now closer to the
current edition of the standard.

Ferenc