1. 20 6月, 2018 1 次提交
  2. 19 6月, 2018 1 次提交
  3. 15 6月, 2018 1 次提交
  4. 09 6月, 2018 1 次提交
  5. 31 5月, 2018 1 次提交
    • U
      bn/bn_exp.c: mitigation of the One-and-Done side-channel attack. · 848113a3
      User 提交于
      The One&Done attack, which is described in a paper to appear in the
      USENIX Security'18 conference, uses EM emanations to recover the values
      of the bits that are obtained using BN_is_bit_set while constructing
      the value of the window in BN_mod_exp_consttime. The EM signal changes
      slightly depending on the value of the bit, and since the lookup of a
      bit is surrounded by highly regular execution (constant-time Montgomery
      multiplications) the attack is able to isolate the (very brief) part of
      the signal that changes depending on the bit. Although the change is
      slight, the attack recovers it successfully >90% of the time on several
      phones and IoT devices (all with ARM processors with clock rates around
      1GHz), so after only one RSA decryption more than 90% of the bits in
      d_p and d_q are recovered correctly, which enables rapid recovery of
      the full RSA key using an algorithm (also described in the paper) that
      modifies the branch-and-prune approach for a situation in which the
      exponents' bits are recovered with errors, i.e. where we do not know
      a priori which bits are correctly recovered.
      
      The mitigation for the attack is relatively simple - all the bits of
      the window are obtained at once, along with other bits so that an
      entire integer's worth of bits are obtained together using masking and
      shifts, without unnecessarily considering each bit in isolation. This
      improves performance somewhat (one call to bn_get_bits is faster than
      several calls to BN_is_bit_set), so the attacker now gets one signal
      snippet per window (rather than one per bit) in which the signal is
      affected by all bits in the integer (rather than just the one bit).
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/6276)
      848113a3
  6. 29 5月, 2018 2 次提交
  7. 17 5月, 2018 1 次提交
    • M
      Make BN_GF2m_mod_arr more constant time · b336ce57
      Matt Caswell 提交于
      Experiments have shown that the lookup table used by BN_GF2m_mod_arr
      introduces sufficient timing signal to recover the private key for an
      attacker with access to cache timing information on the victim's host.
      This only affects binary curves (which are less frequently used).
      
      No CVE is considered necessary for this issue.
      
      The fix is to replace the lookup table with an on-the-fly calculation of
      the value from the table instead, which can be performed in constant time.
      
      Thanks to Youngjoo Shin for reporting this issue.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/6270)
      b336ce57
  8. 11 5月, 2018 1 次提交
  9. 09 5月, 2018 1 次提交
  10. 03 5月, 2018 2 次提交
  11. 27 4月, 2018 2 次提交
  12. 24 4月, 2018 2 次提交
  13. 18 4月, 2018 1 次提交
  14. 17 4月, 2018 1 次提交
  15. 03 4月, 2018 3 次提交
  16. 31 3月, 2018 1 次提交
  17. 28 3月, 2018 2 次提交
  18. 20 3月, 2018 1 次提交
  19. 18 3月, 2018 1 次提交
  20. 07 3月, 2018 1 次提交
  21. 27 2月, 2018 1 次提交
  22. 15 2月, 2018 2 次提交
    • R
      VMS: modify crypto/bn/asm/ia64.S to build properly · 6e652da4
      Richard Levitte 提交于
      On VMS, 'abort' is really 'decc$abort'
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5357)
      6e652da4
    • R
      Harmonize the make variables across all known platforms families · 722c9762
      Richard Levitte 提交于
      The make variables LIB_CFLAGS, DSO_CFLAGS and so on were used in
      addition to CFLAGS and so on.  This works without problem on Unix and
      Windows, where options with different purposes (such as -D and -I) can
      appear anywhere on the command line and get accumulated as they come.
      This is not necessarely so on VMS.  For example, macros must all be
      collected and given through one /DEFINE, and the same goes for
      inclusion directories (/INCLUDE).
      
      So, to harmonize all platforms, we repurpose make variables starting
      with LIB_, DSO_ and BIN_ to be all encompassing variables that
      collects the corresponding values from CFLAGS, CPPFLAGS, DEFINES,
      INCLUDES and so on together with possible config target values
      specific for libraries DSOs and programs, and use them instead of the
      general ones everywhere.
      
      This will, for example, allow VMS to use the exact same generators for
      generated files that go through cpp as all other platforms, something
      that has been impossible to do safely before now.
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5357)
      722c9762
  23. 14 2月, 2018 1 次提交
  24. 13 2月, 2018 1 次提交
  25. 07 2月, 2018 1 次提交
  26. 02 2月, 2018 3 次提交
    • D
      Fix timing leak in BN_from_montgomery_word. · f345b1f3
      David Benjamin 提交于
      BN_from_montgomery_word doesn't have a constant memory access pattern.
      Replace the pointer trick with a constant-time select. There is, of
      course, still the bn_correct_top leak pervasive in BIGNUM itself.
      
      See also https://boringssl-review.googlesource.com/22904 from BoringSSL.
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
      (Merged from https://github.com/openssl/openssl/pull/5228)
      f345b1f3
    • D
      Don't leak the exponent bit width in BN_mod_exp_mont_consttime. · 39eeb64f
      David Benjamin 提交于
      The exponent here is one of d, dmp1, or dmq1 for RSA. This value and its
      bit length are both secret. The only public upper bound is the bit width
      of the corresponding modulus (RSA n, p, and q, respectively).
      
      Although BN_num_bits is constant-time (sort of; see bn_correct_top notes
      in preceding patch), this does not fix the root problem, which is that
      the windows are based on the minimal bit width, not the upper bound. We
      could use BN_num_bits(m), but BN_mod_exp_mont_consttime is public API
      and may be called with larger exponents. Instead, use all top*BN_BITS2
      bits in the BIGNUM. This is still sensitive to the long-standing
      bn_correct_top leak, but we need to fix that regardless.
      
      This may cause us to do a handful of extra multiplications for RSA keys
      which are just above a whole number of words, but that is not a standard
      RSA key size.
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5154)
      39eeb64f
    • D
      Make BN_num_bits_word constant-time. · 972c87df
      David Benjamin 提交于
      (This patch was written by Andy Polyakov. I only wrote the commit
      message. Mistakes in the analysis are my fault.)
      
      BN_num_bits, by way of BN_num_bits_word, currently leaks the
      most-significant word of its argument via branching and memory access
      pattern.
      
      BN_num_bits is called on RSA prime factors in various places. These have
      public bit lengths, but all bits beyond the high bit are secret. This
      fully resolves those cases.
      
      There are a few places where BN_num_bits is called on an input where the
      bit length is also secret. This does *not* fully resolve those cases as
      we still only look at the top word. Today, that is guaranteed to be
      non-zero, but only because of the long-standing bn_correct_top timing
      leak. Once that is fixed, a constant-time BN_num_bits on such inputs
      must count bits on each word.
      
      Instead, those cases should not call BN_num_bits at all. In particular,
      BN_mod_exp_mont_consttime uses the exponent bit width to pick windows,
      but it should be using the maximum bit width. The next patch will fix
      this.
      
      Thanks to Dinghao Wu, Danfeng Zhang, Shuai Wang, Pei Wang, and Xiao Liu
      for reporting this issue.
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5154)
      972c87df
  27. 28 1月, 2018 1 次提交
  28. 19 1月, 2018 1 次提交
  29. 16 1月, 2018 1 次提交
    • M
      Revert BN_copy() flag copy semantics change · 7d461736
      Matt Caswell 提交于
      Commit 9f944291 changed the semantics of BN_copy() to additionally
      copy the BN_FLG_CONSTTIME flag if it is set. This turns out to be
      ill advised as it has unintended consequences. For example calling
      BN_mod_inverse_no_branch() can sometimes return a result with the flag
      set and sometimes not as a result. This can lead to later failures if we
      go down code branches that do not support constant time, but check for
      the presence of the flag.
      
      The original commit was made due to an issue in BN_MOD_CTX_set(). The
      original PR fixed the problem in that function, but it was changed in
      review to fix it in BN_copy() instead. The solution seems to be to revert
      the BN_copy() change and go back to the originally proposed way.
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/5080)
      7d461736
  30. 06 12月, 2017 1 次提交