Hacker News Reader

Comment by metadat | Hacker News Reader

If you're familiar with SHA-256 and this is your first encounter with SHA-3:

The main differences between the older SHA-256 of the SHA-2 family of FIPS 180, and the newer SHA3-256 of the SHA-3 family of FIPS 202, are:

* Resistance to length extension attacks.

* Performance. The SHA-2 functions—particularly SHA-512, SHA-512/224, and SHA-512/256—generally have higher performance than the SHA-3 functions. Partly this was out of paranoia and political reasons in the SHA-3 design process.

Further reading: https://crypto.stackexchange.com/questions/68307/what-is-the...

View on HN

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

[2] https://crypto.stackexchange.com/questions/26336/sha-512-fas...

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).

Allegedly, SHA-256 can often be faster than MD5 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.

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.

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?

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).

Is your software using SHA instructions?

I imagine the sha256sum program would use the best available technique.

Reasonable assumption?

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.)

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.

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.

*2014, yes it was a typo

SHA-3 was also designed with hardware performance in mind IIRC, as in: if it becomes supported in hardware it will be much faster than SHA-2 hardware support.

Some of the more recent 64-bit ARM CPUs have added hardware support for SHA-3 (SHA3 is optional in architectures Armv8.2-A and later, i.e. in Cortex-A55, Cortex-A75 and later, i.e. starting with the smartphones from 2018).

My understanding was that sha-3 should be faster than sha-2, in a general sense, but sha-2 has hardware acceleration. Is that incorrect?

I think SHA-3 is almost always slower in software, in theory SHA-3 could be hardware accelerated of course, but on both current AMD and Intel systems it's not, where SHA-2-256 is.

AArch64 supports accelerated SHA-3, available on production systems since 2019 with the Apple A13, judging by https://github.com/llvm/llvm-project/blob/c35ed40f4f1bd8afd7...

Power10 also supports accelerated SHA-3: https://www.redbooks.ibm.com/redpapers/pdfs/redp5649.pdf (p150)

Accelerated SHA-3 on x86_64 is probably an inevitability; the question is more when than if.

SHA-3 is available on QuickAssist.

https://csrc.nist.gov/projects/cryptographic-algorithm-valid...

For those not familiar with QuickAssist, it is a cryptography and compression accelerator connected through PCIe, which is available in some models of Intel server CPUs or server chipsets and in a few models of Intel server Ethernet NICs.

Moreover, the laptop variants of Alder Lake (H-series, P-series and U-series) are said in the Intel Ark web site to include a subset of QuickAssist, but I have not been able to find any public Intel document explaining which functions are supported by laptop Alder Lake CPUs or any report of someone testing these functions on laptop Alder Lake CPUs.

Most Android smartphones support SHA3 starting with the 2018 models (i.e. Cortex-A55, Cortex-A75 or newer).

i thought sha-2 included the message length in the head padding to prevent length extension attacks?

just read the link you provided: it's sha-224 and above.

i wonder if a similar issue exists in the sha-224+ padding code.

I think you've badly misunderstood what's going on here. SHA-2 includes SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256. Six functions. Of these SHA-256 and SHA-512 are subject to the length extension attack (and SHA-224 only has 32-bit worth of safety which is clearly inadequate). Since you probably only needed a 256-bit hash, SHA-512/256 is a choice available today which produces a 256-bit hash without the possibility of length extension.

Length extension works because the hash is the entire internal hash function state. This is not true for SHA-224, SHA-384, SHA-512/224 or SHA-512/256 since for these four functions not all of the internal state is exposed.

No, the length is not included at the start of the data to be hashed, this would mean committing to entire input before we hash it, which is a pretty unsatisfactory API, the length is appended (with the padding).

> I think you've badly misunderstood what's going on here.

that sounds right. been almost a decade since i've dug into sha-2.

i do remember the lengths in sha-256 and sha-512 though and i remember not being a huge fan of the chunking/padding code.

come to think of it, there's another reason for the message length in the padding. i forget what it is now.

Reply on news.ycombinator.com