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

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

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.

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.

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