1. 17 3月, 2018 2 次提交
  2. 16 3月, 2018 1 次提交
  3. 07 3月, 2018 1 次提交
  4. 22 2月, 2018 1 次提交
  5. 15 2月, 2018 1 次提交
    • D
      DRBG: make locking api truly private · 812b1537
      Dr. Matthias St. Pierre 提交于
      In PR #5295 it was decided that the locking api should remain private
      and used only inside libcrypto. However, the locking functions were added
      back to `libcrypto.num` by `mkdef.pl`, because the function prototypes
      were still listed in `internal/rand.h`. (This header contains functions
      which are internal, but shared between libcrypto and libssl.)
      
      This commit moves the prototypes to `rand_lcl.h` and changes the names
      to lowercase, following the convention therein. It also corrects an
      outdated documenting comment.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5375)
      812b1537
  6. 14 2月, 2018 1 次提交
    • D
      DRBG: add locking api · 3ce1c27b
      Dr. Matthias St. Pierre 提交于
      This commit adds three new accessors to the internal DRBG lock
      
         int RAND_DRBG_lock(RAND_DRBG *drbg)
         int RAND_DRBG_unlock(RAND_DRBG *drbg)
         int RAND_DRBG_enable_locking(RAND_DRBG *drbg)
      
      The three shared DRBGs are intended to be used concurrently, so they
      have locking enabled by default. It is the callers responsibility to
      guard access to the shared DRBGs by calls to RAND_DRBG_lock() and
      RAND_DRBG_unlock().
      
      All other DRBG instances don't have locking enabled by default, because
      they are intendended to be used by a single thread. If it is desired,
      locking can be enabled by using RAND_DRBG_enable_locking().
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5294)
      3ce1c27b
  7. 09 2月, 2018 1 次提交
  8. 07 2月, 2018 2 次提交
  9. 06 2月, 2018 1 次提交
  10. 01 2月, 2018 2 次提交
    • B
      Revert the crypto "global lock" implementation · 63ab5ea1
      Benjamin Kaduk 提交于
      Conceptually, this is a squashed version of:
      
          Revert "Address feedback"
      
          This reverts commit 75551e07.
      
      and
      
          Revert "Add CRYPTO_thread_glock_new"
      
          This reverts commit ed6b2c79.
      
      But there were some intervening commits that made neither revert apply
      cleanly, so instead do it all as one shot.
      
      The crypto global locks were an attempt to cope with the awkward
      POSIX semantics for pthread_atfork(); its documentation (the "RATIONALE"
      section) indicates that the expected usage is to have the prefork handler
      lock all "global" locks, and the parent and child handlers release those
      locks, to ensure that forking happens with a consistent (lock) state.
      However, the set of functions available in the child process is limited
      to async-signal-safe functions, and pthread_mutex_unlock() is not on
      the list of async-signal-safe functions!  The only synchronization
      primitives that are async-signal-safe are the semaphore primitives,
      which are not really appropriate for general-purpose usage.
      
      However, the state consistency problem that the global locks were
      attempting to solve is not actually a serious problem, particularly for
      OpenSSL.  That is, we can consider four cases of forking application
      that might use OpenSSL:
      
      (1) Single-threaded, does not call into OpenSSL in the child (e.g.,
      the child calls exec() immediately)
      
      For this class of process, no locking is needed at all, since there is
      only ever a single thread of execution and the only reentrancy is due to
      signal handlers (which are themselves limited to async-signal-safe
      operation and should not be doing much work at all).
      
      (2) Single-threaded, calls into OpenSSL after fork()
      
      The application must ensure that it does not fork() with an unexpected
      lock held (that is, one that would get unlocked in the parent but
      accidentally remain locked in the child and cause deadlock).  Since
      OpenSSL does not expose any of its internal locks to the application
      and the application is single-threaded, the OpenSSL internal locks
      will be unlocked for the fork(), and the state will be consistent.
      (OpenSSL will need to reseed its PRNG in the child, but that is
      an orthogonal issue.)  If the application makes use of locks from
      libcrypto, proper handling for those locks is the responsibility of
      the application, as for any other locking primitive that is available
      for application programming.
      
      (3) Multi-threaded, does not call into OpenSSL after fork()
      
      As for (1), the OpenSSL state is only relevant in the parent, so
      no particular fork()-related handling is needed.  The internal locks
      are relevant, but there is no interaction with the child to consider.
      
      (4) Multi-threaded, calls into OpenSSL after fork()
      
      This is the case where the pthread_atfork() hooks to ensure that all
      global locks are in a known state across fork() would come into play,
      per the above discussion.  However, these "calls into OpenSSL after
      fork()" are still subject to the restriction to async-signal-safe
      functions.  Since OpenSSL uses all sorts of locking and libc functions
      that are not on the list of safe functions (e.g., malloc()), this
      case is not currently usable and is unlikely to ever be usable,
      independently of the locking situation.  So, there is no need to
      go through contortions to attempt to support this case in the one small
      area of locking interaction with fork().
      
      In light of the above analysis (thanks @davidben and @achernya), go
      back to the simpler implementation that does not need to distinguish
      "library-global" locks or to have complicated atfork handling for locks.
      Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
      Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
      (Merged from https://github.com/openssl/openssl/pull/5089)
      63ab5ea1
    • D
      crypto/rand/rand_lib.c: fix undefined reference to `clock_gettime' · 2e230e86
      Dr. Matthias St. Pierre 提交于
      Some older glibc versions require the `-lrt` linker option for
      resolving the reference to `clock_gettime'. Since it is not desired
      to add new library dependencies in version 1.1.1, the call to
      clock_gettime() is replaced by a call to gettimeofday() for the
      moment. It will be added back in version 1.2.
      Signed-off-by: NDr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/5199)
      2e230e86
  11. 29 1月, 2018 1 次提交
  12. 18 12月, 2017 1 次提交
  13. 18 10月, 2017 2 次提交
    • B
      Add missing RAND_DRBG locking · 2139145b
      Benjamin Kaduk 提交于
      The drbg's lock must be held across calls to RAND_DRBG_generate()
      to prevent simultaneous modification of internal state.
      
      This was observed in practice with simultaneous SSL_new() calls attempting
      to seed the (separate) per-SSL RAND_DRBG instances from the global
      rand_drbg instance; this eventually led to simultaneous calls to
      ctr_BCC_update() attempting to increment drbg->bltmp_pos for their
      respective partial final block, violating the invariant that bltmp_pos < 16.
      The AES operations performed in ctr_BCC_blocks() makes the race window
      quite easy to trigger.  A value of bltmp_pos greater than 16 induces
      catastrophic failure in ctr_BCC_final(), with subtraction overflowing
      and leading to an attempt to memset() to zero a very large range,
      which eventually reaches an unmapped page and segfaults.
      
      Provide the needed locking in get_entropy_from_parent(), as well as
      fixing a similar issue in RAND_priv_bytes().  There is also an
      unlocked call to RAND_DRBG_generate() in ssl_randbytes(), but the
      requisite serialization is already guaranteed by the requirements on
      the application's usage of SSL objects, and no further locking is
      needed for correct behavior.  In that case, leave a comment noting
      the apparent discrepancy and the reason for its safety (at present).
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/4328)
      2139145b
    • D
      Fix reseeding issues of the public RAND_DRBG · c16de9d8
      Dr. Matthias St. Pierre 提交于
      Reseeding is handled very differently by the classic RAND_METHOD API
      and the new RAND_DRBG api. These differences led to some problems when
      the new RAND_DRBG was made the default OpenSSL RNG. In particular,
      RAND_add() did not work as expected anymore. These issues are discussed
      on the thread '[openssl-dev] Plea for a new public OpenSSL RNG API'
      and in Pull Request #4328. This commit fixes the mentioned issues,
      introducing the following changes:
      
      - Replace the fixed size RAND_BYTES_BUFFER by a new RAND_POOL API which
        facilitates collecting entropy by the get_entropy() callback.
      - Don't use RAND_poll()/RAND_add() for collecting entropy from the
        get_entropy() callback anymore. Instead, replace RAND_poll() by
        RAND_POOL_acquire_entropy().
      - Add a new function rand_drbg_restart() which tries to get the DRBG
        in an instantiated state by all means, regardless of the current
        state (uninstantiated, error, ...) the DRBG is in. If the caller
        provides entropy or additional input, it will be used for reseeding.
      - Restore the original documented behaviour of RAND_add() and RAND_poll()
        (namely to reseed the DRBG immediately) by a new implementation based
        on rand_drbg_restart().
      - Add automatic error recovery from temporary failures of the entropy
        source to RAND_DRBG_generate() using the rand_drbg_restart() function.
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      Reviewed-by: NBen Kaduk <kaduk@mit.edu>
      (Merged from https://github.com/openssl/openssl/pull/4328)
      c16de9d8
  14. 01 9月, 2017 1 次提交
  15. 29 8月, 2017 1 次提交
  16. 28 8月, 2017 2 次提交
  17. 23 8月, 2017 1 次提交
  18. 08 8月, 2017 1 次提交
  19. 07 8月, 2017 1 次提交
  20. 06 8月, 2017 1 次提交
  21. 05 8月, 2017 1 次提交
  22. 03 8月, 2017 2 次提交
    • R
      Add RAND_priv_bytes() for private keys · ddc6a5c8
      Rich Salz 提交于
      Add a new global DRBG for private keys used by RAND_priv_bytes.
      
      Add BN_priv_rand() and BN_priv_rand_range() which use RAND_priv_bytes().
      Change callers to use the appropriate BN_priv... function.
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/4076)
      ddc6a5c8
    • 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
  23. 23 7月, 2017 1 次提交
    • R
      Add --with-rand-seed · 8389ec4b
      Rich Salz 提交于
      Add a new config param to specify how the CSPRNG should be seeded.
      Illegal values or nonsensical combinations (e.g., anything other
      than "os" on VMS or HP VOS etc) result in build failures.
      Add RDSEED support.
      Add RDTSC but leave it disabled for now pending more investigation.
      
      Refactor and reorganization all seeding files (rand_unix/win/vms) so
      that they are simpler.
      
      Only require 128 bits of seeding material.
      
      Many document improvements, including why to not use RAND_add() and the
      limitations around using load_file/write_file.
      Document RAND_poll().
      
      Cleanup Windows RAND_poll and return correct status
      
      More completely initialize the default DRBG.
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/3965)
      8389ec4b
  24. 20 7月, 2017 1 次提交
  25. 19 7月, 2017 1 次提交
  26. 15 7月, 2017 1 次提交
    • R
      Start to overhaul RAND API · da8fc25a
      Rich Salz 提交于
      Remove unused rand_hw_xor, MD/EVP indirection
      Make rand_pseudo same as rand.
      Cleanup formatting and ifdef control
      Rename some things:
          - rand_meth to openssl_rand_meth; make it global
          - source file
          - lock/init functions, start per-thread state
          - ossl_meth_init to ossl_rand_init
      Put state into RAND_STATE structure
      And put OSSL_RAND_STATE into ossl_typ.h
      Use "randomness" instead of "entropy"
      Reviewed-by: NBen Kaduk <kaduk@mit.edu>
      (Merged from https://github.com/openssl/openssl/pull/3758)
      da8fc25a
  27. 20 6月, 2017 1 次提交
  28. 10 4月, 2017 1 次提交
  29. 07 4月, 2017 2 次提交
  30. 06 4月, 2017 1 次提交
  31. 28 2月, 2017 1 次提交
    • E
      Clean up references to FIPS · b53338cb
      Emilia Kasper 提交于
      This removes the fips configure option. This option is broken as the
      required FIPS code is not available.
      
      FIPS_mode() and FIPS_mode_set() are retained for compatibility, but
      FIPS_mode() always returns 0, and FIPS_mode_set() can only be used to
      turn FIPS mode off.
      Reviewed-by: NStephen Henson <steve@openssl.org>
      b53338cb
  32. 18 5月, 2016 1 次提交
  33. 13 4月, 2016 1 次提交