[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Concerns with SHA512/t
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]