pkcs11 — archive

[Dina Kurktchi-Nimeh]

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