[pull] master from RustCrypto:master #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Wasn't respecting the pinned MSRV, causing an error on #240 since a new lint was introduced.
Bumps [libc](https://github.com/rust-lang/libc) from 0.2.86 to 0.2.88. - [Release notes](https://github.com/rust-lang/libc/releases) - [Commits](rust-lang/libc@0.2.86...0.2.88) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Expands the test suite to be similar to the one used by the `sha2` crate which tests the following platforms: - Linux: i686/x86_64/aarch64 (latter w\ cross) - Windows: x86_64 - macOS: x86_64 Additionally tests the `asm` feature on all Linux platforms as well as on macOS. Tests on i686 and cross-based tests for aarch64 are currently disabled because the `asm` feature is failing. See RustCrypto/hashes#251
Bumps [byteorder](https://github.com/BurntSushi/byteorder) from 1.4.2 to 1.4.3. - [Release notes](https://github.com/BurntSushi/byteorder/releases) - [Changelog](https://github.com/BurntSushi/byteorder/blob/master/CHANGELOG.md) - [Commits](BurntSushi/byteorder@1.4.2...1.4.3) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [libc](https://github.com/rust-lang/libc) from 0.2.88 to 0.2.93. - [Release notes](https://github.com/rust-lang/libc/releases) - [Commits](rust-lang/libc@0.2.88...0.2.93) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
This release includes support for Apple M1 CPUs: RustCrypto/asm-hashes#35
Renamed in this PR: RustCrypto/utils#381
Adds docs, tests all features in CI, and adds doc_cfg setup for docs.rs.
Uses the newly added `aarch64` support in the `cpufeatures` crate for `sha1` CPU feature detection on Linux and macOS/M1.
The latest nightly seems to be broken: https://github.com/RustCrypto/hashes/pull/274/checks?check_run_id=2581387409
Bumps [cpufeatures](https://github.com/RustCrypto/utils) from 0.1.1 to 0.1.3. - [Release notes](https://github.com/RustCrypto/utils/releases) - [Commits](RustCrypto/utils@cpufeatures-v0.1.1...cpufeatures-v0.1.3) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
`cpufeatures` v0.1.4 can build on any `aarch64` target, not just Linux/macOS ones: RustCrypto/utils#40 This PR bumps the minimum `cpufeatures` requirement to v0.1.4 and removes the OS-specifisms on `aarch64` targets.
According to https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions, it's 8 x 32 bits for sha256 and 8 x 64 bits for sha512. Reading just `the 32-bit 'Sha256'` is confusing to me. But YMMV...
Bumps [cpufeatures](https://github.com/RustCrypto/utils) from 0.1.4 to 0.1.5. - [Release notes](https://github.com/RustCrypto/utils/releases) - [Commits](RustCrypto/utils@cpufeatures-v0.1.4...cpufeatures-v0.1.5) --- updated-dependencies: - dependency-name: cpufeatures dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
We were previously using inline assembly to "emulate" these intrinsics since the ones in `core::arch` had not yet been stabilized. They are now stable as of Rust 1.79. Redux of #570.
Currently AsconXofReader has type XofReaderCoreWrapper<AsconAXofReaderCore>, this is incorrect the type should be XofReaderCoreWrapper<AsconXofReaderCore>.
The support is Nightly-only and requires to enable the `sha2_backend` configuration flag with a value equal to `riscv-zknh` or `riscv-zknh-compact`. The resulting assembly and binary size of the `compress` function (not counting the `K32` and `K64` statics): - SHA-256, unrolled: https://rust.godbolt.org/z/177bqKd3h (5280 bytes) - SHA-256, compact: https://rust.godbolt.org/z/Kzx59bsdP (1308 bytes) - SHA-512, unrolled: https://rust.godbolt.org/z/ExqqrfE1r (7964 bytes) - SHA-512: compact: https://rust.godbolt.org/z/z41v6d4do (2852 bytes)
To force use of the software backend users now have to use `RUSTFLAGS='--cfg sha2_backend="soft"'`.
Annoyingly, RISC-V is really inconvenient when we have to deal with misaligned loads/stores. LLVM by default generates very [inefficient code](https://rust.godbolt.org/z/3Yaj4fq5o) which loads every byte separately and combines them into a 32/64 bit integer. The `ld` instruction "may" support misaligned loads and for Linux user-space it's even [guaranteed](https://www.kernel.org/doc/html/v6.10/arch/riscv/uabi.html#misaligned-accesses), but it can be (and IIUC often in practice is) "extremely slow", so we should not rely on it while writing performant code. After asking around, it looks like this mess is here to stay, so we have no choice but to work around it. To do that this PR introduces two separate paths for loading block data: aligned and misaligned. The aligned path should be the most common one. In the misaligned path we have to rely on inline assembly since we have to load some bits outside of the block. Additionally, this PR makes inlining in the `riscv-zknh` backend less aggressive, which makes generated binary code 3-4 times smaller at the cost of one additional branch. Generated assembly for RV64: - SHA-256, unrolled: https://rust.godbolt.org/z/GxPM8PE3P (2278 bytes) - SHA-256, compact: https://rust.godbolt.org/z/4KWrcve9E (538 bytes) - SHA-512, unrolled: https://rust.godbolt.org/z/Th8ro8Tbo (2278 bytes) - SHA-512: compact: https://rust.godbolt.org/z/dqrv48ax3 (530 bytes)
New Ubuntu images are being deployed, which is causing the cached binaries not to work due to a GLIBC upgrade: https://github.blog/changelog/2024-09-25-actions-new-images-and-ubuntu-latest-changes/ To ensure we're caching consistently on the new image, switches from using `ubuntu-latest` to `ubuntu-24.04`. We can revert this change after October 30th, when the blog post says the deployment is complete.
This PR ports the AVX implementation of SHA-512 to simd128. It also implements the related version of SHA-256 from https://github.com/aws-samples/sha2-with-c-intrinsic/blob/master/src/sha256_compress_x86_64_avx.c in simd128. Also added wasm32 testing in CI using wasmtime. Since wasm does not have feature detection, this backend is only used if the `-C target-feature=+simd128` flag is set. Benchmarks on AMD Ryzen 9 7950X3D, running with wasmtime 26.0.0 (c92317bcc 2024-10-22) on rustc 1.84.0-nightly (b3f75cc87 2024-11-02): ``` + RUSTFLAGS='-C target-feature=+simd128' + cargo +nightly bench -q --bench mod --target wasm32-wasip1 running 8 tests test sha256_10 ... bench: 18.71 ns/iter (+/- 1.62) = 555 MB/s test sha256_100 ... bench: 167.94 ns/iter (+/- 0.62) = 598 MB/s test sha256_1000 ... bench: 1,656.93 ns/iter (+/- 142.75) = 603 MB/s test sha256_10000 ... bench: 15,601.30 ns/iter (+/- 1,268.65) = 640 MB/s test sha512_10 ... bench: 14.35 ns/iter (+/- 0.09) = 714 MB/s test sha512_100 ... bench: 137.37 ns/iter (+/- 0.87) = 729 MB/s test sha512_1000 ... bench: 1,261.63 ns/iter (+/- 105.65) = 793 MB/s test sha512_10000 ... bench: 12,434.24 ns/iter (+/- 24.46) = 804 MB/s test result: ok. 0 passed; 0 failed; 0 ignored; 8 measured; 0 filtered out; finished in 4.40s + RUSTFLAGS='-C target-feature=-simd128' + cargo +nightly bench -q --bench mod --target wasm32-wasip1 running 8 tests test sha256_10 ... bench: 155.59 ns/iter (+/- 1.08) = 64 MB/s test sha256_100 ... bench: 1,539.48 ns/iter (+/- 9.18) = 64 MB/s test sha256_1000 ... bench: 15,207.34 ns/iter (+/- 81.67) = 65 MB/s test sha256_10000 ... bench: 151,547.98 ns/iter (+/- 1,170.30) = 65 MB/s test sha512_10 ... bench: 98.59 ns/iter (+/- 0.45) = 102 MB/s test sha512_100 ... bench: 980.99 ns/iter (+/- 3.43) = 102 MB/s test sha512_1000 ... bench: 9,622.94 ns/iter (+/- 29.97) = 103 MB/s test sha512_10000 ... bench: 95,977.25 ns/iter (+/- 310.30) = 104 MB/s test result: ok. 0 passed; 0 failed; 0 ignored; 8 measured; 0 filtered out; finished in 6.55s + RUSTFLAGS='--cfg sha2_backend="soft" -C target-feature=+simd128' + cargo +nightly bench -q --bench mod --target wasm32-wasip1 running 8 tests test sha256_10 ... bench: 142.07 ns/iter (+/- 13.71) = 70 MB/s test sha256_100 ... bench: 1,404.58 ns/iter (+/- 10.83) = 71 MB/s test sha256_1000 ... bench: 14,823.81 ns/iter (+/- 1,346.05) = 67 MB/s test sha256_10000 ... bench: 139,001.94 ns/iter (+/- 978.58) = 71 MB/s test sha512_10 ... bench: 90.39 ns/iter (+/- 7.82) = 111 MB/s test sha512_100 ... bench: 893.20 ns/iter (+/- 72.22) = 111 MB/s test sha512_1000 ... bench: 8,812.46 ns/iter (+/- 878.60) = 113 MB/s test sha512_10000 ... bench: 87,887.02 ns/iter (+/- 394.70) = 113 MB/s test result: ok. 0 passed; 0 failed; 0 ignored; 8 measured; 0 filtered out; finished in 8.62s ```
This introduces unkeyed hashing for blake2 as specified in [Section 2.5 of RFC 7693](https://www.rfc-editor.org/rfc/rfc7693.html#section-2.5) states the following: The second (little-endian) byte of the parameter block, "kk", specifies the key size in bytes. Set kk = 00 for unkeyed hashing. I propose to make the key an `Option<&[u8]>`: ```rust pub fn new_with_salt_and_personal( key: Option<&[u8]>, salt: &[u8], persona: &[u8], ) -> Result<Self, InvalidLength> ``` By making the key an `Option<&[u8]>` - rather than opting for the unkeyed usage in case of an empty `key` - we make the unkeyed usage explicit and avoid inadvertent usages. This closes #482. See also #509.
Explicit that cSHAKE is supported in the README.
Use the new function `new_customized` from RustCrypto/traits#1334 in CSHAKE tests
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )