-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider updating hasher domain separation #227
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hasher domain separation is currently handled in a bespoke and fairly complex manner. While the current approach means that domain separation is effectively in a human-readable form, it requires special handling and could be subject to edge cases. It may be a good idea to simplify and harden how this is done.
One approach that is likely to be simpler and less prone to error or edge cases is to ensure that all input entering an underlying hash function be prepended with a type flag that indicates the nature of the input: domain separator, version, label, or arbitrary data. Any type corresponding to variable-length input then includes a little-endian 64-bit encoding of the length, followed by the data itself. Any type corresponding to fixed-length input (like the version, which is always a single byte) does not need a length encoding.
This design is also more flexible, since it supports the addition of new input types via a change to the flag list and even supports things like composition via addition of multiple domain separators or labels.
The text was updated successfully, but these errors were encountered: