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

dasgibtesjanicht commented

2017-10-13 08:53:51 -05:00

(Migrated from github.com)

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.

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 commented

2017-10-13 13:09:23 -05:00

(Migrated from github.com)

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 commented

2017-10-13 21:40:04 -05:00

(Migrated from github.com)

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 notifications@github.com 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 https://github.com/01org/isa-l_crypto/issues/9#issuecomment-336527476 , or mute the thread https://github.com/notifications/unsubscribe-auth/AHBf3Mg6Zkd8EK2VY8DyPHww0DSplhsmks5sr6dWgaJpZM4P4hbe .

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 <notifications@github.com> 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 https://github.com/01org/isa-l_crypto/issues/9#issuecomment-336527476 , or mute the thread https://github.com/notifications/unsubscribe-auth/AHBf3Mg6Zkd8EK2VY8DyPHww0DSplhsmks5sr6dWgaJpZM4P4hbe . > > >

Bulat-Ziganshin commented

2017-10-14 16:10:22 -05:00

(Migrated from github.com)

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

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

Rows
Columns

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