[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Proposal: CKM_SHA512_224, CKM_SHA512_256, CKM_SHA512_T
Hi Dina -I went back to FIPS 180-4 and did a bit more reading. I now think I understand what you were trying to do in section 1.3. Unfortunately, your text was ambiguous enough that I didn't catch it.
What I would do is add a specific section reference of FIPS180-4 (e.g. 5.3.6) that identifies the class of truncated hashes you're talking about. I'd also add some discussion that a CKM_SHA512_T with a parameter of 224/8 is the same exact function as CKM_SHA512_224 and equivalently for 256/8 and CKM_SHA512_256.
As your section 1.3 current reads I got it as trunc(SHA512(data), t) not as the section 5.3.6 construct. I object to doing the first one because the effects can be duplicated trivially by doing the truncation externally. The second one can't be done trivially on the output of SHA512.
Assuming you add explanatory text as above I have no further objection.(But seriously - I think this whole class of hashes is a bit of overkill from NIST).
Mike On 8/5/2013 2:43 PM, Dina Kurktchi wrote:
On 08/05/13 11:29, Michael StJohns wrote:On 8/5/2013 1:32 PM, Dina Kurktchi wrote:On 08/05/13 10:10, Michael StJohns wrote:I took a look at this. I don't have a problem with the general addition of SHA512/224 and SHA512/256 to the pot, but I think I'm still not happy (as previously discussed) with adding a set of mechanism types that doesnothing but truncate the result of the other mechanisms.The IV is different for each of the SHA512/t hashes. Thus: trunc( SHA512(text) , 224 ) != SHA512/224( text ), nor is trunc( SHA512/256(text) , 224) != SHA512/224( text ). It is not SHA512(text) "classic" truncated to some shorter length.I was talking about the CKM_SHA512_T etc mechanisms. Not the above. Section 1.3 on in your document.Aha. I was hoping to leave an opening for SHA-512/160, which is not NIST-approved. It is 20 bytes long and fits perfectly into boxed-in spaces formerly containing SHA-1 digests. (Wish NIST had included /160 ... or explained why it wasn't approved.)I note also that this proposal has new key types CKK_SHA512_224_HMAC etal - I think I agree with this, but did we actually agree to do these changes with 2.40? (E.g. adding mechanism specific typing for keys?) I was under the impression that it was a substantial enough change that affected a lot of things that it was deferred to 3.0.Followed the example of the other CKK_*_HMAC that I found in spec.*sigh* Yes. They are there. *sigh* Unfortunately there is still a problem with your text. In the CKM_SHA1_HMAC there is a statement that is missing from your text:The keys it uses are generic secret keys and CKK_SHA_1_HMAC.Or in your case CKK_SHA512_224_HMAC. E.g. you've got a manifest definition with no normative text to describe how that key is used - we can infer, but...I see. I patterned mine off the SHA-512 text, so I missed whatever was back in the SHA-1 section. Yep, some attention here is warranted.The whole key usage for keyed CMAC's and HMAC's text (in the document, not your proposal) needs to be re-worked and cleaned up. Mostly these still use CKK_GENERIC_SECRET. I'd be happier if they used CKK_HMAC rather than something more specific and let the key creator use the CKA_ALLOWED_MECHANISMS attribute to lock the key to a particular HMAC algorithm. Add it to the list of bugs to resolve. MikeIf this goes to ballot for 2.40, I'd like it to be a split ballot with yes/no for the two different groups of mechanisms. I'm not sure what to do about the new CKK_ stuff.Sure, if it needs splitting, I can accommodate. Thanks! D.Mike On 8/2/2013 7:12 PM, Dina Kurktchi wrote:Proposal: CKM_SHA512_224, CKM_SHA512_256, CKM_SHA512_T Addition of new hash algorithms defined in FIPS 180-4: SHA-512/224, SHA-512/256, and general case SHA-512/t. FIPS PUB 180-4, "Secure Hash Standard (SHS)", March 2012 http://www.nist.gov/manuscript-publication-search.cfm?pub_id=910977 The text attached can be inserted immediately after what is now section 2.21 in "PKCS #11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40". The general case SHA-512/t is included for completeness. This proposal is independent of Robert Burns' "Proposal: Update references to FIPS PUB 180". The two ought to be complementary though. Thanks, D. --------------------------------------------------------------------- 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--------------------------------------------------------------------- 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--------------------------------------------------------------------- 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---------------------------------------------------------------------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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]