
ChaCha20-Poly1305 with long nonces – OpenSSL CVE-2019-1543 - jorangreef
https://www.openssl.org/news/secadv/20190306.txt
======
jorangreef
Some of the backstory, in case anyone is interested:

We found this through invariant fuzzing @ronomon/crypto-async
([https://github.com/ronomon/crypto-async](https://github.com/ronomon/crypto-
async)), which depends on OpenSSL.

The invariant fuzzing simply does a few thousand random roundtrips (encrypt,
decrypt) through all the OpenSSL AEAD ciphers we want to support, corrupting
any of {key, iv, ciphertext, aad, tag} and asserting that the authentication
guarantee is maintained by the AEAD cipher.

In addition to the CVE, this quickly found a few small unrelated issues:

 _EVP_CTRL_AEAD_SET_TAG fails for OCB [1]_

 _AEAD: EVP_CIPHER_CTX_iv_length is oblivious to EVP_CTRL_AEAD_SET_IVLEN [2]_

 _EVP_CipherUpdate() setting AAD for AES-256-OCB returns incorrect `outlen`
[3]_

[1]
[https://github.com/openssl/openssl/issues/8331](https://github.com/openssl/openssl/issues/8331)

[2]
[https://github.com/openssl/openssl/issues/8330](https://github.com/openssl/openssl/issues/8330)

[3]
[https://github.com/openssl/openssl/issues/8310](https://github.com/openssl/openssl/issues/8310)

------
haarts
Genuine question; I wonder why OpenSSL deviates from the spec by allowing
anything other than a 96 bit nonce.

~~~
jorangreef
Just a theory, but I think the author who introduced this deviation, may have
confused the nonce length for ChaCha20 (16-bytes) with the nonce length for
ChaCha20-Poly1305 (12-bytes), reusing CHACHA_CTR_SIZE for both.

~~~
nmadden
It's 12 bytes for both.

------
ainar-g
MITRE link: [https://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2019-1543](https://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2019-1543).

Couldn't find anything about LibreSSL, so I guess it's not affected?

~~~
blattimwind
This is a bug in OpenSSL insofar that it allows you to supply invalid values
(which are silently truncated); an application being vulnerable still requires
the application to be buggy as well.

~~~
jorangreef
The thing is, OpenSSL already supports longer-than-default 12-byte nonces for
GCM and OCB, and as of a day ago used to support the same for
ChaCha20-Poly1305. GCM and OCB don't fail however. That makes this less of an
application bug, and more of a hole in the OpenSSL implementation.

In the first place, support for longer-than-default nonces should never have
been introduced by OpenSSL. But far worse, all along there was simply no
implementation behind it for ChaCha20-Poly1305. The first 4 bytes were simply
discarded.

~~~
blattimwind
The difference is that for GCM and OCB nonces with lengths different from 96
bits are defined (albeit not recommended), whereas Chacha20-Poly1305 doesn't
support that in the first place.

The bug isn't OpenSSL throwing bytes away, the bug is OpenSSL acting as-if
anything other than 96 bit nonces are acceptable.

------
nemo1618
Interesting. There's also "XChaCha20-Poly1305", with a 192-bit nonce (long
enough to be chosen randomly), but I don't know if this is standardized.

It seems to me that using a long, explicit, random nonce is always preferable
to using a short, implicit, sequential nonce. Are there any systems that
really can't accommodate this?

~~~
jedisct1
It's on the standard track: [https://tools.ietf.org/html/draft-arciszewski-
xchacha-03](https://tools.ietf.org/html/draft-arciszewski-xchacha-03)

