Collin Funk wrote: > >> * 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
Thanks for testing. Now I'm convinced of the absence of a fatal typo somewhere. > > 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. I see. Indeed, some Gnulib modules make fewer assumptions than others / strive for greater portability than others. Well spotted! Bruno
