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

Closed
noloader opened this issue Jan 26, 2019 · 1 comment

Comments

Projects
None yet
1 participant
@noloader
Copy link
Collaborator

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

And:

  • 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):

032CC123482C31711F94C941AF5AB1F4155784332ED5348FE79AEC5EAD4C06C3
F13C280D8CC49925E4A6A5922EC80E13A4CDFA840C70A1427A3CB699166991A5
ACE4CD09E294D1912D4AD205D06F95D9C2F2BFCF453E8753F128765B62215F4D
92C74F2F626C6A640C0B1284D839EC81F1696281DAFC3E684593937023B58B1D
76B8E0ADA0F13D90405D6AE55386BD28BDD219B8A08DED1AA836EFCC8B770DC7  <== Difference
DA41597C5157488D7724E03FB8D84A376A43B8F41518A11CC387B669B2EE6586
9F07E7BE5551387A98BA977C732D080DCB0F29A048E3656912C6533E32EE7AED
29B721769CE64E43D57133B074D839D531ED1F28510AFB45ACE10A1F4B794D6F

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

032CC123482C31711F94C941AF5AB1F4155784332ED5348FE79AEC5EAD4C06C3
F13C280D8CC49925E4A6A5922EC80E13A4CDFA840C70A1427A3CB699166991A5
ACE4CD09E294D1912D4AD205D06F95D9C2F2BFCF453E8753F128765B62215F4D
92C74F2F626C6A640C0B1284D839EC81F1696281DAFC3E684593937023B58B1D
3DB41D3AA0D329285DE6F225E6E24BD59C9A17006943D5C9B680E3873BDC683A  <== Difference
5819469899989690C281CD17C96159AF0682B5B903468A61F50228CF09622B5A
46F0F6EFEE15C8F1B198CB49D92B990867905159440CC723916DC00128269810
39CE1766AA2542B05DB3BD809AB142489D5DBFE1273E7399637B4B3213768AAA

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.
@noloader

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.