Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request Dependencies
This builds on top of #3673. @falko-strenzke feel free to incorporate my two patches into your PR and squash it all together. We could then just close this one and merge your's.
Description
This applies further cleanup to
Keccak_Permutation
and widens its versatility somewhat. Most notably:Replace single-shot
::expand()
with more versatile::squeeze()
Just like
::absorb()
before,::squeeze()
can be called multiple times with arbitrary-length buffers. That's really useful for implementing XOFs (see eXtendable Output Functions as first-class citizen #3671).use
BufferStuffer
/BufferSlicer
in::squeeze()
and::absorb()
That's more of a style thing to avoid some raw pointers and lots of offset shifting. IMHO, that makes the code as "readable" as it gets. 🤡
remove low-level access to Keccak state and static mutation methods
I believe that's actually the whole point of this new class: No more fiddling with Keccak-states and offset positions in the implementations of "SHA3", "SHAKE" and the "Keccak" hash. @falko-strenzke please make sure that this interface is enough to implement KMAC as well.
::permute() is now private
Its an implementation detail of the sponge construction and should be handled that way, I think. Or are there use cases where a downstream user would want to have control over when exactly
permute()
should be called?My two cents
Was this refactoring worth it? I think so! The implementations of "SHA3", "SHAKE" and the upcoming "SHAKE" XOF are now super slim an concise. Note though, that the implementations for
SHA_3
andKeccak_1600
(the hash) are basically identical. I hope that's roughly what @randombit had in mind when we started arguing about the architecture back in February (#3279)