| Age | Commit message (Collapse) | Author |
|---|
|
`Hash::as_bytes()` returns the hash as an array of bytes. However,
sometimes it's useful to have the hash as a slice of bytes instead, such
as for serialization via an API that takes `&[u8]`. While
`.as_bytes().as_slice()` works for this, it'd be more convenient to have
a direct `.as_slice()` on hashes.
|
|
|
|
Previously "std" enabled runtime CPU feature detection on x86, but as of
https://github.com/BLAKE3-team/BLAKE3/pull/469 that's always on.
|
|
|
|
https://github.com/BLAKE3-team/BLAKE3/pull/458
|
|
|
|
This code is based on rust_sse2.rs of the same distribution, and is
subject to further improvements. Some comments are left intact even if
their applicability is questioned.
SIMD implementation is gated by `wasm32-simd` feature, portable version
is used otherwise.
Performance measurements with a primitive benchmark with ~16Kb of data:
| M1 native | 11,610 ns |
| M1 WASM SIMD | 13,355 ns |
| M1 WASM | 22,037 ns |
| x64 native | 6,713 ns |
| x64 WASM SIMD | 11,985 ns |
| x64 WASM | 25,978 ns |
wasmtime v12.0.1 was used on both platforms.
Closes #187.
|
|
This is a convenience method, to avoid having to first call
`<[u8; 32]>::try_from(slice)?`.
|
|
|
|
This was a good suggestion by @dhardy:
https://github.com/rust-random/rand/issues/989#issuecomment-2303969094
|
|
|
|
|
|
Removes dependence on proc-macros when enabling the zeroize feature.
|
|
This mostly reverts commits 8416b1658c2690dc6351bdc7e0975b0d5f1a5282 and
dd0afd640ad97b5ebcf887107162009a23ffdca0.
Changing the serialization of Hash can only be backwards-compatible in
self-describing formats like CBOR. In non-self-describing formats like
bincode, the deserializer has to know in advance which serialization
format was used.
Fixes https://github.com/BLAKE3-team/BLAKE3/issues/414.
Reopens https://github.com/BLAKE3-team/BLAKE3/issues/412.
|
|
Closes #412.
|
|
Signed-off-by: wangcundashang <[email protected]>
|
|
|
|
|
|
Added a new cargo feature `serde` that when enabled will derive
`serde::Serialize` and `serde::Deserialize` for the `blake3::Hash`
struct.
|
|
|
|
This makes them consistent with how the existing update() and
update_rayon() methods work, with the difference being that it's it's
io::Result<&mut Self> instead of just &mut Self.
|
|
New methods:
- update_reader
- update_mmap
- update_mmap_rayon
These are more discoverable, more convenient, and safer.
There are two problems I want to avoid by taking a `Path` instead of a
`File`. First, exposing `Mmap` objects to the caller is fundamentally
unsafe, and making `maybe_mmap_file` private avoids that issue. Second,
taking a `File` raises questions about whether memory mapped reads
should behave like regular file reads. (Should they respect the current
seek position? Should they update the seek position?) Taking a `Path`
from the caller and opening the `File` internally avoids these
questions.
|
|
|
|
As part of this change, I don't think we need the `zeroize_crate`
workaround anymore if we use the relateively new `dep:` syntax in
Cargo.toml.
|
|
|
|
|
|
|
|
The function is `const`, so it is fundamentally different from the
`From` trait implementation by allowing compile-time instantiation of a
`Hash`.
|
|
|
|
|
|
The same change was previously made in README.md.
|
|
|
|
|
|
|
|
https://eprint.iacr.org/2022/283
|
|
|
|
Adjust to the following changes that happened in digest:
- The crypto-mac crate has been merged into digest (with "mac" feature
enabled)
- Various traits have been split up
- The Digest and Mac traits now share their update/finalize/reset
implementations
- The BlockInput trait was dropped without replacement apparently (as
long as the low-level core API is not used)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This version uses const generics, which bumps our minimum supported
compiler version to 1.51.
|
|
Suggested by @joshtriplett at:
https://github.com/BLAKE3-team/BLAKE3/issues/168#issuecomment-829609667
|
|
|
|
|
|
These clutter the toplevel API, and their prominence might lead callers
to prefer them as a first resort, which probably isn't a good idea.
Restricting multithreading to `Hasher::update_rayon` feels better,
similar to what we've done with `Hasher::finalize_xof`. (But I think
`update_rayon` is still an improvement over the trait-based interface
that it replaced.)
|
|
This approach was suggested by @tarcieri at
https://github.com/BLAKE3-team/BLAKE3/pull/157.
|
