- drbg_lib.c: Silence coverity warning: the comment preceding the
RAND_DRBG_instantiate() call explicitely states that the error
is ignored and explains the reason why.
- drbgtest: Add checks for the return values of RAND_bytes() and
RAND_priv_bytes() to run_multi_thread_test().
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5976)
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: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5920)
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: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5876)
Fail harshly (in debug builds) when rand_pool_acquire_entropy isn't
delivering the required amount of entropy. In release builds, this
produces an error with details.
We also take the opportunity to modernise the types used.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5857)
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: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
GH: #5503
The RAND_DRBG API was added in PR #5462 and modified by PR #5547.
This commit adds the corresponding documention.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5461)
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: Matt Caswell <matt@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/4110)
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: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5789)
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: Rich Salz <rsalz@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5737)
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: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5676)
This avoids lock contention.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5547)
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: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
GH: #5402
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5646)
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: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5632)
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: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5462)
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: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5576)
We currently don't support the algorithm from NIST SP 800-90C
10.1.2 to use a weaker DRBG as source
Reviewed-by: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
GH: #5506
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
GH: #5400
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: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5375)
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: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5294)
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: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5294)
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: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5294)
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: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5231)
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: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5251)
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: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5251)
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: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5251)
Conceptually, this is a squashed version of:
Revert "Address feedback"
This reverts commit 75551e07bd.
and
Revert "Add CRYPTO_thread_glock_new"
This reverts commit ed6b2c7938.
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: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5089)
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: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5199)
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: Matt Caswell <matt@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5083)
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: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4998)
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: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4998)
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: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/4402)
