cksum: add length support for shake128 and shake256 validation#11320
cksum: add length support for shake128 and shake256 validation#11320RenjiSann merged 1 commit intouutils:mainfrom
Conversation
|
GNU testsuite comparison: |
|
I think length's unit is coming from https://codeberg.org/maandree/sha3sum . |
|
I agree the length option being undecidedly in bits or bytes is an issue, and we should try to stay coherent. The only issue I have with that is that we should make sure we are not going against strongly established existing implementations On another topic, tbh I am not a fan of not writing the length in the tagged output because it is the default length, and I think we should make our output as explicit as possible (while still being able to decode tagged lines that are missing the length. WDYT ? |
|
Just follow with ? |
The more I think of it, the less I'm convinced. I think we can deviate from GNU behavior here and provide the XOF length every time. The output will still be compatible with GNU, though, so it's not a big deal. |
|
Since GNU does not have definition for them yet, including length always is useful. |
8b1c918 to
2d096df
Compare
|
GNU testsuite comparison: |
Merging this PR will not alter performance
Comparing Footnotes
|
0f96d8a to
0817bd7
Compare
|
GNU testsuite comparison: |
0817bd7 to
53bcdb9
Compare
|
GNU testsuite comparison: |
As pure XOF hashes, shake* algos don't make much sense if we don't specify the length. This follows the current behaviour of the blake2b algo, where the length is appended (when not the default) in the same way as with the sha3 family.
It is unfortunate that bit and byte length are used in the same variable for different algos right now. I'm tempted to have another PR to make this uniform.