Skip to content
  1. Mar 13, 2019
  2. Mar 11, 2019
  3. Mar 10, 2019
  4. Mar 07, 2019
  5. Mar 06, 2019
    • Matt Caswell's avatar
      Update ChaCha20-Poly1305 documentation · f7a6d112
      Matt Caswell authored
      
      
      Correctly describe the maximum IV length.
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8406)
      
      (cherry picked from commit 27d5631236325c3fd8a3bd06af282ac496aac64b)
      f7a6d112
    • Matt Caswell's avatar
      Test an overlong ChaCha20-Poly1305 nonce · 9b10d1bf
      Matt Caswell authored
      
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8406)
      
      (cherry picked from commit a4f0b50eafb256bb802f2724fc7f7580fb0fbabc)
      9b10d1bf
    • Matt Caswell's avatar
      Prevent over long nonces in ChaCha20-Poly1305 · f426625b
      Matt Caswell authored
      
      
      ChaCha20-Poly1305 is an AEAD cipher, and requires a unique nonce input for
      every encryption operation. RFC 7539 specifies that the nonce value (IV)
      should be 96 bits (12 bytes). OpenSSL allows a variable nonce length and
      front pads the nonce with 0 bytes if it is less than 12 bytes. However it
      also incorrectly allows a nonce to be set of up to 16 bytes. In this case
      only the last 12 bytes are significant and any additional leading bytes are
      ignored.
      
      It is a requirement of using this cipher that nonce values are unique.
      Messages encrypted using a reused nonce value are susceptible to serious
      confidentiality and integrity attacks. If an application changes the
      default nonce length to be longer than 12 bytes and then makes a change to
      the leading bytes of the nonce expecting the new value to be a new unique
      nonce then such an application could inadvertently encrypt messages with a
      reused nonce.
      
      Additionally the ignored bytes in a long nonce are not covered by the
      integrity guarantee of this cipher. Any application that relies on the
      integrity of these ignored leading bytes of a long nonce may be further
      affected.
      
      Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe
      because no such use sets such a long nonce value. However user
      applications that use this cipher directly and set a non-default nonce
      length to be longer than 12 bytes may be vulnerable.
      
      CVE-2019-1543
      
      Fixes #8345
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8406)
      
      (cherry picked from commit 2a3d0ee9d59156c48973592331404471aca886d6)
      f426625b
  6. Mar 05, 2019
  7. Mar 04, 2019
  8. Mar 01, 2019
  9. Feb 28, 2019
  10. Feb 27, 2019
  11. Feb 26, 2019