Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
llvm-project
The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
The full advisory is linked at https://github.com/XKCP/XKCP/security/advisories/GHSA-6w4m-2.... In order for an application to be vulnerable, it must:
1. Break the file into multiple chunks and pass them to SHA-3 individually.
2. Make one of those chunks larger than 4 GB in size. (This requires using 4 GB of memory.)
This is kind of an unlikely thing for an application to do. If you're breaking the file into chunks, usually you'd use smaller chunks. (And if your server is limited to less than 4 GB of RAM, you might not be able to allocate enough memory to trigger the vulnerability in any case.) But it could be exploitable in some really weird or poorly written application somewhere.
The version in the Golang stdlib is a pure-go implementation, but there's an assembler variant optimized for amd64 (https://github.com/golang/crypto/blob/master/sha3/keccakf_am...), which is apparently derived from the XKCP package.
Bad news for the (mostly-Golang) Ethereum ecosystem...
Phew. It works.
gem specific_install https://github.com/steakknife/digest-sha3-ruby
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 if than when.