Closed edward-shen closed 6 months ago
Hey @newpavlov! Sorry for the ping; I know your time is limited but I just wanted to check if this is on your or someone else's radar.
I believe this is a pretty easy-to-trigger API hazard (especially for non-experts) so I wanted to make sure this will be addressed sooner than later. Let me know if it's not the case.
Thanks!
I’d personally like to get #228 over the finish line
Hey @tarcieri, #228 still requires more discussion right? While that also does resolve #509 from what I can tell, the pace of discussion there feels like it won't be merged soon. Of course, I also might not be privy to discussion elsewhere.
This is a very small change that shouldn't create merge conflicts with #228, since as far as I can tell git is treating your blake2 implementation as completely new files.
I'm pushing for this pretty hard because I feel like preventing incorrect construction of hashes is pretty important, but if the project isn't in the state where it can accept PRs or is not accepting new PRs until #228 is merged, please let me know so I don't annoy you or other maintainers!
I will merge this PR, but we probably will replace implementation based on #228 before publishing v0.11.
Fixes #509.
Blake2 0.10 splits keyed hashing into
*Mac
struct variants. However, this permits empty keys to be provided tonew_with_salt_and_personal
, while the implementation assumes a non-empty key. This leads to an invalid construction of Blake2, as thekk
argument of the parameter block will now be0x00
, but buffer is initialized as ifkk > 0x00
.This change introduces a guard to the function, failing if the key was empty.