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