Repository navigation
Fix the ChaCha20 overflow check for start counter 0xffffffff - #299
Merged
utelle merged 2 commits intoNov 3, 2026
Merged
Conversation
chacha20_counter_wraps() assumed that the call starts at counter + 1. That holds for the page and VLE encryption, but chacha20_xor() passes the start counter of the call itself. For the start counter 0xffffffff (page counter 0xfffffffe) the check saw no overflow, so the accelerated code was used and carried the counter into the nonce. A page with this counter written by version 2.5 or earlier was still read incorrectly on x86 and ARM64. The function now takes the start counter of the call, and the two encrypting callers pass counter + 1. The counters chosen when encrypting do not change.
For lengths that use the accelerated code, chacha20_xor has to give the same result as sqleet for every start counter from just below the overflow up to 0xffffffff. Without the previous commit the test fails for the start counter 0xffffffff.
Owner
|
Thanks for detecting and fixing this glitch. |
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.
Follow-up to 77827fa. chacha20_counter_wraps() expects the page counter (the call starts at counter + 1), but chacha20_xor() passes the start counter of the call. For the start counter 0xffffffff, i.e. page counter 0xfffffffe, the check sees no overflow, and the accelerated code carries the counter into the first nonce word. Pages with this counter that version 2.5 or earlier wrote are then still read incorrectly with hardware acceleration.
The function now takes the start counter of the call, and the page and VLE encryption pass counter + 1. The counters chosen when encrypting stay the same (checked for all 2^32 values), and the check in chacha20_xor now flags exactly the start counters at which the counter overflows.
The second commit adds the case to cryptotest: for lengths of 1024 bytes and more, chacha20_xor has to match sqleet for every start counter from just below the overflow up to 0xffffffff. On the current main it fails for 0xffffffff.
Testing (macOS arm64 with NEON, x86_64 with SSSE3 under Rosetta):