4 ms·
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 a
by 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 agoThis 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 agoThe 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 agoThe 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.