On 01/09/2025 03:56, Collin Funk 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
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 vulnerable 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?
Collin
[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
Hi Collin, this is really good.
As we discussed, selecting the size with --length is a nice cleanup,
rather than listing out each SHA3-<DIGEST-SIZE> option.
I would simplify the interface though, and not extend it
to select arbitrary lengths on fixed size digests.
If you were to do this the SHA3-<DIGEST-SIZE>/<TRUNCATED-SIZE>
would be the most appropriate format, but it would introduce complication
as you'd need to parse that also for --check.
Also truncation has limited use cases best contained in libs rather than tools.
So I would keep it simple so that:
--length selects fixed sizes for sha3.
I.e. it will reject anything other than {224,256,384,512}
--length continues to select arbitrary sizes for blake2b
(and possibly in future shake128 or shake256}
--length is required with --algorithm=sha3
so that there is no ambiguity in size chosen.
I.e. there is no default for fixed size digests.
Since there is no default, -<DIGEST-SIZE> should always output for SHA3
(or any (future) fixed size digest)
thanks!
Padraig
p.s. I'm thinking cksum might deprecate the explicit -a sha{224,256,384,512},
instead preferring -a sha2 -l {224,256,384,512}, which is more symmetrical and
neater.
Though for interop compat we would not change the output tag, keeping
SHA{224,256,384,512}.
