4 ms·

ChaCha20-Poly1305 with long nonces – OpenSSL CVE-2019-1543

78 points by jorangreef 8y ago

ainar-g 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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.
haarts 8y ago
Genuine question; I wonder why OpenSSL deviates from the spec by allowing anything other than a 96 bit nonce.
- jorangreef 8y ago
  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 8y ago
    It's 12 bytes for both.
deleted 8y ago
[deleted]
jorangreef 8y ago
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
nemo1618 8y ago
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 8y ago
  It's on the standard track: https://tools.ietf.org/html/draft-arciszewski-xchacha-03 https://tools.ietf.org/html/draft-arciszewski-xchacha-03
- emilfihlman 8y ago
  Yes, many and a lot. High quality random sources are not a general availability, for example in small devices. The best would be to have a strong random nonce and a counter, or some combination of these, for example 64 bit counter appended to a 192 bit random vector. Even just a 64 bit sequential counter would last almost 600 years at 10^9 encryption operations per second.

78 points by jorangreef 8y ago

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 8y ago
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 8y ago
  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 8y ago
    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.

haarts 8y ago

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

jorangreef 8y ago
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 8y ago
  It's 12 bytes for both.

deleted 8y ago

[deleted]

jorangreef 8y ago

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

nemo1618 8y ago

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 8y ago
It's on the standard track: https://tools.ietf.org/html/draft-arciszewski-xchacha-03 https://tools.ietf.org/html/draft-arciszewski-xchacha-03
emilfihlman 8y ago
Yes, many and a lot. High quality random sources are not a general availability, for example in small devices. The best would be to have a strong random nonce and a counter, or some combination of these, for example 64 bit counter appended to a 192 bit random vector. Even just a 64 bit sequential counter would last almost 600 years at 10^9 encryption operations per second.