chacha20: Replace salsa20-core with ctr-derived buffering#81
Merged
Conversation
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 ChaCha20 block function output as little endian bytes - implementing the `stream-cipher` APIs This commit gets rid of `salsa20-core` as a dependency (which is also making it difficult to do further SIMD optimizations), replacing it with code derived from the `ctr` crate, but specialized to the ChaCha20 use case.
tarcieri
force-pushed
the
chacha20/remove-salsa20-core
branch
from
January 15, 2020 23:38
1e1f36c to
c0740fe
Compare
Merged
tarcieri
added a commit
that referenced
this pull request
Jan 17, 2020
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.
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
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.
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:
stream-cipherAPIsThis commit gets rid of
salsa20-coreas a dependency (which is also making it difficult to do further SIMD optimizations), replacing it with code derived from thectrcrate, but specialized to the ChaCha20 use case. It also changes theBlock::generateAPI to write into a referenced slice as output, handling little endian serialization (which for the SSE2 backend is a noop), allowing the buffering code to work in terms of bytes rather thanu32arrays.This results in a ~40% performance improvement (bringing us from ~3.5cpb to ~2.4cpb):