GPU VulnDB

Database/Kernel, userspace & hypervisor

OpenSSL: ChaCha20-Poly1305 accepts 16-byte nonces, silently ignoring leading bytes

CVSS 7.4CVE-2019-1543Kernel, userspace & hypervisorcurated

Impact

OpenSSL 1.1.0 and 1.1.1 allow a ChaCha20-Poly1305 nonce of up to 16 bytes, but only the trailing 12 bytes are significant. An application that sets a longer nonce and varies the leading bytes to obtain uniqueness is in fact reusing the nonce, which breaks both the confidentiality and the integrity guarantees of the AEAD construction; the ignored leading bytes are also outside the integrity tag. OpenSSL's own TLS and internal uses never set such a nonce and are unaffected, so for an operator the exposure is limited to in-house or third-party code on the fleet that calls this cipher directly with a non-default nonce length - for example a custom encryption layer in a storage or telemetry agent. Rated low severity by OpenSSL because of that narrow scope.

Who can reach it

Remote attacker against an application that uses ChaCha20-Poly1305 directly with a nonce length longer than 12 bytes. No OpenSSL-level authentication is involved; stock TLS deployments are not exposed.

What to do

Move to OpenSSL 1.1.1c or 1.1.0k (or a distribution package carrying the backport) and restart services that link it; OpenSSL did not cut emergency releases for this. The durable fix is in application code: use a 12-byte nonce for ChaCha20-Poly1305 and never rely on leading bytes of a longer one for uniqueness.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.