pkcs11 — archive

[Andrey Jivsov]

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.