Skip to content
  1. Feb 28, 2019
  2. Feb 27, 2019
  3. Feb 26, 2019
  4. Feb 25, 2019
    • Richard Levitte's avatar
      Rearrange the inclusion of curve448/curve448_lcl.h · 13d928d3
      Richard Levitte authored
      
      
      The real cause for this change is that test/ec_internal_test.c
      includes ec_lcl.h, and including curve448/curve448_lcl.h from there
      doesn't work so well with compilers who always do inclusions relative
      to the C file being compiled.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8334)
      
      (cherry picked from commit f408e2a3)
      13d928d3
    • Matt Caswell's avatar
      Ensure bn_cmp_words can handle the case where n == 0 · 576129cd
      Matt Caswell authored
      
      
      Thanks to David Benjamin who reported this, performed the analysis and
      suggested the patch. I have incorporated some of his analysis in the
      comments below.
      
      This issue can cause an out-of-bounds read. It is believed that this was
      not reachable until the recent "fixed top" changes. Analysis has so far
      only identified one code path that can encounter this - although it is
      possible that others may be found. The one code path only impacts 1.0.2 in
      certain builds. The fuzzer found a path in RSA where iqmp is too large. If
      the input is all zeros, the RSA CRT logic will multiply a padded zero by
      iqmp. Two mitigating factors:
      
      - Private keys which trip this are invalid (iqmp is not reduced mod p).
      Only systems which take untrusted private keys care.
      - In OpenSSL 1.1.x, there is a check which rejects the oversize iqmp,
      so the bug is only reproducible in 1.0.2 so far.
      
      Fortunately, the bug appears to be relatively harmless. The consequences of
      bn_cmp_word's misbehavior are:
      
      - OpenSSL may crash if the buffers are page-aligned and the previous page is
      non-existent.
      - OpenSSL will incorrectly treat two BN_ULONG buffers as not equal when they
      are equal.
      - Side channel concerns.
      
      The first is indeed a concern and is a DoS bug. The second is fine in this
      context. bn_cmp_word and bn_cmp_part_words are used to compute abs(a0 - a1)
      in Karatsuba. If a0 = a1, it does not matter whether we use a0 - a1 or
      a1 - a0. The third would be worth thinking about, but it is overshadowed
      by the entire Karatsuba implementation not being constant time.
      
      Due to the difficulty of tripping this and the low impact no CVE is felt
      necessary for this issue.
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      Reviewed-by: default avatarViktor Dukhovni <viktor@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8326)
      576129cd
    • David von Oheimb's avatar
  5. Feb 24, 2019
  6. Feb 22, 2019
  7. Feb 21, 2019
  8. Feb 20, 2019
    • Markus Stockhausen's avatar
      MIPS32R3 provides the EXT instruction to extract bits from · 45921723
      Markus Stockhausen authored
      
      registers. As the AES table is already 1K aligned we can
      use it everywhere and speedup table address calculation by
      10%. Performance numbers:
      
      decryption         16B       64B      256B     1024B     8192B
      -------------------------------------------------------------------
      aes-256-cbc   5636.84k  6443.26k  6689.02k  6752.94k  6766.59k bef.
      aes-256-cbc   6200.31k  7195.71k  7504.30k  7585.11k  7599.45k aft.
      -------------------------------------------------------------------
      aes-128-cbc   7313.85k  8653.67k  9079.55k  9188.35k  9205.08k bef.
      aes-128-cbc   7925.38k  9557.99k 10092.37k 10232.15k 10272.77k aft.
      
      encryption         16B       64B      256B     1024B     8192B
      -------------------------------------------------------------------
      aes-256 cbc   6009.65k  6592.70k  6766.59k  6806.87k  6815.74k bef.
      aes-256 cbc   6643.93k  7388.69k  7605.33k  7657.81k  7675.90k aft.
      -------------------------------------------------------------------
      aes-128 cbc   7862.09k  8892.48k  9214.04k  9291.78k  9311.57k bef.
      aes-128 cbc   8639.29k  9881.17k 10265.86k 10363.56k 10392.92k aft.
      
      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/8206)
      45921723