- 23 7月, 2019 2 次提交
-
-
由 Pauli 提交于
The rand pool support allocates maximal sized buffers -- this is typically 12288 bytes in size. These pools are allocated in secure memory which is a scarse resource. They are also allocated per DRBG of which there are up to two per thread. This change allocates 64 byte pools and grows them dynamically if required. 64 is chosen to be sufficiently large so that pools do not normally need to grow. Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/9428) (cherry picked from commit a6a66e4511eec0f4ecc2943117a42b3723eb2222)
-
由 Bernd Edlinger 提交于
The additional data allocates 12K per DRBG instance in the secure memory, which is not necessary. Also nonces are not considered secret. [extended tests] Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9424)
-
- 30 5月, 2019 1 次提交
-
-
由 Pauli 提交于
Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8606) (cherry picked from commit 711a161f03ef9ed7cd149a22bf1203700c103e96)
-
- 28 5月, 2019 1 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9034)
-
- 22 3月, 2019 1 次提交
-
-
由 Pauli 提交于
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/8554) (cherry picked from commit b3d113ed2993801ee643126118ccf6592ad18ef7)
-
- 09 11月, 2018 1 次提交
-
-
由 Bernd Edlinger 提交于
Fixes #7022 Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7588) (cherry picked from commit e2d227bb4a25bb75354a40816439630a8162f073)
-
- 08 11月, 2018 1 次提交
-
-
由 Pauli 提交于
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/7587) (cherry picked from commit ac765685d4b08a48cefffc71c434760045154dad)
-
- 07 11月, 2018 1 次提交
-
-
由 Bernd Edlinger 提交于
... to make the intended use more clear and differentiate it from the data member "adin_pool". Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7575) (cherry picked from commit 31f32abb8eb2a3ebd8500e6e0460b4a6791e5ed7)
-
- 06 11月, 2018 1 次提交
-
-
由 Bernd Edlinger 提交于
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7518)
-
- 29 10月, 2018 1 次提交
-
-
由 Bernd Edlinger 提交于
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7504) (cherry picked from commit f9e43929c46b38667f67e02765fe0f1c0d3061d6)
-
- 27 10月, 2018 1 次提交
-
-
由 Bernd Edlinger 提交于
Fixes #7394 Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7399) (cherry picked from commit a83dc59afa2e0207180d7218efed19b20d48de95)
-
- 26 10月, 2018 1 次提交
-
-
由 Bernd Edlinger 提交于
Reviewed-by: NPaul Yang <yang.yang@baishancloud.com> Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7474) (cherry picked from commit 21311777ad8b8c2f2fb8eb7a4f9618ceae1e043d)
-
- 22 10月, 2018 1 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
This bug was introduced by #7382 which enhanced RAND_add() to accept large buffer sizes. As a consequence, RAND_add() now fails for buffer sizes less than 32 bytes (i.e. less than 256 bits). In addition, rand_drbg_get_entropy() forgets to reset the attached drbg->pool in the case of an error, which leads to the heap corruption. The problem occurred with RAND_load_file(), which reads the file in chunks of 1024 bytes each. If the size of the final chunk is less than 32 bytes, then RAND_add() fails, whence RAND_load_file() fails silently for buffer sizes n = k * 1024 + r with r = 1,...,31. This commit fixes the heap corruption only. The other issues will be addressed in a separate pull request. Thanks to Gisle Vanem for reporting this issue. Fixes #7449 Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7455) (cherry picked from commit 5b4cb385c18a5bb4e118e300f1c746bf7c2a5628)
-
- 17 10月, 2018 1 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
In pull request #4328 the seeding of the DRBG via RAND_add()/RAND_seed() was implemented by buffering the data in a random pool where it is picked up later by the rand_drbg_get_entropy() callback. This buffer was limited to the size of 4096 bytes. When a larger input was added via RAND_add() or RAND_seed() to the DRBG, the reseeding failed, but the error returned by the DRBG was ignored by the two calling functions, which both don't return an error code. As a consequence, the data provided by the application was effectively ignored. This commit fixes the problem by a more efficient implementation which does not copy the data in memory and by raising the buffer the size limit to INT32_MAX (2 gigabytes). This is less than the NIST limit of 2^35 bits but it was chosen intentionally to avoid platform dependent problems like integer sizes and/or signed/unsigned conversion. Additionally, the DRBG is now less permissive on errors: In addition to pushing a message to the openssl error stack, it enters the error state, which forces a reinstantiation on next call. Thanks go to Dr. Falko Strenzke for reporting this issue to the openssl-security mailing list. After internal discussion the issue has been categorized as not being security relevant, because the DRBG reseeds automatically and is fully functional even without additional randomness provided by the application. Fixes #7381 Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7382) (cherry picked from commit 3064b55134434a0b2850f07eff57120f35bb269a)
-
- 22 8月, 2018 1 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Fixes #7022 In pull request #6432 a change was made to keep the handles to the random devices opened in order to avoid reseeding problems for applications in chroot environments. As a consequence, the handles of the random devices were leaked at exit if the random generator was not used by the application. This happened, because the call to RAND_set_rand_method(NULL) in rand_cleanup_int() triggered a call to the call_once function do_rand_init, which opened the random devices via rand_pool_init(). Thanks to GitHub user @bwelling for reporting this issue. Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7023)
-
- 26 7月, 2018 1 次提交
-
-
由 Shane Lontis 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NTim Hudson <tjh@openssl.org> 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/6778)
-
- 27 6月, 2018 1 次提交
-
-
由 Pauli 提交于
This allows operation inside a chroot environment without having the random device present. A new call, RAND_keep_random_devices_open(), has been introduced that can be used to control file descriptor use by the random seed sources. Some seed sources maintain open file descriptors by default, which allows such sources to operate in a chroot(2) jail without the associated device nodes being available. 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/6432)
-
- 11 5月, 2018 1 次提交
-
-
由 Kurt Roeckx 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> GH: #6208
-
- 02 5月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
rand_pool_bytes_needed() was constructed in such a way that the smallest acceptable entropy factor was 1 entropy bits per 8 bits of data. At the same time, we have a DRBG_MINMAX_FACTOR that allows weaker source, as small as 1 bit of entropy per 128 bits of data. The conclusion is that rand_pool_bytes_needed() needs to change to support weaker entropy sources. We therefore change the input of entropy per byte to be an entropy factor instead. This entropy factor expresses how many bits of data it takes (on average) to get 1 bit of entropy. Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/6150)
-
- 01 5月, 2018 1 次提交
-
-
由 Bernd Edlinger 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6124)
-
- 14 4月, 2018 1 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Fixes #5849 In pull request #5503 a fallback was added which adds a random nonce of security_strength/2 bits if no nonce callback is provided. This change raised the entropy requirements form 256 to 384 bit, which can cause problems on some platforms (e.g. VMS, see issue #5849). The requirements for the nonce are given in section 8.6.7 of NIST SP 800-90Ar1: A nonce may be required in the construction of a seed during instantiation in order to provide a security cushion to block certain attacks. The nonce shall be either: a) A value with at least (security_strength/2) bits of entropy, or b) A value that is expected to repeat no more often than a (security_strength/2)-bit random string would be expected to repeat. Each nonce shall be unique to the cryptographic module in which instantiation is performed, but need not be secret. When used, the nonce shall be considered to be a critical security parameter. This commit implements a nonce of type b) in order to lower the entropy requirements during instantiation back to 256 bits. The formulation "shall be unique to the cryptographic module" above implies that the nonce needs to be unique among (with high probability) among all DRBG instances in "space" and "time". We try to achieve this goal by creating a nonce of the following form nonce = app-specific-data || high-resolution-utc-timestamp || counter Where || denotes concatenation. The application specific data can be something like the process or group id of the application. A utc timestamp is used because it increases monotonically, provided the system time is synchronized. This approach may not be perfect yet for a FIPS evaluation, but it should be good enough for the moment. This commit also harmonizes the implementation of the get_nonce() and the get_additional_data() callbacks and moves the platform specific parts from rand_lib.c into rand_unix.c, rand_win.c, and rand_vms.c. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5920)
-
- 10 4月, 2018 1 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5918)
-
- 05 4月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
When these two functions returned zero, it could mean: 1. that an error occured. In their case, the error is an overflow of the pool, i.e. the correct response from the caller would be to stop trying to fill the pool. 2. that there isn't enought entropy acquired yet, i.e. the correct response from the caller would be to try and add more entropy to the pool. Because of this ambiguity, the returned zero turns out to be useless. This change makes the returned value more consistent. 1 means the addition of new entropy was successful, 0 means it wasn't. To know if the pool has been filled enough, the caller will have to call some other function, such as rand_pool_entropy_available(). Fixes #5846 Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/5876)
-
- 02 4月, 2018 1 次提交
-
-
由 Kurt Roeckx 提交于
If a nonce is required and the get_nonce callback is NULL, request 50% more entropy following NIST SP800-90Ar1 section 9.1. Reviewed-by: NDr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> GH: #5503
-
- 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 2 次提交
-
-
由 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
-
- 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)
-
- 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
-
- 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 1 次提交
-
-
由 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 1 次提交
-
-
由 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)
-
- 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)
-
- 18 12月, 2017 1 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
A third shared DRBG is added, the so called master DRBG. Its sole purpose is to reseed the two other shared DRBGs, the public and the private DRBG. The randomness for the master DRBG is either pulled from the os entropy sources, or added by the application using the RAND_add() call. The master DRBG reseeds itself automatically after a given number of generate requests, but can also be reseeded using RAND_seed() or RAND_add(). A reseeding of the master DRBG is automatically propagated to the public and private DRBG. This construction fixes the problem, that up to now the randomness provided by RAND_add() was added only to the public and not to the private DRBG. 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)
-