Bruno Haible <[email protected]> writes:
> Great work!
Thanks!
>> + * lib/sha3.c: New file.
>> + * lib/sha3.h: Likewise.
>
> Do these files borrow significant code from other lib/sha* files?
> If so, it would be good to indicate this in the ChangeLog entry
> ("New file, based on ..."), just as a precaution measure against possible
> future copyright claims.
For the sha3.h I copied a significant amount from sha512.h, including
modifying the comments to match the block size and digest size of SHA-3.
The intent there was mostly to make the API similar.
There are parts of sha3.c taken from sha512.c like 'set_uint64'. The
'sha3_process_bytes' function could not be created in the same way as
the sha512 version since the block size of SHA-3 is not a power of 2.
The 'sha3_read_ctx' function is similar to the versions in sha512.c, but
had to be modified since the digest length is not always divisible by
the state word size (224 % 64 == 32).
I'll add a note in the ChangeLog. Aside from copyright it seems like a
good reference.
>> * tests/test-sha3-224-buffer.c: Likewise.
>> * tests/test-sha3-256-buffer.c: Likewise.
>> * tests/test-sha3-384-buffer.c: Likewise.
>> * tests/test-sha3-512-buffer.c: Likewise.
>
> Did you check the expected results against the results of some other
> implementation than yours? In other words, where is the proof that the
> new code does not have a silly typo somewhere, that leads to completely
> different results than those described by FIPS-202?
>
> (Yes, you said that you haven't added the OpenSSL alternative yet. But
> maybe it is easy to run openssl interactively, to produce their results,
> and compare?)
Yep. The 'openssl <CIPHER>' command has an output that is similar to
'cksum'. I have a patch for coreutils that is likely incomplete, but
works for testing at least:
$ dd if=/dev/random of=test-input count=5000000 bs=1000
5000000+0 records in
5000000+0 records out
5000000000 bytes (5.0 GB, 4.7 GiB) copied, 40.5068 s, 123 MB/s
$ ./src/cksum -a sha3 -l 224 test-input
SHA3-224 (test-input) =
042869f6039e8d1c64115cefc2d40b0e72486a41fd9523345c018e2c
$ openssl sha3-224 test-input
SHA3-224(test-input)=
042869f6039e8d1c64115cefc2d40b0e72486a41fd9523345c018e2c
$ ./src/cksum -a sha3 -l 256 test-input
SHA3-256 (test-input) =
b4bb9fd80135606f99b253520341a713ec8487307e156c6e5060fcccf83fa419
$ openssl sha3-256 test-input
SHA3-256(test-input)=
b4bb9fd80135606f99b253520341a713ec8487307e156c6e5060fcccf83fa419
$ ./src/cksum -a sha3 -l 384 test-input
SHA3-384 (test-input) =
37afa74e515be7c4e4cbe737e30acc49e96919d4d3a7221fbfad649adef1b6b9b2b4fa55eb2548ee02356b9bd77f003d
$ openssl sha3-384 test-input
SHA3-384(test-input)=
37afa74e515be7c4e4cbe737e30acc49e96919d4d3a7221fbfad649adef1b6b9b2b4fa55eb2548ee02356b9bd77f003d
$ ./src/cksum -a sha3 -l 512 test-input
SHA3-512 (test-input) =
d213d59a73ddb319510d608807799d3312f3a45c608c3124fa3d2c4ff24f7e2de93f44ec3cc34f573b6634236335fa4df9ee536d10c820041b006607bdc8b0ff
$ openssl sha3-512 test-input
SHA3-512(test-input)=
d213d59a73ddb319510d608807799d3312f3a45c608c3124fa3d2c4ff24f7e2de93f44ec3cc34f573b6634236335fa4df9ee536d10c820041b006607bdc8b0ff
> Re u64 support: I wouldn't have gone through the trouble of using the 'u64'
> module. Lots of other code in Gnulib assumes an uint64_t type in <stdint.h>,
> for more than 10 or 15 years. But this is not an objection.
I generally agree. I wrote it using uint64_t at first but then changed
it after seeing the following commit:
commit 6cf3388fa179a1e089a101703b403c7976ae6c8f
Author: Paul Eggert <[email protected]>
AuthorDate: Sat May 18 19:02:48 2024 -0700
Commit: Paul Eggert <[email protected]>
CommitDate: Sat May 18 19:04:36 2024 -0700
sha512-buffer: port back to 32-bit-only hosts
Port to platforms lacking 64-bit integers (something that Emacs
still attempts to do, in theory) by adding an u64bswap primitive
to u64.h and using that, instead of using bswap_64.
And I figured that Emacs would probably like to add SHA-3 (or at least
be willing to add it if I wrote a patch).
Collin
