[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
SHA-1 was deprecated by NIST at the end of 2010 for digital signature generation and is not allowed after December 31, 2013 (specifically in government applications and recommended guidance for the rest of us). It can be used for validation purposes for legacy signatures beyond end of year though but I don't see adding it to the specification if it doesn't already exist in the real world. See Pages 13 & 14 of SP800-131A for more details. http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf Bob L. -----Original Message----- From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Dina Kurktchi Sent: Monday, August 05, 2013 11:43 AM To: pkcs11@lists.oasis-open.org Subject: Re: [pkcs11] Proposal: CKM_SHA512_224, CKM_SHA512_256, CKM_SHA512_T 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. > > 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.ph >> p >> >> > > > --------------------------------------------------------------------- > 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]