Re: [pkcs11] Proposal: CKM_SHA512_224, CKM_SHA512_256, CKM_SHA512_T

[Dina Kurktchi <dina.kurktchi@oracle.com>]

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.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