Skip to content
  1. May 26, 2019
    • Simo Sorce's avatar
      Fix input checks wrt legacy code · d4d89a07
      Simo Sorce authored
      In all legacy code ctx->cipher is dereferenced without checks, so it
      makes no sense to jump there is ctx->cipher is NULL as it will just lead
      to a crash. Catch it separately and return an error.
      
      This is simlar to the fix in d2c2e49e
      
      
      
      Signed-off-by: default avatarSimo Sorce <simo@redhat.com>
      
      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/9002)
      d4d89a07
    • Laszlo Ersek's avatar
      crypto/evp/evp_key.c: #define BUFSIZ if <stdio.h> doesn't #define it · 2e9d61ec
      Laszlo Ersek authored
      CLA: trivial
      
      Fixes #8904
      
      Commit 48feaceb ("Remove the possibility to disable the UI module
      entirely", 2017-07-03) made the BUFSIZ references in "evp_key.c"
      unconditional, by deleting the preprocessing directive "#ifndef
      OPENSSL_NO_UI". This breaks the build when compiling OpenSSL for edk2
      (OPENSSL_SYS_UEFI), because edk2's <stdio.h> doesn't #define BUFSIZ.
      
      Provide a fallback definition, like we do in "crypto/ui/ui_util.c" (from
      commit 984d6c60
      
      , "Fix no-stdio build", 2015-09-29).
      
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      
      Reviewed-by: default avatarTomas Mraz <tmraz@fedoraproject.org>
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/8922)
      2e9d61ec
    • Daniël van Eeden's avatar
      Use fixed length for formatting standard cipher names · 7817e74d
      Daniël van Eeden authored
      
      
      Example with patch:
      ```
      $ openssl ciphers -stdname 'TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305'
      TLS_AES_256_GCM_SHA384                        - TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256) Mac=AEAD
      TLS_CHACHA20_POLY1305_SHA256                  - TLS_CHACHA20_POLY1305_SHA256   TLSv1.3 Kx=any      Au=any   Enc=CHACHA20/POLY1305(256) Mac=AEAD
      TLS_AES_128_GCM_SHA256                        - TLS_AES_128_GCM_SHA256         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(128) Mac=AEAD
      TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 - ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
      ```
      
      Example without patch:
      ```
      $ openssl ciphers -stdname 'TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305'
      TLS_AES_256_GCM_SHA384 - TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
      TLS_CHACHA20_POLY1305_SHA256 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
      TLS_AES_128_GCM_SHA256 - TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
      TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
      ```
      
      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)
      7817e74d
    • 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