[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 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.
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...
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. Mike
If 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]