Description
While I was developing the 64-bit counter variant, I had a suspicion that the NEON code used 64-bit addition with the counter and I wrote a test for it. The test I wrote passed with all backends, except for the NEON backend, resulting in a mismatch between the output of the first four blocks and the output of the first four blocks after the counter was supposed to wrap around.
This would not have affected the cipher implementations because they panic when it reaches the end of the keystream, but it does affect the rng.
This is not a vulnerability; however, it is still a bug, and it should probably be dealt with. It can probably be fixed by changing add64! to add32!, but when I was developing the 64-bit counter, I had to change the order of the operations when the counter was being applied to maintain the functionality of both counters. But it can probably be fixed by changing that macro if we only need the 32-bit counter.
This is the test that failed on NEON and passed on the other backends:
#[test]
fn counter_wrapping() {
let mut rng = ChaChaRng::from_seed([0u8; 32]);
// get first four blocks and word pos
let mut first_blocks = [0u8; 64 * 4];
rng.fill_bytes(&mut first_blocks);
let word_pos = rng.get_word_pos();
// get first four blocks after wrapping
rng.set_block_pos(u32::MAX);
let mut result = [0u8; 64 * 5];
rng.fill_bytes(&mut result);
assert_eq!(word_pos, rng.get_word_pos());
assert_eq!(&first_blocks[0..64 * 4], &result[64..]);
}
Activity