salsa20: replace salsa20-core with ctr-derived buffering; MSRV 1.34+#94
Merged
Conversation
This is pretty much the same PR as #81 was for `chacha20`. The previously used buffering logic in the `salsa20-core` crate is complex, hard-to-audit, and slow: https://github.com/RustCrypto/stream-ciphers/blob/6be62af/salsa20-core/src/lib.rs#L93 The main reason is because it tries to handle too many things at once, namely: - serializing the Salsa20 block function output as little endian bytes - implementing the stream-cipher APIs This commit gets rid of `salsa20-core` as a dependency, replacing it with code derived from the `ctr` crate, but specialized to the Salsa20 use case. Ideally this code could eventually be unified with the extremely similar code in the `ctr` crate and `chacha20` crates, as much of it seems reusable. For now though, I think it's probably better to keep the code in `chacha20` separate from this code: the previous API was a major impediment in SIMD optimizations, and being able to refactor both the buffering logic and the various block function implementations internally to a single crate is much easier than having to touch (and release) 3 different crates for such a change. This crate doesn't have a SIMD backend, and there's no plans to add one, so using the simplest buffering logic possible probably makes sense. As this was the last crate with a code dependency on `salsa20-core`, this commit also removes it, as it's no longer needed.
Merged
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
This is pretty much the same PR as #81 was for
chacha20.The previously used buffering logic in the
salsa20-corecrate is complex, hard-to-audit, and slow:https://github.com/RustCrypto/stream-ciphers/blob/6be62af/salsa20-core/src/lib.rs#L93
The main reason is because it tries to handle too many things at once, namely:
This commit gets rid of
salsa20-coreas a dependency, replacing it with code derived from thectrcrate, but specialized to the Salsa20 use case.Ideally this code could eventually be unified with the extremely similar code in the
ctrcrate andchacha20crates, as much of it seems reusable.For now though, I think it's probably better to keep the code in
chacha20separate from this code: the previous API was a major impediment in SIMD optimizations, and being able to refactor both thebuffering logic and the various block function implementations internally to a single crate is much easier than having to touch (and release) 3 different crates for such a change.
This crate doesn't have a SIMD backend, and there's no plans to add one, so using the simplest buffering logic possible probably makes sense.
As this was the last crate with a code dependency on
salsa20-core, this commit also removes it, as it's no longer needed.