Calling the functions rand_pool_add_{additional,nonce}_data()
in crypto/rand/rand_lib.c with no implementation for djgpp/MSDOS
causees unresolved symbols when linking with djgpp.
Reported and fixed by Gisle Vanem
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6421)
If built with no-dso, syscall_random remains "blind" to getentropy.
Since it's possible to detect symbol availability on ELF-based systems
without involving DSO module, bypass it.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/6436)
If built with no-dso, DSO_global_lookup leaves "unsupported" message
in error queue. Since there is a fall-back code, it's unnecessary
distraction.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/6436)
Only Linux and FreeBSD provide getrandom(), but they both also provide
getentropy() since the same version and we already tried to call that.
Reviewed-by: Andy Polyakov <appro@openssl.org>
GH: #6405
This will actually support most OSs, and at least adds support for
Solaris and OSX
Fixes: #6403
Reviewed-by: Andy Polyakov <appro@openssl.org>
GH: #6405
Stop redefining structures that are already defined in system
headers. This also means we can stop setting the pointer size
globally, because the system structures will have the correct pointer
sizes either way. The only exception is passing the right pointer
size to a function.
Stop trying to twist things around with rand(), that's the job of the
DRBG that we feed.
Stop assuming the location of the JPI$_FINALEXC item, look it up
instead.
Signal an exception if the sys$getjpiw call fails (it means the item
list isn't set up right, so works as an assertion, but using VMS
methodology).
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6151)
No need to buildtest on opensslconf.h
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6149)
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: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/6150)
- 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)
