Skip to content
  1. May 26, 2019
    • Daniël van Eeden's avatar
      Update format string for ciphers to account for newer ciphers · 26648109
      Daniël van Eeden authored
      
      
      * Cipher name: from 23 to 30 (example: ECDHE-ECDSA-AES128-GCM-SHA256)
      * Fixed length for TLS version (examples: TLSv1, TLSv1.3)
      * Au length from 4 to 5 (example: ECDSA)
      
      Example (without patch):
      ```
      $ openssl ciphers -v 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA'
      TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
      TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
      TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
      ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
      ECDHE-ECDSA-AES128-SHA  TLSv1 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
      ```
      
      Example (with patch):
      ```
      $ openssl ciphers -v 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA'
      TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256) Mac=AEAD
      TLS_CHACHA20_POLY1305_SHA256   TLSv1.3 Kx=any      Au=any   Enc=CHACHA20/POLY1305(256) Mac=AEAD
      TLS_AES_128_GCM_SHA256         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(128) Mac=AEAD
      ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
      ECDHE-ECDSA-AES128-SHA         TLSv1   Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
      ```
      
      CLA: trivial
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8999)
      26648109
  2. May 24, 2019
  3. May 23, 2019
  4. May 22, 2019
  5. May 21, 2019
  6. May 20, 2019
  7. May 17, 2019
    • Daniel Axtens's avatar
      ppc assembly pack: always increment CTR IV as quadword · e9f148c9
      Daniel Axtens authored
      
      
      The kernel self-tests picked up an issue with CTR mode. The issue was
      detected with a test vector with an IV of
      FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD: after 3 increments it should wrap
      around to 0.
      
      There are two paths that increment IVs: the bulk (8 at a time) path,
      and the individual path which is used when there are fewer than 8 AES
      blocks to process.
      
      In the bulk path, the IV is incremented with vadduqm: "Vector Add
      Unsigned Quadword Modulo", which does 128-bit addition.
      
      In the individual path, however, the IV is incremented with vadduwm:
      "Vector Add Unsigned Word Modulo", which instead does 4 32-bit
      additions. Thus the IV would instead become
      FFFFFFFFFFFFFFFFFFFFFFFF00000000, throwing off the result.
      
      Use vadduqm.
      
      This was probably a typo originally, what with q and w being
      adjacent.
      
      CLA: trivial
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/8942)
      e9f148c9
  8. May 16, 2019
  9. May 12, 2019
  10. May 10, 2019
  11. May 09, 2019