On Sun, Aug 31, 2025 at 10:57 PM Collin Funk <[email protected]> wrote:
> Hi, > > I have attached a patch adding SHA-3 to 'cksum' using the --algorithm > (-a) option and some tests based off of tests/cksum/b2sum.sh. There are > some details of it that I would like others thoughts on before pushing. > > 1. Originally I wanted the default digest size to be 256 bits instead of > 512 bits like this patch does. This is because for SHA-2, a very large > majority of the time I see SHA-256 being used. Less commonly it is > SHA-512, and even less commonly SHA-224 and SHA-384. If the world > decides to switch to SHA-3 eventually, I would guess that people would > use the same digest size. > > However, this would require more code since the value in the > 'algorithm_bits' array is really treated as a maximum supported by the > algorithm. This also would differ from the default behavior of > 'cksum -a blake2b' which defaults to the greatest supported digest size, > 512 bits. > > Less importantly, my Fedora system has a sha3sum command which is a Perl > script to interface with the Digest::SHA3 module. It defaults to 224 > bits, but I care less about diverging from that. We are cksum not > sha3sum anyways. > > 2. I did not restrict the '--length' option to 224, 256, 384, and 512 > bits. Instead the argument will round up to use the next largest digest > size and then truncate the digest. Here is an example of the behavior on > a file that does not change across program invocations: > > $ ./src/cksum -a sha3 -l 224 COPYING > SHA3-224 (COPYING) = > 0e93a263ef507adafd16b2330ba30384c89f56700198efe7b54588a0 > $ ./src/cksum -a sha3 -l 112 COPYING > SHA3-112 (COPYING) = 0e93a263ef507adafd16b2330ba3 > > $ ./src/cksum -a sha3 -l 256 COPYING > SHA3-256 (COPYING) = > edb0016d9f8bafb54540da34f05a8d510de8114488f23916276bdead05509a53 > $ ./src/cksum -a sha3 -l 232 COPYING > SHA3-232 (COPYING) = > edb0016d9f8bafb54540da34f05a8d510de8114488f23916276bdead05 > > $ ./src/cksum -a sha3 -l 384 COPYING > SHA3-384 (COPYING) = > 93b8fc41e79c2445f8d653c56a1265f12d6c51d54f9ba17c015cde6e35bdb0c4a200a656beab782307bb4912dec1f8f0 > $ ./src/cksum -a sha3 -l 264 COPYING > SHA3-264 (COPYING) = > 93b8fc41e79c2445f8d653c56a1265f12d6c51d54f9ba17c015cde6e35bdb0c4a2 > > $ ./src/cksum -a sha3 -l 512 COPYING > SHA3-512 (COPYING) = > 678655c1f91fb4dbb27e1450fb41bcfd0209339c3493c595ab1fc294dd7a04eb23dc74934aa2229d990b8eb92f8f89528667b7c604548f134c950b0edda374ef > $ ./src/cksum -a sha3 -l 392 COPYING > SHA3-392 (COPYING) = > 678655c1f91fb4dbb27e1450fb41bcfd0209339c3493c595ab1fc294dd7a04eb23dc74934aa2229d990b8eb92f8f895286 > > I am conflicted on this since it might give the impression that SHA-232, > for example, is standardized in FIPS-202 when that is not the case. This > differs from the blake2b specification which states that digests can be > anywhere from 1 to 64 bytes [2]. > > My idea was to use a name similar the truncated SHA-2 algorithms which > NIST standardized, SHA-512/224 and SHA-512/256. They never standardized > similar algorithms for SHA-3, for reasons I do not know of. Maybe > because SHA-3 is not vulnerabile to a length extension attack that SHA-2 > is, but I do not think that was their rational for them in the first > place [3][4]. > > Anyways, I think the notation SHA3-<DIGEST-SIZE>/<TRUNCATED-SIZE> has > less potential to cause problems. NIST acknowledges that there is > sometimes a need to truncate digests [5]. Therefore, I think this > notation would be well understood. > > Thoughts? > > [1] https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.202.pdf > [2] https://www.blake2.net/blake2.pdf > [3] https://en.wikipedia.org/wiki/Length_extension_attack > [4] > https://csrc.nist.gov/csrc/media/Projects/crypto-publication-review-project/documents/initial-comments/fips180-4-initial-public-comments-2022.pdf > [5] > https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r1.pdf > Be careful of truncated hashes. Kelsey showed you cannot simply lop off bits and maintain security levels. The truncated hash use case is one of the use cases handled by SHA3 and the extensible output function (XOF). The idea is, different size outputs produce completely different hashes under the same input. For example, these should produce completely unique outputs, and not share the same "stem" or leftmost bits. $ ./src/cksum -a sha3 -l 224 COPYING SHA3-224 (COPYING) = 0e93a263ef507adafd16b2330ba30384c89f56700198efe7b54588a0 $ ./src/cksum -a sha3 -l 112 COPYING SHA3-112 (COPYING) = 0e93a263ef507adafd16b2330ba3 Jeff
