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

[Andrey Jivsov <Andrey_Jivsov@symantec.com>]

In summary, I am not sure what is lost if the issue of truncation is 
left to applications.

See more bellow...

On 08/06/2013 12:51 PM, Dina Kurktchi wrote:
> On 08/06/13 10:25, Andrey Jivsov wrote:
> > On 08/05/2013 06:20 PM, Michael StJohns wrote:
> > > There's some disconnect going on here. SHA1 has been
> > > deprecated/prohibited only for signatures, it's still permitted for
> > > general hashes, KDFs, PRFs and HMACs. So for the current document, its
> > > perfectly acceptable to talk about 160 bit lengths.
> > For non-digital signature uses (i.e. for applications that don't depend
> > on collision resistance) there is no known weakness in SHA-1. These
> > applications can continue using SHA-1. There won't be a compliance issue
> > regarding this (again, in non-digital signature applications).
> >
> > The question remains: where would SHA-512/160 be needed today and in the
> > future? I don't see such a use.
> SHA-512/160 is not part of the proposal.
>
> The question for this group is about SHA-512/t generic and special
> cases SHA-512/224, SHA-512/256.  The only reason SHA-512/160 came up
> was my response to why SHA-512/t generic was included -- I indicated
> we have a use for SHA-512/160, hence that "opening".
>
> NIST has not disallowed any value of t, except t=384.  NIST defined
> a general method to compute SHA-512/t for all other 0 < t < 512.
> NIST took an additional step of approving t=224 and t=256 as meeting
> their security guidelines at this time.  That step does not preclude
> other t, nor outright truncation of digests to lengths different from
> those provided in FIPS 180-4.

I understand this, but my point was that SHA-512/160 (or any t<224) is a 
special case. If the use of SHA-512/160 falls into the category of 
collision resistance (i.e. digital signature applications), it's not 
approved by NIST.

> 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.)
BTW, my comments in this thread were to provide my opinion for why I 
think /160 is not included (with its own constants K).

> Even PKCS#11 uses trunc( SHA-1(text), 3 bytes) in a couple places.
> There may even be a use for SHA-512/24 -- but it's not part of the
> proposal either.

... yet let me observe that SHA-1/24 would be equivalent here to 
SHA-512/24 (clearly, a non-signature use). If one insists on 
all-SHA-512, it's a an edge case, but it has a neat solution: let the 
caller truncate the hash.