[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
On 08/06/13 09:03, Michael StJohns wrote:
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.
I did go round and round with myself about this before posting the proposal. The first few drafts had more explanatory text, but in the end I chose to stop rewriting FIPS 180-4 and removed it all.
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.
"SHA-512/t" is the name of the digest method as described in section 5.3.6 of FIPS 180-4. By calling it by its name, I thought it would beclear which digest method I meant. I see how it can be mistaken for "Truncated message digests" in section 7.
Yes, stating the CKM_SHA512_224 and CKM_SHA512_256 are special cases of CKM_SHA512_T is no problem. It may even be useful to rewrite this as one section instead of three, and make CKM_SHA512_224 and CKM_SHA512_256 subsections of the main one. Can I leave that to the doc editors, or do I need to do this myself? D.
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 does nothing 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 et al - 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--------------------------------------------------------------------- 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]