OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[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 Bob -

Dina wasn't asking about SHA-1, but rather SHA-512/160 - which takes
as much space as the SHA-1 digest (good for retrofit into older
protocols that didn't leave expansion space).

Valerie

On 08/ 5/13 12:16 PM, Lockhart, Robert wrote:
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







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]