I was pointed to https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305-01. This draft specifies chacha as using a 96-bit nonce and a 32-bit block counter. When asking about this discrepancy on the tls list, Adam Langley replied
: On Fri, Feb 14, 2014 at 1:57 PM, Niels Möller nisse@lysator.liu.se wrote: : > [...] And a 32-bit counter (256 GB message size, if I manage to get : > the powers right) ought to be sufficient for almost all applications. : > But I'm afraid it might to slow adoption of chacha if there are : > multiple slightly incompatible specifications. : : I intend for the 64/64 bit version to be dead at this point. I think : everyone can agree on the 96/32 split. I wouldn't want there to be two : versions if it can be avoided.
Apparently, IPSec wants 96 bits nonces, and this is also in line with rfc5116, which says that all AEAD algorithms SHOULD support 12-byte nonces.
But this change is news to me. Do everyone really agree on the change of 96/32 in chacha?
My interpretation is that this move is advocated by people are thinking of various packetized protocols, where 32-bit block counter clearly will be sufficient to encrypt each packet. And that's clearly the most important applications of chacha will be of that type. But maybe there are other applications where a limit of 256 GB for a single message to be encrypted with chacha could be a problem?
There is some possibilty to let the two views of these input block coexist, but I'm afraid that will get a bit messy to support in Nettle (although I haven't yet thought very much about the details).
Anyway, this makes me feel that support for chacha and chacha-poly1305 must be marked as experimental, until the specifications really settle.
Regards, /Niels
On 02/15/2014 08:28 AM, Niels Möller wrote:
I was pointed to https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305-01. This draft specifies chacha as using a 96-bit nonce and a 32-bit block counter. When asking about this discrepancy on the tls list, Adam Langley replied : On Fri, Feb 14, 2014 at 1:57 PM, Niels Möller nisse@lysator.liu.se wrote: : > [...] And a 32-bit counter (256 GB message size, if I manage to get : > the powers right) ought to be sufficient for almost all applications. : > But I'm afraid it might to slow adoption of chacha if there are : > multiple slightly incompatible specifications. : I intend for the 64/64 bit version to be dead at this point. I think : everyone can agree on the 96/32 split. I wouldn't want there to be two : versions if it can be avoided. Apparently, IPSec wants 96 bits nonces, and this is also in line with rfc5116, which says that all AEAD algorithms SHOULD support 12-byte nonces. But this change is news to me. Do everyone really agree on the change of 96/32 in chacha?
In the TLS version of chacha we are going to propose is whather the cfrg draft says. So that would be 96/32.
regards, Nikos
"NM" == Niels Möller nisse@lysator.liu.se writes:
NM> But this change is news to me. Do everyone really agree NM> on the change of 96/32 in chacha?
Openssh's implementation uses DJB's 64/64 split.
If any nettle-using ssh app wants to interact, it will need 64/64.
-JimC -- James Cloos cloos@jhcloos.com OpenPGP: 1024D/ED7DAEA6
nisse@lysator.liu.se (Niels Möller) writes:
There is some possibilty to let the two views of these input block coexist, but I'm afraid that will get a bit messy to support in Nettle (although I haven't yet thought very much about the details).
This is all about initialization and update of words 12-15 (last row) of the chacha state. Either
12 13 14 15 c0 c1 n0 n1 (64-bit counter, 64 bit nonce)
or
12 13 14 15 c n0 n1 n2 (32-bit counter, 96 bit nonce)
When using a 64-bit counter, c0 is the least significant half, and c1 is the most significant half. Say we adopt the second layout (and notation). Then letting the counter c overflow is an error which should never happen when using the 32/96 variant. So we can make the compatible extension to increment the n0 word whenever c wraps around (this will break if for some reason someone wants to use 32/96 chacha with an unusually large initial counter, though).
With this tweak, one can get 64/64 chacha by simply prepending 32 zero bits to the 64-bit nonce, and use the 32/96 chacha.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
James Cloos -
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se