The library does not provide the FIPS-4 init vectors for truncated Sha_512 variants

[dasgibtesjanicht]

The FIPS-4 document mandates different init vectors for the approved Sha512_256 and Sha512_224 truncated variants. The library needs to provide the these init vectors and some backwards compatible means in the API to ask for these. One possibility is to define a couple of new flags that are looked at when we do the first "submit". that way any existing code that does not care about these can run unchanged, and people who want to calculate these truncated sha-s in a FIPS-4 compliant way will have the option to do so.
The sha512_256 digest would be esp. useful, as it provides a compact, collision resistant, and fast-running digest option for storage applications.

[gbtucker]

Thanks for the request. We had a user say they will submit a sha224 shortened code for review soon. We haven't seen any requests for sha512_256. Do you have a need for it?

[dasgibtesjanicht]

Hi Greg, Thanks for getting back to me. I have actually hacked the code already. I leveraged the "flags" field of the submit function, and added a couple of extra flags to switch the init vector to the appropriate FIPS-4 mandated initializer for the 224 and 256 bit truncated sha-512. (To keep the API backwards compatible) For Dedupe hashing Sha512_256 is the sweet spot, being as compact as, and significantly faster to compute than the sha-256, and having about the same collision strength. I made the request, because it would be simpler for my co. to use an Intel provided implementation than to rely on an in-house modified version. The obvious solution would be to contribute my changes, but I work for a really large company, with a complicated set of internal approvals needed for such submission. /sG/

…

On October 13, 2017 at 2:09 PM Greg Tucker ***@***.***> wrote: Thanks for the request. We had a user say they will submit a sha224 shortened code for review soon. We haven't seen any requests for sha512_256. Do you have a need for it? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub #9 (comment) , or mute the thread https://github.com/notifications/unsubscribe-auth/AHBf3Mg6Zkd8EK2VY8DyPHww0DSplhsmks5sr6dWgaJpZM4P4hbe .

[Bulat-Ziganshin]

do you store hash values for later usage? if no, there is an order of magnitude faster alternative - VMAC/UMAC algorithms. MAC can be considered as keyed hash. If an attacker doesn't know the key, it's no easier to generate a dup than to recover AES-encrypted text (AES is used as part of these algos).

With SHA, the faster approach to hashing is to use multi-buffer API, check in particular chunking_with_mb_hash.c - this way sha256 became faster than sha512 and moreover, it will accelerate on armv8/sha-ni cpus