Changes since 0.3.6:
- BUGFIX: The C implementation was incorrect on big endian systems for
inputs longer than 1024 bytes. This bug affected all previous versions
of the C implementation. Little endian platforms like x86 were
unaffected. The Rust implementation was also unaffected.
@jakub-zwolakowski and @pascal-cuoq from TrustInSoft reported this
bug: https://github.com/BLAKE3-team/BLAKE3/pull/118
- BUGFIX: The C build on x86-64 was producing binaries with an
executable stack. @tristanheaven reported this bug:
https://github.com/BLAKE3-team/BLAKE3/issues/109
- @mkrupcale added optimized implementations for SSE2. This improves
performance on older x86 processors that don't support SSE4.1.
- The C implementation now exposes the
`blake3_hasher_init_derive_key_raw` function, to make it easier to
implement language bindings. Added by @k0001.
Changes since 0.3.4:
- The `digest` dependency is now v0.9 and the `crypto-mac` dependency is
now v0.8.
- Intel CET is supported in the assembly implementations.
- `b3sum` error output includes filepaths again.
Changes since 0.3.3:
- `b3sum` now supports the `--check` flag. This is intended to be a
drop-in replacement for e.g. `md5sum --check` from Coreutils. The
behavior is somewhat stricter than Coreutils with respect to invalid
Unicode in filenames. For a complete description of how `--check`
works, see the file `b3sum/what_does_check_do.md`.
- To support the `--check` feature, backslashes and newlines that appear
in filenames are now escaped in the output of `b3sum`. This is done
the same way as in Coreutils.
- To support `--check` interoperability between Unix and Windows,
backslashes in filepaths on Windows are now replaced with forward
slashes in the output of `b3sum`. Note that this is different from
Coreutils.
Changes since 0.3.0:
- The x86 build now automatically falls back to "pure" Rust intrinsics,
under either of two possible conditions:
1. The `cc` crate fails to invoke a C compiler at all, indicating that
nothing of the right name (e.g. "cc" or "$CC" on Unix) is installed.
2. The `cc` crate detects that the compiler doesn't support AVX-512
flags, usually because it's too old.
The end result should be that most callers successfully build the
assembly implementations, and that callers who can't build those see a
warning but not an error. (And note that Cargo suppresses warnings for
non-path depencies.)
Changes since version 0.2.3:
- The optimized assembly implementations are now built by default. They
perform better than the intrinsics implementations, and they compile
much more quickly. Bringing the default behavior in line with reported
benchmark figures should also simplify things for people running their
own benchmarks. Previously this crate only built Rust intrinsics
implementations by default, and the assembly implementations were
gated by the (slightly confusingly named) "c" feature. Now the "c"
feature is gone, and applications that need the old behavior can use
the new "pure" feature. Mainly this will be applications that don't
want to require a C compiler. Note that the `b3sum` crate previously
activated the "c" feature by default, so its behavior hasn't changed.
The biggest change here is that assembly implementations are enabled by
default.
Added features:
- "pure" (Pure Rust, with no C or assembly implementations.)
Removed features:
- "c" (Now basically the default.)
Renamed features;
- "c_prefer_intrinsics" -> "prefer_intrinsics"
- "c_neon" -> "neon"
Unchanged:
- "rayon"
- "std" (Still the only feature on by default.)
Changes since version 0.2.2:
- Bug fix: Commit 13556be fixes a crash on Windows when using the SSE4.1
assembly implementation (--features=c, set by default for b3sum). This
is undefined behavior and therefore a potential security issue.
- b3sum now supports the --num-threads flag.
- The C API now includes a blake3_hasher_finalize_seek() function, which
returns output from any position in the extended output stream.
- Build fix: Commit 5fad419 fixes a compiler error in the AVX-512 C
intrinsics implementation targeting the Windows GNU ABI.
As part of this change, make the rayon and memmap dependencies
mandatory. This simplifies the code a lot, and I'm not aware of any
callers who build b3sum without the default dependencies.
If --num-threads is not given, or if its value is 0, b3sum will still
respect the RAYON_NUM_THREADS environment variable.
Changes since 0.2.1 (and since c-0.2.0):
- Fix a performance issue when the caller makes multiple calls to
update() with uneven lengths. (#69, reported by @willbryant.)
Changes since 0.1.5:
- The `c_avx512` feature has been replaced by the `c` feature. In
addition to providing AVX-512 support, `c` also provides optimized
assembly implementations. These assembly implementations perform
better, perform more consistently across compilers, and compile more
quickly. As before, `c` is off by default, but the `b3sum` binary
crate activates it by default.
- The `rayon` feature no longer affects the entire API. Instead, it
provides the `join::RayonJoin` type for use with
`Hasher::update_with_join`, so that the caller can control when
multi-threading happens. Standalone API functions like `hash` are
always single-threaded now.
Changes since 0.1.3:
- Hasher supports the reset() method.
- Hasher implements several traits from the `digest` and `crypto_mac`
crates.
- Bug fixes in the C implementation for MSVC and for 32-bit x86.
Changes since 0.1.2:
- All x86 implementations include _mm_prefetch optimizations. These
improve performance for very large inputs.
- The C implementation performs parallel parent hashing, matching the
performance of the single-threaded Rust implementation.
- b3sum supports --no-mmap. Contributed by @cesarb.
Changes since 0.1.1:
- b3sum no longer mmaps files smaller than 16 KiB. This improves
performance for hashing many small files. Contributed by @xzfc.
- b3sum now supports --raw output. Contributed by @phayes.
Changes since 0.1.0:
- Optimizations contributed by @cesarb.
- Fix the build on x86_64-pc-windows-gnu when c_avx512 is enabled.
- Add an explicit error message for compilers that don't support c_avx512.
If AVX-512 is enabled, and the local C compiler doesn't support it, the
build is going to fail. However, if we check for this explicitly, we can
give a better error message.
Fixes https://github.com/BLAKE3-team/BLAKE3/issues/6.
Putting secret keys on the command line is bad practice, because command
line args are usually globally visible within the OS. Even if these
flags are mostly intended for testing and experimentation, we might as
well do the right thing. Plus this saves people the trouble of hex
encoding their keys.
Jack O'Connor
Jack O'Connor