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

ChaChaTLS results when counter block wraps #790

noloader opened this issue Jan 26, 2019 · 1 comment


None yet
1 participant
Copy link

commented Jan 26, 2019

ChaCha and the IETF's ChaChaTLS are slightly different implementations. Each uses the ChaCha state variables slightly differently, which leads to two slightly different implementations. Two of the differences are:

  • ChaCha uses two 32-bit words for a block counter
  • ChaCha uses two 32-bit words for a nonce
  • ChaChaTLS uses one 32-bit word for a block counter
  • ChaChaTLS uses three 32-bit words for a nonce


  • ChaCha does not wrap because the counter always starts at 0 and 64-bits is large enough for inputs
  • ChaChaTLS does wrap because the counter can be an arbitrary value, like 0xfffffffe, that wraps the 32-bit word almost immediately

Crypto++, Botan and libsodium are arriving at different results for ChaChaTLS for the following test case, which verifies behavior around the wrap condition:

  • Key - All 0's
  • IV - All 0's
  • Initial Block Counter - 0xfffffffe

Crypto++ arrives at the following keystream (see chacha_tls.txt):

76B8E0ADA0F13D90405D6AE55386BD28BDD219B8A08DED1AA836EFCC8B770DC7  <== Difference

Botan and libsodium arrive at the following keystream (see Botan chacha.vec):

3DB41D3AA0D329285DE6F225E6E24BD59C9A17006943D5C9B680E3873BDC683A  <== Difference

The problem everyone is having is, RFC 7539 does not say what should happen. Crypto++ wraps the counter block (state[12]) back to 0. Botan and libsodium wrap the counter block (state[12]) back to 0 and increment the first word of the nonce (state[13]).

We can't find authority to increment the nonce, and it feels like a wild memory write because it is a different object (message nonce vs block counter).

This bug report merely documents the problem. We need the RFC to say what we should do.

Also see How to handle block counter wrap in IETF's ChaCha algorithm? on the CFRG mailing list.

noloader added a commit that referenced this issue Feb 11, 2019

Back-off ChaCha assert at the moment (GH #790)
We don't know what we are supposed to do at the moment. We need the CFRG or IETF to say what is supposed to happen.

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 23, 2019

Let's close this out for the moment. We can revisit it if someone tells us what to do.

@noloader noloader closed this Feb 23, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.