feature: implement blake3 hash and keyed hash modes - #641
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #641 +/- ##
==========================================
- Coverage 99.14% 99.02% -0.12%
==========================================
Files 108 113 +5
Lines 19961 20611 +650
==========================================
+ Hits 19791 20411 +620
- Misses 170 200 +30 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
You were unlucky and hit a new Rust version which introduced a new lint which made the CI fail. So no fault at all on your part. If you rebase on current
This is a perfect approach, thank you for taking this into account! |
brycx
left a comment
brycx
left a comment
There was a problem hiding this comment.
Thank you a lot for all this hard work, @jakub-mata! I get the feeling you were careful and put a lot of effort into it, which really tells.
Let me know if any of my review comments don't make sense or you believe you have a better approach.
The new version implements the `Drop` trait for various structs, where zeroization occurs. `Blake3`, which contains the secret key used for a keyed hash (if applicable). ChunkState and TreeStack also implement it, as they contain the key, its traces, or internal state.
brycx
left a comment
brycx
left a comment
There was a problem hiding this comment.
I'll have to think about what to do with the mut self and &mut self a bit more.
The rest is just adding omitted debugs where you've added the zeroization.
The previous solution used a `Mode` struct, which needed to contain the secret key. However, then it cannot derive the `Clone` trait. If containing its reference, lifetime specifier are needed, which muddles the interface. Instead, the common blake3 state is extracted and included within specific `Blake3` and `Blake3Keyed` structs which are exposed publicly.
The chaining value (`cv`) in `ChunkState` contains the secret before the first round is run. Futhermore, it shouldn't be leaked until the last round is finished. `TreeStack` may unnecessarily leak information about the output chaining values which are then compressed. It is ommited in debugs as well.
|
I'm willing to change the API of |
Thank you for sticking with the PR. I'd like to have it use Apart from this change, I believe this is ready to be merged. I'll add documentation in a follow-up PR. |
|
A note for historic design rationales: Because BLAKE3 acts as both a XOF, MAC and Hash, the typical I haven't been able to come up with a reasonable solution for this. Should be considered further for the upcoming While dangerous and not what you'd expect from other modules in |
brycx
left a comment
brycx
left a comment
There was a problem hiding this comment.
Thank you for all your hard work on this, @jakub-mata! Really awesome, I really appreciate it - thank you.
2 participants
This PR introduces the BLAKE3 hash function into the
/hazardousmodule, implemented according to the official BLAKE3 specifications.Features Included:
Note: The "derive key" mode has been omitted from this PR to keep the scope focused on standard hashing. The underlying state machine has been structured so that key derivation can be easily added in a future PR if desired.
Testing includes:
This initial implementation establishes a single-threaded baseline. Because BLAKE3's tree structure is designed for infinite parallelism, a natural next step will be adding a data-parallelism feature flag to support multi-threaded hashing for large inputs.
Resolves #394