Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ChaCha20: Fix stream-length overflow check #216

Merged
merged 6 commits into from
Jan 6, 2021

Conversation

jpdoyle
Copy link
Contributor

@jpdoyle jpdoyle commented Jan 6, 2021

It seems that the stream-length-overflow check has been through a few iterations, and at some point along the way it developed troublesome edge-case behavior. This adds 7 unit tests to exercise the behavior, a confusing subset of which (1,2,3,6,7) fail on the current upstream branch. it also adds a simplified stream-length-overflow check and enforces stream-position checking in try_seek(). Those changes make all the new tests pass.

Based on a quick glance through the history, I'm not sure when this problem appeared. It doesn't seem easy to exploit unless you're very deliberately extracting more keystream than you should be allowed to, but it definitely needs a fix.

Tests 1, 2, 3, 6, and 7 fail. I suspect they behave differently with the
`avx2` backend since it depends on where the boundary of the buffer is.
I don't think it's easy to exploit this unless you're trying really
hard. That said, I believe it's possible for sufficiently determined
user code to bypass the MAX_BLOCKS check and generate looped/overflowed
keystream past 256GB.
@jpdoyle jpdoyle changed the title Fix overflow check ChaCha20: Fix stream-length overflow check Jan 6, 2021
@jpdoyle
Copy link
Contributor Author

jpdoyle commented Jan 6, 2021

One sec, forgot I was running nightly...

@jpdoyle
Copy link
Contributor Author

jpdoyle commented Jan 6, 2021

@tarcieri not sure if you're the right person to tag but this could use review

@tarcieri
Copy link
Member

tarcieri commented Jan 6, 2021

Great, thank you!

This part of the code has been problematic in part because it's duplicated between ctr, chacha20, and salsa20, however I've been meaning to do a pass to update it to the new block-buffer API which should hopefully make it much simpler.

The added tests should hopefully ensure it does not regress.

@tarcieri tarcieri merged commit 131cd4b into RustCrypto:master Jan 6, 2021
jpdoyle added a commit to jpdoyle/stream-ciphers that referenced this pull request Jan 8, 2021
@tarcieri tarcieri mentioned this pull request Apr 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants