[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Concerns with SHA512/t
On 14/11/2016 14:43, Johnson Darren wrote:
Hi, This is my opinion... but I don't feel too strongly on it. So if the group feels differently, I will not object :) I think we should fix it instead of moving it to the legacy list. Mostly just for completeness of the standard. I don’t think there is a strong argument for not supporting General-length HMACs for SHA512/t. If we believe there is an argument for not supporting it... then it would apply to General-length SHA512/224 and SHA512/256 as well as they are also truncated HMACs. (ie why truncate something that is already truncated?). I would argue that the T value is not the same as the General-length truncation value. The T value is also used to define the initial hash values/constants. I think that difference is significant enough that it should be treated separately from the General-length truncation value.
The general length concept in the PKCS#11 functions is useful where the caller has a fixed sized buffer for the output and wants to avoid allocating a buffer only to have to copy the shorter size to the fixed buffer. So it avoids a malloc/memcpy/free, which could be important in some cases.
For SHA512/T (for T not one of 244,256,384) you are already avoiding the extra copy space.
What is the use case for using SHA512/T (which it clearly needs to be for recent code) and then truncating the hash down to something smaller than T ?
Consider we have a fixed buffer of size 160 because the application data format was designed for SHA1. It is being changed to support SHA512. So either you call SHA512/T with T=160 or you call SHA512 and truncate to 160. Why would you do something like SHA512/200 then trim to 160 ? I can't think of an IETF protocol that would use SHA512/T and then do an additional truncation.
My understanding for why SHA512/T came about with different initial pad/IV was so that it was more than just a "chop" and the implication was that was seen to be better security.
If PKCS#11 didn't have the general-length HMAC concept already I wonder if it would get invented now that SHA512/t exists ?
SHA512/t is already special compared to the other mechanisms because it takes a length param, so my personal preferences is that the general length concept is not needed for SHA512/t and is actually confusing and thus potentially dangerous.
DJ -----Original Message----- From: Valerie Fenwick [mailto:valerie.fenwick@oracle.com] Sent: Monday, November 14, 2016 6:26 AM To: Johnson Darren <darren.johnson@gemalto.com>; pkcs11@lists.oasis-open.org Subject: Re: [pkcs11] Concerns with SHA512/t Talking about this with my team now, another proposal is: What if we get rid of the mechanism (ie move it to historical) CK_SHA_512_T_MAC_GENERAL_PARAMS ? The T is already providing the truncation that general provides. (ie why would you truncate something is already truncated?) thoughts? Valerie On 11/10/2016 9:08 PM, Johnson Darren wrote:Hi, I agree, that section is very odd. I raised the same questions/concerns in the SHA1/SHA2 proposal. It was an open ended question in my document that I completely forgot to raise on the last two calls. I apologize for that. My questions were along the same lines as Ferenc's below and I agree completely. If we want to support a CKM_SHA512_T_HMAC_GENERAL mechanism, then it does need two inputs. Ideally using a specific mechanism parameter as defined below by Ferenc. Thanks Darren -----Original Message----- From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Valerie Fenwick Sent: Wednesday, November 09, 2016 3:33 PM To: pkcs11@lists.oasis-open.org Subject: [pkcs11] 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 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php ________________________________ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.-- Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054. ________________________________ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
-- Darren J Moffat
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]