You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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]fncounter_wrapping(){letmut rng = ChaChaRng::from_seed([0u8;32]);// get first four blocks and word posletmut 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);letmut 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..]);}
The text was updated successfully, but these errors were encountered:
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 therng
.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!
toadd32!
, 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:
The text was updated successfully, but these errors were encountered: