Open httpjamesm opened 5 months ago
Hi @httpjamesm
Thanks for bringing up this suggestion! I'm definitely not opposed to supporting BLAKE3.
Whether or not it should be the default in the high-level API can be discussed, once we get closer to providing an actual implementation. I'm not a big fan of adding orion::hash::digest_blake3
specifically, as anything in the higher-level modules is intended to incur the least amount of decision making from the user, so I'm tending strongly towards keeping it at a single primitive there.
In either case, we need to provide it in the hazardous
module as well.
Is a BLAKE3 implementation something you're interested in working on?
Possibly. Just taking a quick look at the code and I had a few questions:
blake3
package and essentially "remap" the existing hazardous hash functions to blake3 functions?blake2b_core
here. Is that a public crate?We normally try to avoid this. Orion is intended as an alternative to other crates, with a focus on a trimmed-down dependency tree. So we normally provide concrete implementations from Orion directly.
No, that's part of the mod.rs
file here: https://github.com/orion-rs/orion/blob/39d57ba9aefbca262db921064bf94e828a4db3de/src/hazardous/hash/blake2/mod.rs#L26
Summary Brief explanation of the feature.
Orion currently supports Blake2b hashing through
which uses Blake2b-256. However, Blake3 is 7x faster https://github.com/wazuh/wazuh/issues/15632.
Basic example If the proposal involves a new or changed API, include a basic code example. Omit this section if it's not applicable.
I propose adding Blake3 through another function to prevent breaking old code. Maybe
orion::hash::digest_blake3
?