This is a pure Rust implementation of BLAKE2 based on RFC 7693.
This crate follow the common API design for streaming hash functions, which has one state/context struct and three associated functions: one to initialize the struct, one which is called repeatedly to process the incoming data, and one to do the final processing and return the hash. For the case where the full data is already in memory, there is a convenience function which does these three steps in a single call.
This basic design was slightly adapted to make a better use of Rust's characteristics: the finalization function consumes the struct, doing a move instead of a borrow, so the struct cannot be accidentally used after its internal state has been overwritten by the finalization.
To prevent timing attacks, it's important that the comparison of hash values takes constant time. To make it easier to do the right thing, the finalization function returns the result wrapped in a struct which does a constant-time comparison by default. If a constant-time comparison is not necessary, the hash result can easily be extracted from this struct.
A single BLAKE2b hash is limited to 16 exabytes, lower than its
theorical limit (but identical to the BLAKE2s theorical limit), due to
the use of a
u64 as the byte counter. This limit can be increased, if
necessary, after either the
extprim crate (with its
u128 type) or
OverflowingOps trait become usable with the "stable" Rust release.
This crate does not attempt to clear potentially sensitive data from its work memory (which includes the state context, the stack, and processor registers). To do so correctly without a heavy performance penalty would require help from the compiler. It's better to not attempt to do so than to present a false assurance.
This crate is limited to the features described in the RFC: only the "digest length" and "key length" parameters can be used.
If you need to use other advanced BLAKE2 features, this crate has an undocumented function to create a hashing context with an arbitrary parameter block, and an undocumented function to finalize the last node in tree hashing mode. You are responsible for creating a valid parameter block, for hashing the padded key block if using keyed hashing, and for calling the correct finalization function. The parameter block is not validated by these functions.
This crate has experimental support for explicit SIMD optimizations. It requires nightly Rust due to the use of unstable features.
The following cargo features enable the explicit SIMD optimization:
simdenables the explicit use of SIMD vectors instead of a plain struct
simd_optadditionally enables the use of SIMD shuffles to implement some of the rotates
simd_asmadditionally enables the use of inline asm to implement some of the SIMD shuffles
While one might expect that each of these is faster than the previous
one, and that they are all faster than not enabling explicit SIMD
vectors, that's not always the case. It can vary depending on target
architecture and compiler options. If you need the extra speed from
these optimizations, benchmark each one (the
bench feature enables
cargo bench in this crate, so you can use for instance
--features="bench simd_asm"). They have currently been tuned for SSE2
(x86 and x86-64) and NEON (arm).
Licensed under either of
- Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.