Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/chacha20.yml
Original file line number Diff line number Diff line change
Expand Up @@ -211,4 +211,4 @@ jobs:
toolchain: ${{ matrix.rust }}
targets: ${{ matrix.target }}
- uses: RustCrypto/actions/cross-install@master
- run: RUSTFLAGS="${{ matrix.rustflags }}" cross test --package chacha20 --target ${{ matrix.target }}
- run: RUSTFLAGS="${{ matrix.rustflags }}" cross test --package chacha20 --target ${{ matrix.target }} --all-features
6 changes: 5 additions & 1 deletion chacha20/src/rng.rs
Original file line number Diff line number Diff line change
Expand Up @@ -362,6 +362,10 @@ macro_rules! impl_chacha_rng {
#[inline]
fn generate(&mut self, r: &mut Self::Results) {
self.0.generate(&mut r.0);
#[cfg(target_endian = "big")]
for word in r.0.iter_mut() {
*word = word.to_le();
}
Comment on lines +365 to +368
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is wrong: there is no type change here (u32 to u32) so there should be no endian-switch.

We also don't do this in rand_chacha.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dug through rand_chacha and ppv-lite86 for a few minutes and couldn't find anywhere with endian conversions regarding the output. But multiple tests fail on big endian. If you look closely, you can see that the bytes within the words are in reverse order. I don't know why they are in reverse order, but the tests pass as soon as to_le() is called on all of the words.

https://github.com/RustCrypto/stream-ciphers/actions/runs/17169966574/job/48717538576

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might have found the problem. Line 48 of soft.rs converts each word to little endian. Big endian code will most likely be hitting the soft.rs backend. Even if this isn't the culprit, then this part of the code should be using conditional compilation. Will change the code and run a test right quick

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep... that was it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm pretty sure the backends shouldn't be doing any endian conversions.

}
}

Expand Down Expand Up @@ -1066,7 +1070,7 @@ pub(crate) mod tests {
tester_array = [0u8; LEN];
dest_pos = 0;

// test fill_bytes with lengths starting at N bytes, decreasing by 1,
// test fill_bytes with lengths starting at `N` bytes, decreasing by 1,
// down to 1 byte
for test_len in 1..=N {
let debug_start_word_pos = rng.get_word_pos();
Expand Down