EVP_chacha20 does not match RFC 7539 or documentation in nonce/counter split

[davidben]

RFC 7539 specified ChaCha20 with a 96-bit nonce and a 32-bit counter. Only 32 bits of the input is incremented across each block.
https://www.rfc-editor.org/rfc/rfc7539.html#section-2.4

The original paper didn't specify a split but, prior to the RFC, 64-bit nonce with 64-bit counter was also common. A 96/32 and 64/64 split are very similar primitives, but not quite the same. OpenSSL's documentation says it implements the RFC formulation:

The ChaCha20 stream cipher. The key length is 256 bits, the IV is 128 bits long. The first 32 bits consists of a counter in little-endian order followed by a 96 bit nonce.

https://www.openssl.org/docs/manmaster/man3/EVP_chacha20.html

However, the implementation doesn't match this and uses a 64-bit counter.

openssl/crypto/evp/e_chacha20_poly1305.c

Lines 112 to 113 in b134300

	key->counter[0] = ctr32;
	if (ctr32 == 0) key->counter[1]++;

See also C2SP/wycheproof#90

[t8m]

I assume we should just document the current implementation. A new feature would be to add a parameter to change to the 32/96 bit split implementation.

[bernd-edlinger]

But this does not really affect ChaCha20_Poly1305, since the counter[0] starts always at 0,
and an overflow is therefore (almost) impossible. Right?

[paulidale]

That's my understanding.

From what's discussed in C2SP/wycheproof#90, it seems like any overflow is extremely unlikely unless someone is trying to shoot themselves.

I don't think that precludes us from implementing it in a standards compliant manner.