mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #128] Use rust-crypto from crates.io #100
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#100
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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-coreto crates.io we need to only use dependencies that have themselves been published there.The possible solutions are:
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
@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.
@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.
@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.
@newpavlov commented on GitHub (Feb 10, 2018):
Take a look at RustCrypto org which aims to be a successor of
rust-crypto. It hasaesnicrate 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 usingstdsimdcrate) But unfortunately we haven't yet ported bit-sliced implementation fromrust-crypto. Can you please list crypto related algorithms which utilized in your crate?@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.
@newpavlov commented on GitHub (Feb 11, 2018):
No, only
aesnirelies 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-1hmac(it's a generic crate which after composition withsha-1will 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
aescrate in the following month.@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.
@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.
@sashahilton00 commented on GitHub (Feb 12, 2018):
#147 implements option 5 from the OP.
@plietar commented on GitHub (Feb 12, 2018):
Fixed by #147