[GH-ISSUE #128] Use rust-crypto from crates.io #100

Closed
opened 2026-02-27 19:28:50 +03:00 by kerem · 10 comments
Owner

Originally created by @plietar on GitHub (Feb 8, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/128

We currently depend on a fork of rust-crypto which only exists on GitHub. The fork (https://github.com/awmath/rust-crypto.git, branch avx2) fixes the implementation of AES on some CPUs (see https://github.com/plietar/librespot/issues/155).

If we want to publish librespot-core to crates.io we need to only use dependencies that have themselves been published there.

The possible solutions are:

  1. Give up on supporting that kind of CPUs
  2. Get the fix into upstream rust-crypto and published (very unlikely)
  3. Publish our own version of rust-crypto with this patch
  4. Find an acceptable alternative AES implementation that works on all cpus and is published on crates.io (last time I checked there weren't any)
  5. Use the upstream crates.io, but specifying a [replace] (https://doc.rust-lang.org/cargo/reference/manifest.html#the-replace-section) to switch to the fork

I'm in favour of 5. Building librespot from crates.io (ie using it as a dependency in a 3rd party project) will get the upstream rust-crypto without the AVX fix, but building from a cloned repo (as it's done today) would have the fix.

3rd party projects that use librespot would be able to apply the same [replace] attribute in their Cargo.toml

Originally created by @plietar on GitHub (Feb 8, 2018). Original GitHub issue: https://github.com/librespot-org/librespot/issues/128 We currently depend on a fork of rust-crypto which only exists on GitHub. The fork (https://github.com/awmath/rust-crypto.git, branch `avx2`) fixes the implementation of AES on some CPUs (see https://github.com/plietar/librespot/issues/155). If we want to publish `librespot-core` to crates.io we need to only use dependencies that have themselves been published there. The possible solutions are: 1) Give up on supporting that kind of CPUs 2) Get the fix into upstream rust-crypto and published (very unlikely) 3) Publish our own version of rust-crypto with this patch 4) Find an acceptable alternative AES implementation that works on all cpus and is published on crates.io (last time I checked there weren't any) 5) Use the upstream crates.io, but specifying a [replace] (https://doc.rust-lang.org/cargo/reference/manifest.html#the-replace-section) to switch to the fork I'm in favour of 5. Building librespot from crates.io (ie using it as a dependency in a 3rd party project) will get the upstream rust-crypto without the AVX fix, but building from a cloned repo (as it's done today) would have the fix. 3rd party projects that use librespot would be able to apply the same [replace] attribute in their Cargo.toml
kerem closed this issue 2026-02-27 19:28:50 +03:00
Author
Owner

@sashahilton00 commented on GitHub (Feb 8, 2018):

I just requested that this be merged and published here: https://github.com/DaGenix/rust-crypto/pull/433, lets see what the response is. No point adding complexity if it can be merged to upstream.

<!-- gh-comment-id:363977081 --> @sashahilton00 commented on GitHub (Feb 8, 2018): I just requested that this be merged and published here: https://github.com/DaGenix/rust-crypto/pull/433, lets see what the response is. No point adding complexity if it can be merged to upstream.
Author
Owner

@plietar commented on GitHub (Feb 8, 2018):

Given that there haven't been any activity since September 2016 I've got pretty low hopes of this working, but it's always worth the try.

<!-- gh-comment-id:363980415 --> @plietar commented on GitHub (Feb 8, 2018): Given that there haven't been any activity since September 2016 I've got pretty low hopes of this working, but it's always worth the try.
Author
Owner

@sashahilton00 commented on GitHub (Feb 8, 2018):

Yup, just realised that after making the PR. Give it a couple of days, otherwise do whatever you think best.

<!-- gh-comment-id:363980556 --> @sashahilton00 commented on GitHub (Feb 8, 2018): Yup, just realised that after making the PR. Give it a couple of days, otherwise do whatever you think best.
Author
Owner

@newpavlov commented on GitHub (Feb 10, 2018):

Take a look at RustCrypto org which aims to be a successor of rust-crypto. It has aesni crate which implements AES (block cipher and CTR block mode) using inline assembly for AES-NI. Currently it requires nightly Rust, but with stabilization of SIMD it will work on stable. (currently I am rewriting it using stdsimd crate) But unfortunately we haven't yet ported bit-sliced implementation from rust-crypto. Can you please list crypto related algorithms which utilized in your crate?

<!-- gh-comment-id:364678106 --> @newpavlov commented on GitHub (Feb 10, 2018): Take a look at [RustCrypto](https://github.com/RustCrypto) org which aims to be a successor of `rust-crypto`. It has `aesni` crate which implements AES (block cipher and CTR block mode) using inline assembly for AES-NI. Currently it requires nightly Rust, but with [stabilization](https://github.com/rust-lang/rfcs/pull/2325) of SIMD it will work on stable. (currently I am rewriting it using `stdsimd` crate) But unfortunately we haven't yet ported bit-sliced implementation from `rust-crypto`. Can you please list crypto related algorithms which utilized in your crate?
Author
Owner

@plietar commented on GitHub (Feb 11, 2018):

librespot gets used on various architectures, including ARM (both v6 and v7) and MIPS.

As far as I can tell RustCrypto only supports a subset of intel CPUs, so it wouldn't work for us.

In terms of algorithms we rely on sha1, hmac-sha1, pbkdf2, AES-CTR and AES-ECB. The first 3 can be replaced by ring I believe, but it doesn't support the AES modes we need.

<!-- gh-comment-id:364709327 --> @plietar commented on GitHub (Feb 11, 2018): librespot gets used on various architectures, including ARM (both v6 and v7) and MIPS. As far as I can tell RustCrypto only supports a subset of intel CPUs, so it wouldn't work for us. In terms of algorithms we rely on sha1, hmac-sha1, pbkdf2, AES-CTR and AES-ECB. The first 3 can be replaced by ring I believe, but it doesn't support the AES modes we need.
Author
Owner

@newpavlov commented on GitHub (Feb 11, 2018):

No, only aesni relies on availability of AES-NI instruction set, all other crates are written in pure Rust, thus should work on other platforms (including big-endian ones) without any problems. See the following crates:

  • sha-1
  • hmac (it's a generic crate which after composition with sha-1 will give you HMAC-SHA1)
  • pbkdf2 (again it's an implementation generic over MAC, so you can use e.g. HMAC-SHA1)

I'll try to port bit-sliced implementation and publish it under aes crate in the following month.

<!-- gh-comment-id:364709657 --> @newpavlov commented on GitHub (Feb 11, 2018): No, only `aesni` relies on availability of AES-NI instruction set, all other crates are written in pure Rust, thus should work on other platforms (including big-endian ones) without any problems. See the following crates: - `sha-1` - `hmac` (it's a generic crate which after composition with `sha-1` will give you HMAC-SHA1) - `pbkdf2` (again it's an implementation generic over MAC, so you can use e.g. HMAC-SHA1) I'll try to port bit-sliced implementation and publish it under `aes` crate in the following month.
Author
Owner

@sashahilton00 commented on GitHub (Feb 12, 2018):

No activity for the PR on the original repo, I vote for Option 5. We could potentially switch to RustCrypto once necessary changes made upstream.

<!-- gh-comment-id:364805405 --> @sashahilton00 commented on GitHub (Feb 12, 2018): No activity for the PR on the original repo, I vote for Option 5. We could potentially switch to RustCrypto once necessary changes made upstream.
Author
Owner

@awiouy commented on GitHub (Feb 12, 2018):

As a transient solution, we could also use [patch] and platform specific dependencies, described here.
Patch requires Rust 1.21.0.

<!-- gh-comment-id:364908477 --> @awiouy commented on GitHub (Feb 12, 2018): As a transient solution, we could also use [patch] and platform specific dependencies, described [here](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html). Patch requires Rust 1.21.0.
Author
Owner

@sashahilton00 commented on GitHub (Feb 12, 2018):

#147 implements option 5 from the OP.

<!-- gh-comment-id:364916365 --> @sashahilton00 commented on GitHub (Feb 12, 2018): #147 implements option 5 from the OP.
Author
Owner

@plietar commented on GitHub (Feb 12, 2018):

Fixed by #147

<!-- gh-comment-id:364947417 --> @plietar commented on GitHub (Feb 12, 2018): Fixed by #147
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/librespot#100
No description provided.