Skip to content

Conversation

pull[bot]
Copy link

@pull pull bot commented Nov 6, 2019

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

@pull pull bot added the ⤵️ pull label Nov 6, 2019
@pull pull bot added the merge-conflict Resolve conflicts manually label Feb 19, 2020
newpavlov and others added 30 commits March 24, 2025 05:56
Additionally, move some common code to the `utils` modules.
The flag is passed automatically by docs.rs.
The new backend results in a much smaller binary code (e.g. for SHA-256
on `thumbv7em-none-eabi` we get [~150 instructions][0] vs [~1680
instructions][1], for SHA-512 it's [~330][2] vs [~7950][3]) while being
somewhat slower on non-embedded CPUs (e.g. for SHA-256 on my x86-64
laptop with `opt-level=s` it results in 289 MB/s vs 315 MB/s).

[0]: https://rust.godbolt.org/z/c5cT5chGz
[1]: https://rust.godbolt.org/z/rWMTqaxdc
[2]: https://rust.godbolt.org/z/EKoxxdqrv
[3]: https://rust.godbolt.org/z/Td81PxsdW
This change makes it easier to read the software backend code and makes
it similar to the `soft-compact` backend. It also slightly improves
codegen (e.g. on x86-64 for SHA-256 it results in [~3330][0] vs
[~3490][1] instructions).

[0]: https://rust.godbolt.org/z/xsees1r7r
[1]: https://rust.godbolt.org/z/5q19WYW14
This PR implements `CollisionResistance` for all XOFs. I started with
those to add support for `ExpandMsgXof` in `elliptic-curve` and will do
follow-up PRs for at least SHA2 and SHA3 fixed output hashes.

Companion PR: RustCrypto/traits#1862.

See RustCrypto/traits#1816 for previous
discussions.
Also includes new `rc.0` prereleases of crates we've previously done
prereleases for (i.e. that are deps elsewhere in the project)
When pulling dependencies using a `patch.crates-io` to a git dependency
like:
```
[dependencies]
sha1 = "0.11.0-rc.0"

[patch.crates-io]
sha1-checked = { git = "https://github.com/RustCrypto/hashes.git" }
```

Cargo will duplicate sha1 dependency:
```
[[package]]
name = "sha1"
version = "0.11.0-rc.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "6f9318facddf9ac32a33527066936837e189b3f23ced6edc1603720ead5e2b3d"
dependencies = [
 "cfg-if",
 "cpufeatures",
 "digest 0.11.0-rc.0",
]

[[package]]
name = "sha1"
version = "0.11.0-rc.0"
source = "git+https://github.com/RustCrypto/hashes.git#2bcfb5a0a849503ed73b190538787a00c58baada"
dependencies = [
 "cfg-if",
 "cpufeatures",
 "digest 0.11.0-rc.0",
]

[[package]]
name = "sha1-checked"
version = "0.11.0-pre"
source = "git+https://github.com/RustCrypto/hashes.git#2bcfb5a0a849503ed73b190538787a00c58baada"
dependencies = [
 "digest 0.11.0-rc.0",
 "sha1 0.11.0-rc.0 (git+https://github.com/RustCrypto/hashes.git)",
 "zeroize",
]
```

This causes issues further down the line, for example when the
downstream client is built with nix which does not support two copies of
the same crate/version tuple.

This switches the local overrides using a workspace patch instead which
are not used when the crate is consumed via git.
Moved to the actions repository in RustCrypto/actions#46
The implementation uses the GM/T OID. SM3 also has an alternative ISO
OID assigned to it (and IIRC several others), but we have to select one.
If necessary, in future we may introduce different wrappers (e.g. `Sm3Iso`).
Reasons:
 * BLAKE3 has been out for 5 years now.
* No further cryptanalytic results have come out indicating that it
might not be secure (nor for BLAKE2, nor BLAKE, nor ChaCha20, nor
Salsa20).
* BLAKE3 has a major, qualitative efficiency improvement, which is the
Merkle Tree structure, allowing (but not requiring) any amount of
parallelism.
* BLAKE3 is already extensively adopted in many different projects in
many different industries/areas/niches.
* BLAKE3 is currently being more actively maintained, as in patches are
being accepted by the chief maintainer, Jack "@oconnor663" O'Connor.
https://github.com/BLAKE3-team/BLAKE3/commits/master/
The tag effectively duplicates the cryptography category which we use
for all our crates. Per discussion in #717 we decided that we should not
have such duplication.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⤵️ pull merge-conflict Resolve conflicts manually
Projects
None yet
Development

Successfully merging this pull request may close these issues.