5 ms·

Note that truncated SHA-2 (SHA-224, SHA-384, SHA-512/224, SHA-512/256) are not susceptible to length-extensions attacks [1]. With the added benefit of better p

Note that truncated SHA-2 (SHA-224, SHA-384, SHA-512/224, SHA-512/256) are not susceptible to length-extensions attacks [1]. With the added benefit of better performance of SHA-512 (on 64 bit systems) [2], there's no good reason to use SHA-256 rather than SHA-512/256 for new cryptographic designs. [1] https://en.wikipedia.org/wiki/Length_extension_attack https://en.wikipedia.org/wiki/Length_extension_attack [2] https://crypto.stackexchange.com/questions/26336/sha-512-faster-than-sha-256 https://crypto.stackexchange.com/questions/26336/sha-512-fas...

adrian_b 4y ago
There is a good reason to use SHA-256 and not SHA-512. Many modern CPUs, e.g. all AMD Zen, most Intel Atom, Intel Ice Lake and newer, most 64-bit ARM, have hardware implementations of SHA-256, which are much faster than software computing SHA-512. Only some more recent 64-bit ARM CPUs also have hardware for SHA-512 and SHA-3. Whenever the speed matters, SHA-256 is the best choice, unless you choose different hash algorithms based on the detected CPU. On old 64-bit CPUs without SHA hardware, e.g. Intel Skylake, SHA-512 is faster than SHA-256 (Intel introduced SHA in Atom CPUs many years before also introducing it in Core CPUs, so that Atom could compete in Geekbench scores with the ARM CPUs, which already had SHA).
- metadat 4y ago
  Interesting, in general I've noticed SHA-256 hashing is relatively CPU intensive and slow.. is the 2024 Xeon CPU in my server too old to include the hardware implementation?
  - adrian_b 4y ago
    I think that you might have mistyped the Xeon model number. Nevertheless, most existing Xeon CPUs are too old to have SHA hardware. In Intel server CPUs SHA was introduced many years later than in AMD server CPUs or Intel desktop CPUs, i.e. only in "the 3rd generation Xeon Scalable" based on the Ice Lake Server cores, in Q2 of 2021 (Xeon model numbers 83xx, 63xx and 53xx).
  - tedunangst 4y ago
    Is your software using SHA instructions?
    - metadat 4y ago
      I imagine the sha256sum program would use the best available technique. Reasonable assumption?
      - adrian_b 4y ago
        Last time when I have checked what sha256sum (from coreutils) does was one year ago. At that time, on x86 CPUs (I have not tested on ARM) neither sha256sum nor sha224sum nor sha1sum used the hardware instructions (and I have compiled them from sources, with the appropriate flags). Because I have a Zen CPU (but that would also be true on Atom CPUs or Core CPUs since Ice Lake), I have to use "openssl dgst -r -sha256" instead of sha256sum and "openssl dgst -r -sha1" instead of sha1sum. The openssl implementation uses the hardware instructions where available and in that case it is several times faster. (The "-r" option flag in "openssl dgst" selects an output format that is more similar to the sha???sum tools, i.e. hash value followed by file name, but openssl still outputs an extra character, which must be accounted in scripts.)
        metadat 4y ago
        I also see similarly slow performance when using the Go built-in Sha256 hashing library. Thanks for the info! Fortunately for my purposes of integrity checking, slow is okay.
        adrian_b 4y ago
        I also use them for file integrity checking, but I frequently check large files, e.g. 50 GB files, and in that case the difference in time until finish between "sha256sum" and "openssl dgst -r -sha256" is extremely noticeable on a Zen CPU. On the other hand, on older Skylake/Kaby Lake/Coffee Lake etc. CPUs, both programs have the same speed.
  - metadat 4y ago
    *2014, yes it was a typo
- hot_gril 4y ago
  Allegedly, SHA-256 can often be faster than MD5 https://security.stackexchange.com/a/95697 https://security.stackexchange.com/a/95697 Not to say the algo is faster, it's not, but the CPU has specialized hardware for SHA-256.
- orangepurple 4y ago
  Makes me wonder if there is a microcode back door to these hardware hashers such as one which steers the output after the microprocessor is fed carefully crafted input to cause it to run in a vulnerable state.

adrian_b 4y ago

There is a good reason to use SHA-256 and not SHA-512. Many modern CPUs, e.g. all AMD Zen, most Intel Atom, Intel Ice Lake and newer, most 64-bit ARM, have hardware implementations of SHA-256, which are much faster than software computing SHA-512. Only some more recent 64-bit ARM CPUs also have hardware for SHA-512 and SHA-3. Whenever the speed matters, SHA-256 is the best choice, unless you choose different hash algorithms based on the detected CPU. On old 64-bit CPUs without SHA hardware, e.g. Intel Skylake, SHA-512 is faster than SHA-256 (Intel introduced SHA in Atom CPUs many years before also introducing it in Core CPUs, so that Atom could compete in Geekbench scores with the ARM CPUs, which already had SHA).

metadat 4y ago
Interesting, in general I've noticed SHA-256 hashing is relatively CPU intensive and slow.. is the 2024 Xeon CPU in my server too old to include the hardware implementation?
- adrian_b 4y ago
  I think that you might have mistyped the Xeon model number. Nevertheless, most existing Xeon CPUs are too old to have SHA hardware. In Intel server CPUs SHA was introduced many years later than in AMD server CPUs or Intel desktop CPUs, i.e. only in "the 3rd generation Xeon Scalable" based on the Ice Lake Server cores, in Q2 of 2021 (Xeon model numbers 83xx, 63xx and 53xx).
- tedunangst 4y ago
  Is your software using SHA instructions?
  - metadat 4y ago
    I imagine the sha256sum program would use the best available technique. Reasonable assumption?
    - adrian_b 4y ago
      Last time when I have checked what sha256sum (from coreutils) does was one year ago. At that time, on x86 CPUs (I have not tested on ARM) neither sha256sum nor sha224sum nor sha1sum used the hardware instructions (and I have compiled them from sources, with the appropriate flags). Because I have a Zen CPU (but that would also be true on Atom CPUs or Core CPUs since Ice Lake), I have to use "openssl dgst -r -sha256" instead of sha256sum and "openssl dgst -r -sha1" instead of sha1sum. The openssl implementation uses the hardware instructions where available and in that case it is several times faster. (The "-r" option flag in "openssl dgst" selects an output format that is more similar to the sha???sum tools, i.e. hash value followed by file name, but openssl still outputs an extra character, which must be accounted in scripts.)
      - metadat 4y ago
        I also see similarly slow performance when using the Go built-in Sha256 hashing library. Thanks for the info! Fortunately for my purposes of integrity checking, slow is okay.
        adrian_b 4y ago
        I also use them for file integrity checking, but I frequently check large files, e.g. 50 GB files, and in that case the difference in time until finish between "sha256sum" and "openssl dgst -r -sha256" is extremely noticeable on a Zen CPU. On the other hand, on older Skylake/Kaby Lake/Coffee Lake etc. CPUs, both programs have the same speed.
- metadat 4y ago
  *2014, yes it was a typo
hot_gril 4y ago
Allegedly, SHA-256 can often be faster than MD5 https://security.stackexchange.com/a/95697 https://security.stackexchange.com/a/95697 Not to say the algo is faster, it's not, but the CPU has specialized hardware for SHA-256.
orangepurple 4y ago
Makes me wonder if there is a microcode back door to these hardware hashers such as one which steers the output after the microprocessor is fed carefully crafted input to cause it to run in a vulnerable state.