Skip to content

T
Third Party Openssl

OpenHarmony / Third Party Openssl
1 年多 前同步成功

通知 10
Star 18
Fork 1
T
Third Party Openssl
切换分支/标签
  1. 26 5月, 2023 1 次提交
  3. 12 4月, 2023 2 次提交
  5. 10 8月, 2021 1 次提交
  7. 27 2月, 2020 1 次提交
  9. 28 9月, 2019 1 次提交
  11. 26 2月, 2019 1 次提交
  13. 17 1月, 2019 1 次提交
  15. 30 10月, 2018 1 次提交
  17. 24 7月, 2018 1 次提交
  19. 12 7月, 2018 1 次提交
  21. 15 6月, 2018 1 次提交
  23. 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
  25. 29 5月, 2018 1 次提交
  27. 13 2月, 2018 1 次提交
  29. 02 2月, 2018 1 次提交
    • 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
  31. 17 11月, 2017 1 次提交
  33. 18 10月, 2017 1 次提交
  35. 11 10月, 2017 1 次提交
    • M
      Ensure we test all parameters for BN_FLG_CONSTTIME · e913d11f
      由 Matt Caswell 提交于 
      RSA_setup_blinding() calls BN_BLINDING_create_param() which later calls
BN_mod_exp() as follows:

BN_mod_exp(ret->A, ret->A, ret->e, ret->mod, ctx)

ret->mod will have BN_FLG_CONSTTIME set, but ret->e does not. In
BN_mod_exp() we only test the third param for the existence of this flag.
We should test all the inputs.

Thanks to Samuel Weiser (samuel.weiser@iaik.tugraz.at) for reporting this
issue.

This typically only happens once at key load, so this is unlikely to be
exploitable in any real scenario.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4477)
      e913d11f
  37. 26 6月, 2017 1 次提交
  39. 01 3月, 2017 1 次提交
  41. 16 11月, 2016 1 次提交
  43. 15 8月, 2016 1 次提交
  45. 29 6月, 2016 1 次提交
  47. 28 5月, 2016 1 次提交
  49. 18 5月, 2016 1 次提交
  51. 01 3月, 2016 2 次提交
  53. 27 1月, 2016 1 次提交
    • R
      Remove /* foo.c */ comments · 34980760
      由 Rich Salz 提交于 
      This was done by the following
        find . -name '*.[ch]' | /tmp/pl
where /tmp/pl is the following three-line script:
        print unless $. == 1 && m@/\* .*\.[ch] \*/@;
        close ARGV if eof; # Close file to reset $.

And then some hand-editing of other files.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
      34980760
  55. 20 12月, 2015 1 次提交
  57. 15 12月, 2015 1 次提交
  59. 01 9月, 2015 1 次提交
  61. 23 6月, 2015 1 次提交
    • R
      Rearrange rsaz · ed45f3c2
      由 Richard Levitte 提交于 
      A small rearrangement so the inclusion of rsaz_exp.h would be
unconditional, but what that header defines becomes conditional.

This solves the weirdness where rsaz_exp.h gets in and out of the
dependency list for bn_exp.c, depending on the present architecture.
Reviewed-by: NRich Salz <rsalz@openssl.org>
      ed45f3c2
  63. 14 5月, 2015 1 次提交
  65. 01 5月, 2015 2 次提交
  67. 29 4月, 2015 1 次提交
  69. 12 3月, 2015 1 次提交
  71. 22 1月, 2015 2 次提交