- 30 3月, 2018 1 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
The RAND_DRBG API was added in PR #5462 and modified by PR #5547. This commit adds the corresponding documention. Reviewed-by: NKurt Roeckx <kurt@roeckx.be> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5461)
-
- 29 3月, 2018 2 次提交
-
-
由 Benjamin Kaduk 提交于
Add some more exposition on why unlocked access to the global rand_fork_count is safe, and provide a comment for the struct rand_drbg_st fork_count field. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/4110)
-
由 Richard Levitte 提交于
The VMS C RTL has setbuf() working for short pointers only, probably the FILE pointer will always be in P0 (the lower 4GB). Fortunately, this only generates a warning about possible data loss (doesn't apply in this case) that we can simply turn off. Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5789)
-
- 28 3月, 2018 1 次提交
-
-
由 Andy Polyakov 提交于
Apparently applications rely on RAND_load_file's ability to work with non-regular files, customarily with /dev/urandom, so that the ban was not exactly appropriate. Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5737)
-
- 22 3月, 2018 1 次提交
-
-
由 Kurt Roeckx 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> GH: #5580
-
- 21 3月, 2018 1 次提交
-
-
由 Andy Polyakov 提交于
At earlier point e_os.h was omitted from a number of headers (in order to emphasize OS neutrality), but this affected o_fopen.c and randfile.c which are not OS-neutral, and contain some Win32-specific code. Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5676)
-
- 20 3月, 2018 2 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5689)
-
由 Richard Levitte 提交于
Without it, the RAND_POOL typedef is missing Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5685)
-
- 19 3月, 2018 1 次提交
-
-
由 Kurt Roeckx 提交于
This avoids lock contention. Reviewed-by: NTim Hudson <tjh@openssl.org> Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/5547)
-
- 17 3月, 2018 4 次提交
-
-
由 Kurt Roeckx 提交于
There is a requirements of having access to a live entropy source which we can't do with the default callbacks. If you need prediction resistance you need to set up your own callbacks that follow the requirements of NIST SP 800-90C. Reviewed-by: NDr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> GH: #5402
-
由 Kurt Roeckx 提交于
Reviewed-by: NDr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> GH: #5402
-
由 Bernd Edlinger 提交于
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5646)
-
由 Dr. Matthias St. Pierre 提交于
This commit adds a new api RAND_DRBG_set_defaults() which sets the default type and flags for new DRBG instances. See also #5576. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5632)
-
- 16 3月, 2018 1 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Fixes #4403 This commit moves the internal header file "internal/rand.h" to <openssl/rand_drbg.h>, making the RAND_DRBG API public. The RAND_POOL API remains private, its function prototypes were moved to "internal/rand_int.h" and converted to lowercase. Documentation for the new API is work in progress on GitHub #5461. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5462)
-
- 10 3月, 2018 1 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
The introduction of thread local public and private DRBG instances (#5547) makes it very cumbersome to change the reseeding (time) intervals for those instances. This commit provides a function to set the default values for all subsequently created DRBG instances. int RAND_DRBG_set_reseed_defaults( unsigned int master_reseed_interval, unsigned int slave_reseed_interval, time_t master_reseed_time_interval, time_t slave_reseed_time_interval ); The function is intended only to be used during application initialization, before any threads are created and before any random bytes are generated. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5576)
-
- 07 3月, 2018 1 次提交
-
-
由 Kurt Roeckx 提交于
We currently don't support the algorithm from NIST SP 800-90C 10.1.2 to use a weaker DRBG as source Reviewed-by: NDr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> GH: #5506
-
- 27 2月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 22 2月, 2018 1 次提交
-
-
由 Kurt Roeckx 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NDr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: NPaul Dale <paul.dale@oracle.com> GH: #5400
-
- 15 2月, 2018 1 次提交
-
-
由 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)
-
- 14 2月, 2018 4 次提交
-
-
由 Kurt Roeckx 提交于
getrandom() is now used on Linux by default when using Linux >= 3.17 and glibc >= 2.25 Reviewed-by: NRich Salz <rsalz@openssl.org> GH: #5314
-
由 Dr. Matthias St. Pierre 提交于
The NIST standard presents two alternative ways for seeding the CTR DRBG, depending on whether a derivation function is used or not. In Section 10.2.1 of NIST SP800-90Ar1 the following is assessed: The use of the derivation function is optional if either an approved RBG or an entropy source provides full entropy output when entropy input is requested by the DRBG mechanism. Otherwise, the derivation function shall be used. Since the OpenSSL DRBG supports being reseeded from low entropy random sources (using RAND_POOL), the use of a derivation function is mandatory. For that reason we change the default and replace the opt-in flag RAND_DRBG_FLAG_CTR_USE_DF with an opt-out flag RAND_DRBG_FLAG_CTR_NO_DF. This change simplifies the RAND_DRBG_new() calls. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5294)
-
由 Dr. Matthias St. Pierre 提交于
The functions drbg_setup() and drbg_cleanup() used to duplicate a lot of code from RAND_DRBG_new() and RAND_DRBG_free(). This duplication has been removed, which simplifies drbg_setup() and makes drbg_cleanup() obsolete. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5294)
-
由 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)
-
- 09 2月, 2018 1 次提交
-
-
由 Pauli 提交于
Simplify Posix timer detection. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5279)
-
- 07 2月, 2018 2 次提交
-
-
由 Pauli 提交于
MacOS seems to define __GLIBC__ but not __GLIBC_PREREQ. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5269)
-
由 Pauli 提交于
Remove the timer and TSC additional input code and instead provide a single routine that attempts to use the "best" timer/counter available on the system. It attempts to use TSC, then various OS dependent resources and finally several tries to obtain the date. If any of these timer/counters is successful, the rest are skipped. No randomness is credited for this. Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/5231)
-
- 06 2月, 2018 3 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
The functions RAND_bytes() and RAND_priv_bytes() are now both based on a common implementation using RAND_DRBG_bytes() (if the default OpenSSL rand method is active). This not only simplifies the code but also has the advantage that additional input from a high precision timer is added on every generate call if the timer is available. Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5251)
-
由 Dr. Matthias St. Pierre 提交于
When comparing the implementations of drbg_bytes() and RAND_DRBG_bytes(), it was noticed that the former split the buffer into chunks when calling RAND_DRBG_generate() to circumvent the size limitation of the buffer to outlen <= drb->max_request. This loop was missing in RAND_DRBG_bytes(), so it was adopted from drbg_bytes(). Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5251)
-
由 Dr. Matthias St. Pierre 提交于
This check not only prevented the automatic reinstantiation of the DRBG, which is implemented in RAND_DRBG_generate(), but also prevented an error message from being generated in the case of failure. Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5251)
-
- 01 2月, 2018 2 次提交
-
-
由 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)
-
由 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)
-
- 29 1月, 2018 1 次提交
-
-
由 Kurt Roeckx 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/4752)
-
- 19 1月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/5110)
-
- 16 1月, 2018 1 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Fixes #5076 Since do_rand_drbg_init() allocates three locks, it needs to ensure that OPENSSL_init_crypto() is called, otherwise these resources are not cleaned up properly. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5083)
-
- 09 1月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5038)
-
- 04 1月, 2018 2 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
The DRGB concept described in NIST SP 800-90A provides for having different algorithms to generate random output. In fact, the FIPS object module used to implement three of them, CTR DRBG, HASH DRBG and HMAC DRBG. When the FIPS code was ported to master in #4019, two of the three algorithms were dropped, and together with those the entire code that made RAND_DRBG generic was removed, since only one concrete implementation was left. This commit restores the original generic implementation of the DRBG, making it possible again to add additional implementations using different algorithms (like RAND_DRBG_CHACHA20) in the future. Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4998)
-
由 Dr. Matthias St. Pierre 提交于
The generic part of the FIPS DRBG was implemented in fips_drbg_lib.c and the algorithm specific parts in fips_drbg_<alg>.c for <alg> in {ctr, hash, hmac}. Additionally, there was the module fips_drbg_rand.c which contained 'gluing' code between the RAND_METHOD api and the FIPS DRBG. When the FIPS code was ported to master in #4019, for some reason the ctr-drbg implementation from fips_drbg_ctr.c ended up in drbg_rand.c instead of drbg_ctr.c. This commit renames the module drbg_rand.c back to drbg_ctr.c, thereby restoring a simple relationship between the original fips modules and the drbg modules in master: fips_drbg_lib.c => drbg_lib.c /* generic part of implementation */ fips_drbg_<alg>.c => drbg_<alg>.c /* algorithm specific implementations */ Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4998)
-
- 18 12月, 2017 3 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Previously, the RAND_DRBG_uninstantiate() call was not exactly inverse to RAND_DRBG_instantiate(), because some important member values of the drbg->ctr member where cleared. Now these values are restored internally. Signed-off-by: NDr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/4402)
-
由 Dr. Matthias St. Pierre 提交于
Signed-off-by: NDr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/4402)
-
由 Dr. Matthias St. Pierre 提交于
Every DRBG now supports automatic reseeding not only after a given number of generate requests, but also after a specified time interval. Signed-off-by: NDr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/4402)
-