Found by running the checkpatch.pl Linux script to enforce coding style.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21468)
With egd as the rand source the reseed after fork confuses the egd.
Fixes#19396
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19454)
(cherry picked from commit 0b3fec5022)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/18424)
For functions that exist in 1.1.1 provide a simple aliases via #define.
Fixes#15236
Functions with OSSL_DECODER_, OSSL_ENCODER_, OSSL_STORE_LOADER_,
EVP_KEYEXCH_, EVP_KEM_, EVP_ASYM_CIPHER_, EVP_SIGNATURE_,
EVP_KEYMGMT_, EVP_RAND_, EVP_MAC_, EVP_KDF_, EVP_PKEY_,
EVP_MD_, and EVP_CIPHER_ prefixes are renamed.
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15405)
pointers to provider size algorithm contexts.
Fixes#14284
The gettable_ctx_params methods were confusingly passing a 'provctx' and
a provider context which are completely different objects.
Some objects such as EVP_KDF used 'data' while others such as EVP_MD used 'provctx'.
For libcrypto this 'ctx' is an opaque ptr returned when a providers algorithm
implementation creates an internal context using a new_ctx() method.
Hence the new name 'algctx'.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15275)
Change:
EVP_RAND_gettable_ctx_params -> EVP_RAND_CTX_gettable_params
EVP_RAND_settable_ctx_params -> EVP_RAND_CTX_settable_params
Which brings them in line with the other similar functions for other algorithm
types.
Fixes#14880
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14893)
The DRBG known answer tests are performed by evp_test and the old vectors
are not used.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13867)
HPE NonStop Port Changes for 3.0.0 Includes unthreaded, PUT, and SPT for OSS.
The port changes include wrapping where necessary for FLOSS and
appropriate configuration changes to support that. Two tests
are excluded as being inappropriate for the platform.
The changes are:
* Added /usr/local/include to nonstop-nsx_spt_floss to load floss.h
* Added SPT Floss variant for NonStop
* Wrapped FLOSS definitions in OPENSSL_TANDEM_FLOSS to allow selective enablement.
* SPT build configuration for NonStop
* Skip tests not relevant for NonStop
* PUT configuration changes required for NonStop platforms
* Configurations/50-nonstop.conf: updates for TNS/X platform.
* FLOSS instrumentation for HPE NonStop TNS/X and TNS/E platforms.
* Configurations/50-nonstop.conf: modifications for non-PUT TNS/E platform b
* Fix use of DELAY in ssltestlib.c for HPNS.
* Fixed commit merge issues and added floss to http_server.c
CLA: Permission is granted by the author to the OpenSSL team to use these modifications.
Fixes#5087.
Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12800)
Add the AuthEnvelopedData as defined in RFC 5083 with AES-GCM
parameter as defined in RFC 5084.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/8024)
Issue #12377 demonstrated that it is not sufficient to verify that
after a fork a reseeding is triggered in the child. This commit
enhances the test by collecting the output of the public and private
drbg for the parent and all children and checking for duplicates.
In case of duplicates, it prints an error message and displays a
sorted output.
The analysis of #12377 (see [1]) showed that due to an error in the
resetting of the AES-CTR (issue #12405, fixed by #12413), it could
happen that only the first n bytes (n=1,...15) of the children's
random output were identical.
This test is optimized to detect this issue by only comparing the first
byte of the sampled data (i.e., the first 'column' of the output).
The number of samples is chosen high enough to keep the chance of false
positives low. The test is executed sixteen times, each time advancing
the internal counter by requesting a single extra byte of random data.
Another, more general test splits the entire sampled random data into
two-byte chunks and counts their collisions. If a certain threshold
is exceeded, it reports an error.
[1] https://github.com/openssl/openssl/issues/12377#issuecomment-656207334
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12407)
The RAND_DRBG API did not fit well into the new provider concept as
implemented by EVP_RAND and EVP_RAND_CTX. The main reason is that the
RAND_DRBG API is a mixture of 'front end' and 'back end' API calls
and some of its API calls are rather low-level. This holds in particular
for the callback mechanism (RAND_DRBG_set_callbacks()) and the RAND_DRBG
type changing mechanism (RAND_DRBG_set()).
Adding a compatibility layer to continue supporting the RAND_DRBG API as
a legacy API for a regular deprecation period turned out to come at the
price of complicating the new provider API unnecessarily. Since the
RAND_DRBG API exists only since version 1.1.1, it was decided by the OMC
to drop it entirely.
Other related changes:
Use RNG instead of DRBG in EVP_RAND documentation. The documentation was
using DRBG in places where it should have been RNG or CSRNG.
Move the RAND_DRBG(7) documentation to EVP_RAND(7).
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/12509)
It's the generate counter (drbg->reseed_gen_counter), not the
reseed counter which needs to be raised above the reseed_interval.
This mix-up was partially caused by some recent renamings of DRBG
members variables, but that will be dealt with in a separate commit.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11195)
The behaviour of RAND_DRBG_generate() has changed. Previously, it
would fail for requests larger than max_request, now it automatically
splits large input into chunks (which was previously done only
by RAND_DRBG_bytes() before calling RAND_DRBG_generate()).
So this test has not only become obsolete, the fact that it succeeded
unexpectedly also caused a buffer overflow that terminated the test.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11195)
The reseed counter condition was broken since a93ba40, where the
initial value was wrongly changed from one to zero.
Commit 8bf3665 fixed the initialization, but also adjusted the check,
so the problem remained.
This change restores original (OpenSSL-fips-2_0-stable) behavior.
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/11195)
The condition in test_error_checks() was inverted, so it succeeded
as long as error_check() failed. Incidently, error_check() contained
several bugs that assured it always failed, thus giving overall drbg
test success.
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/11195)
The existing wording didn't capture the reality of the default setup, this new
nomenclature attempts to improve the situation.
Reviewed-by: Mark J. Cox <mark@awe.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12366)
This macro is used to determine if certain pieces of code should
become part of the FIPS module or not. The old name was confusing.
Fixes#11538
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11539)
It took me a little while to realize why the test_rand_drbg_reseed test
kept crashing after replacing the RAND_DRBG_{gs}et_ex_data() calls by
RAND_DRBG_{gs}et_callback_data().
The reason was that the ex_data API prohibits modifying the callbacks
or callback data of chained DRBGs and returned an error which was
ignored by the `test_rand_drbg_reseed` test, for good reasons.
The `test_rand_drbg_reseed` test is special in this respect, because
it needs to install callbacks for all DRBGs, in order to intercept
and count the reseeding events.
Since the drbgtest module has access to the internal structures of
the DRBG anyway, the problem could be solved by accessing the members
directly. I added a warning comment in hook_drbg().
[extended tests]
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10950)
Documenting the macros removes 14 undocumented items.
Merged three separate manpages into one.
Rename the DRBG CRYPTO_EX define into RAND_DRBG, but keep the old one
for API compatibility.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10216)
Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
directory. Currently, they have different suffixes like
'*_lcl.h', '*_local.h', or '*_int.h'
This commit changes the different suffixes to '*_local.h' uniformly.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)
Currently, there are two different directories which contain internal
header files of libcrypto which are meant to be shared internally:
While header files in 'include/internal' are intended to be shared
between libcrypto and libssl, the files in 'crypto/include/internal'
are intended to be shared inside libcrypto only.
To make things complicated, the include search path is set up in such
a way that the directive #include "internal/file.h" could refer to
a file in either of these two directoroes. This makes it necessary
in some cases to add a '_int.h' suffix to some files to resolve this
ambiguity:
#include "internal/file.h" # located in 'include/internal'
#include "internal/file_int.h" # located in 'crypto/include/internal'
This commit moves the private crypto headers from
'crypto/include/internal' to 'include/crypto'
As a result, the include directives become unambiguous
#include "internal/file.h" # located in 'include/internal'
#include "crypto/file.h" # located in 'include/crypto'
hence the superfluous '_int.h' suffixes can be stripped.
The files 'store_int.h' and 'store.h' need to be treated specially;
they are joined into a single file.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)
When the new OpenSSL CSPRNG was introduced in version 1.1.1,
it was announced in the release notes that it would be fork-safe,
which the old CSPRNG hadn't been.
The fork-safety was implemented using a fork count, which was
incremented by a pthread_atfork handler. Initially, this handler
was enabled by default. Unfortunately, the default behaviour
had to be changed for other reasons in commit b5319bdbd0, so
the new OpenSSL CSPRNG failed to keep its promise.
This commit restores the fork-safety using a different approach.
It replaces the fork count by a fork id, which coincides with
the process id on UNIX-like operating systems and is zero on other
operating systems. It is used to detect when an automatic reseed
after a fork is necessary.
To prevent a future regression, it also adds a test to verify that
the child reseeds after fork.
CVE-2019-1549
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9832)
CLA: trivial
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/9288)
This is in preparation for moving this code inside the FIPS module.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9039)
The functions RAND_add() and RAND_seed() provide a legacy API which
enables the application to seed the CSPRNG.
But NIST SP-800-90A clearly mandates that entropy *shall not* be provided
by the consuming application, neither for instantiation, nor for reseeding.
The provided random data will be mixed into the DRBG state as additional
data only, and no entropy will accounted for it.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8722)
Digest stored entropy for CRNG test.
Via the FIPS lab, NIST confirmed:
The CMVP had a chance to discuss this inquiry and we agree that
hashing the NDRNG block does meet the spirit and letter of AS09.42.
However, the CMVP did have a few questions: what hash algorithm would
be used in this application? Is it approved? Is it CAVs tested?
SHA256 is being used here and it will be both approved and CAVs tested.
This means that no raw entropy needs to be kept between RNG seedings, preventing
a potential attack vector aganst the randomness source and the DRBG chains.
It also means the block of secure memory allocated for this purpose is no longer
required.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/8790)
Refer to NIST SP 800-90C section 5.4 "Prediction Resistance.l"
This requires the seed sources to be approved as entropy sources, after
which they should be considered live sources as per section 5.3.2 "Live
Entropy Source Availability."
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/8647)
Refer to FIPS 140-2 section 4.9.2 Conditional Tests for details.
The check is fairly simplistic, being for the entropy sources to not feed
the DRBG the same block of seed material twice in a row. Only the first
DRBG in a chain is subject to this check, latter DRBGs are assumed to be
safely seeded via the earlier DRBGs.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8599)
The manual says this in its notes:
... and therefore applications using static linking should also call
OPENSSL_thread_stop() on each thread. ...
Fixes#8171
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/8173)
Commit 5b4cb385c1 (#7382) introduced a bug which had the effect
that RAND_add()/RAND_seed() failed for buffer sizes less than
32 bytes. The reason was that now the added random data was used
exlusively as entropy source for reseeding. When the random input
was too short or contained not enough entropy, the DRBG failed
without querying the available entropy sources.
This commit makes drbg_add() act smarter: it checks the entropy
requirements explicitely. If the random input fails this check,
it won't be added as entropy input, but only as additional data.
More precisely, the behaviour depends on whether an os entropy
source was configured (which is the default on most os):
- If an os entropy source is avaible then we declare the buffer
content as additional data by setting randomness to zero and
trigger a regular reseeding.
- If no os entropy source is available, a reseeding will fail
inevitably. So drbg_add() uses a trick to mix the buffer contents
into the DRBG state without forcing a reseeding: it generates a
dummy random byte, using the buffer content as additional data.
Related-to: #7449
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7456)
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: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7382)
In drbgtest, test_set_defaults changes the default DRBGs. This works fine
when tests are run in the normal order. However if
OPENSSL_TEST_RAND_ORDER is defined then it may fail (dependent on the
ordering). This environment variable is defined for one of the Travis
tests, so this issue was causing intermittent travis test failures.
[extended tests]
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7338)
