1. 03 3月, 2022 1 次提交
  2. 21 1月, 2022 1 次提交
  3. 14 12月, 2021 1 次提交
    • B
      Fix a carry overflow bug in bn_sqr_comba4/8 for mips 32-bit targets · 336923c0
      Bernd Edlinger 提交于
      bn_sqr_comba8 does for instance compute a wrong result for the value:
      a=0x4aaac919 62056c84 fba7334e 1a6be678 022181ba fd3aa878 899b2346 ee210f45
      
      The correct result is:
      r=0x15c72e32 605a3061 d11b1012 3c187483 6df96999 bd0c22ba d3e7d437 4724a82f
          912c5e61 6a187efe 8f7c47fc f6945fe5 75be8e3d 97ed17d4 7950b465 3cb32899
      
      but the actual result was:
      r=0x15c72e32 605a3061 d11b1012 3c187483 6df96999 bd0c22ba d3e7d437 4724a82f
          912c5e61 6a187efe 8f7c47fc f6945fe5 75be8e3c 97ed17d4 7950b465 3cb32899
      
      so the forth word of the result was 0x75be8e3c but should have been
      0x75be8e3d instead.
      
      Likewise bn_sqr_comba4 has an identical bug for the same value as well:
      a=0x022181ba fd3aa878 899b2346 ee210f45
      
      correct result:
      r=0x00048a69 9fe82f8b 62bd2ed1 88781335 75be8e3d 97ed17d4 7950b465 3cb32899
      
      wrong result:
      r=0x00048a69 9fe82f8b 62bd2ed1 88781335 75be8e3c 97ed17d4 7950b465 3cb32899
      
      Fortunately the bn_mul_comba4/8 code paths are not affected.
      
      Also the mips64 target does in fact not handle the carry propagation
      correctly.
      
      Example:
      a=0x4aaac91900000000 62056c8400000000 fba7334e00000000 1a6be67800000000
          022181ba00000000 fd3aa87800000000 899b234635dad283 ee210f4500000001
      
      correct result:
      r=0x15c72e32272c4471 392debf018c679c8 b85496496bf8254c d0204f36611e2be1
          0cdb3db8f3c081d8 c94ba0e1bacc5061 191b83d47ff929f6 5be0aebfc13ae68d
          3eea7a7fdf2f5758 42f7ec656cab3cb5 6a28095be34756f2 64f24687bf37de06
          2822309cd1d292f9 6fa698c972372f09 771e97d3a868cda0 dc421e8a00000001
      
      wrong result:
      r=0x15c72e32272c4471 392debf018c679c8 b85496496bf8254c d0204f36611e2be1
          0cdb3db8f3c081d8 c94ba0e1bacc5061 191b83d47ff929f6 5be0aebfc13ae68d
          3eea7a7fdf2f5758 42f7ec656cab3cb5 6a28095be34756f2 64f24687bf37de06
          2822309cd1d292f8 6fa698c972372f09 771e97d3a868cda0 dc421e8a00000001
      Reviewed-by: NPaul Dale <pauli@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/17258)
      336923c0
  4. 27 11月, 2021 1 次提交
  5. 28 10月, 2021 1 次提交
  6. 07 7月, 2021 1 次提交
  7. 17 6月, 2021 1 次提交
  8. 02 6月, 2021 1 次提交
  9. 15 10月, 2020 1 次提交
  10. 13 9月, 2020 1 次提交
    • R
      NonStop port updates for 3.0.0. · 08073700
      Randall S. Becker 提交于
      HPE NonStop Port Changes for 3.0.0  Includes unthreaded, PUT, and SPT for OSS.
      
      The port changes include wrapping where necessary for FLOSS and
      appropriate configuration changes to support that. Two tests
      are excluded as being inappropriate for the platform.
      
      The changes are:
      * Added /usr/local/include to nonstop-nsx_spt_floss to load floss.h
      * Added SPT Floss variant for NonStop
      * Wrapped FLOSS definitions in OPENSSL_TANDEM_FLOSS to allow selective enablement.
      * SPT build configuration for NonStop
      * Skip tests not relevant for NonStop
      * PUT configuration changes required for NonStop platforms
      * Configurations/50-nonstop.conf: updates for TNS/X platform.
      * FLOSS instrumentation for HPE NonStop TNS/X and TNS/E platforms.
      * Configurations/50-nonstop.conf: modifications for non-PUT TNS/E platform b
      * Fix use of DELAY in ssltestlib.c for HPNS.
      * Fixed commit merge issues and added floss to http_server.c
      
      CLA: Permission is granted by the author to the OpenSSL team to use these modifications.
      Fixes #5087.
      Signed-off-by: NRandall S. Becker <rsbecker@nexbridge.com>
      Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/12800)
      08073700
  11. 12 12月, 2019 1 次提交
  12. 06 12月, 2019 1 次提交
  13. 17 10月, 2019 1 次提交
  14. 15 10月, 2019 1 次提交
  15. 16 7月, 2019 1 次提交
  16. 07 7月, 2019 1 次提交
  17. 29 5月, 2019 1 次提交
  18. 25 4月, 2019 1 次提交
  19. 18 3月, 2019 1 次提交
  20. 21 2月, 2019 1 次提交
    • N
      Test for constant-time flag leakage in BN_CTX · fe16ae5f
      Nicola Tuveri 提交于
      This commit adds a simple unit test to make sure that the constant-time
      flag does not "leak" among BN_CTX frames:
      
      - test_ctx_consttime_flag() initializes (and later frees before
        returning) a BN_CTX object, then it calls in sequence
        test_ctx_set_ct_flag() and test_ctx_check_ct_flag() using the same
        BN_CTX object. The process is run twice, once with a "normal"
        BN_CTX_new() object, then with a BN_CTX_secure_new() one.
      - test_ctx_set_ct_flag() starts a frame in the given BN_CTX and sets the
        BN_FLG_CONSTTIME flag on some of the BIGNUMs obtained from the frame
        before ending it.
      - test_ctx_check_ct_flag() then starts a new frame and gets a number of
        BIGNUMs from it. In absence of leaks, none of the BIGNUMs in the new
        frame should have BN_FLG_CONSTTIME set.
      
      In actual BN_CTX usage inside libcrypto the leak could happen at any
      depth level in the BN_CTX stack, with varying results depending on the
      patterns of sibling trees of nested function calls sharing the same
      BN_CTX object, and the effect of unintended BN_FLG_CONSTTIME on the
      called BN_* functions.
      
      This simple unit test abstracts away this complexity and verifies that
      the leak does not happen between two sibling functions sharing the same
      BN_CTX object at the same level of nesting.
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8253)
      fe16ae5f
  21. 11 2月, 2019 1 次提交
  22. 17 1月, 2019 1 次提交
  23. 06 12月, 2018 1 次提交
  24. 22 6月, 2018 1 次提交
  25. 29 5月, 2018 1 次提交
  26. 27 4月, 2018 1 次提交
  27. 31 3月, 2018 1 次提交
  28. 13 2月, 2018 1 次提交
  29. 22 1月, 2018 1 次提交
  30. 06 12月, 2017 1 次提交
  31. 28 11月, 2017 1 次提交
  32. 13 11月, 2017 1 次提交
  33. 02 11月, 2017 1 次提交
  34. 30 8月, 2017 1 次提交
  35. 22 8月, 2017 1 次提交
  36. 18 8月, 2017 2 次提交
  37. 16 8月, 2017 1 次提交
  38. 10 8月, 2017 1 次提交
  39. 03 8月, 2017 1 次提交
    • R
      Switch from ossl_rand to DRBG rand · 75e2c877
      Rich Salz 提交于
      If RAND_add wraps around, XOR with existing. Add test to drbgtest that
      does the wrap-around.
      
      Re-order seeding and stop after first success.
      
      Add RAND_poll_ex()
      
      Use the DF and therefore lower RANDOMNESS_NEEDED.  Also, for child DRBG's,
      mix in the address as the personalization bits.
      
      Centralize the entropy callbacks, from drbg_lib to rand_lib.
      (Conceptually, entropy is part of the enclosing application.)
      Thanks to Dr. Matthias St Pierre for the suggestion.
      
      Various code cleanups:
          -Make state an enum; inline RANDerr calls.
          -Add RAND_POLL_RETRIES (thanks Pauli for the idea)
          -Remove most RAND_seed calls from rest of library
          -Rename DRBG_CTX to RAND_DRBG, etc.
          -Move some code from drbg_lib to drbg_rand; drbg_lib is now only the
           implementation of NIST DRBG.
          -Remove blocklength
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/4019)
      75e2c877