These functions are generalizations of EVP_PKEY_CTX_str2ctrl() and
EVP_PKEY_CTX_hex2ctrl(). They will parse the value, and then pass the
parsed result and length to a callback that knows exactly how to pass
them on to a main _ctrl function, along with a context structure
pointer.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7393)
We currently implement EVP MAC methods as EVP_PKEY methods. This
change creates a separate EVP API for MACs, to replace the current
EVP_PKEY ones.
A note about this EVP API and how it interfaces with underlying MAC
implementations:
Other EVP APIs pass the EVP API context down to implementations, and
it can be observed that the implementations use the pointer to their
own private data almost exclusively. The EVP_MAC API deviates from
that pattern by passing the pointer to the implementation's private
data directly, and thereby deny the implementations access to the
EVP_MAC context structure. This change is made to provide a clearer
separation between the EVP library itself and the implementations of
its supported algorithm classes.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7393)
Signed-off-by: Antoine Salon <asalon@vmware.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/7345)
Having it as a 'platform' was conceptually wrong from from the
beginning, and makes decoding more complicated than necessary.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7191)
BIO_s_log() is declared for everyone, so should return NULL when not
actually implemented. Also, it had explicit platform limitations in
util/mkdef.pl that didn't correspond to what was actually in code.
While at it, a few other hard coded things that have lost their
relevance were removed.
include/openssl/ocsp.h had a few duplicate declarations.
Reviewed-by: Paul Yang <yang.yang@baishancloud.com>
(Merged from https://github.com/openssl/openssl/pull/7331)
Thus users can use this function to set customized EVP_PKEY_CTX to
EVP_MD_CTX structure.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7113)
CRYPTO_atomic_read was added with intention to read statistics counters,
but readings are effectively indistinguishable from regular load (even
in non-lock-free case). This is because you can get out-dated value in
both cases. CRYPTO_atomic_write was added for symmetry and was never used.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/6883)
Some EC functions exist in *_GFp and *_GF2m forms, in spite of the
implementations between the two curve types being identical. This
commit provides equivalent generic functions with the *_GFp and *_GF2m
forms just calling the generic functions.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6815)
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: Matt Caswell <matt@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/6432)
EVP_PKEY_asn1_set_get_priv_key() and EVP_PKEY_asn1_set_get_pub_key()
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6394)
Only applies to algorithms that support it. Both raw private and public
keys can be obtained for X25519, Ed25519, X448, Ed448. Raw private keys
only can be obtained for HMAC, Poly1305 and SipHash
Fixes#6259
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6394)
OpenSSL 1.1.0 made the X509_LOOKUP_METHOD structure opaque, so
applications that were previously able to define a custom lookup method
are not able to be ported.
This commit adds getters and setters for each of the current fields of
X509_LOOKUP_METHOD, along with getters and setters on several associated
opaque types (such as X509_LOOKUP and X509_OBJECT).
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6152)
In commit 6decf9436f, fourteen public symbols were removed from
util/libcrypto.num on the master branch and the following symbols
renumbered. Unfortunately, the symbols `OCSP_resp_get0_signer` and
`X509_get0_authority_key_id` were not adjusted accordingly on the
OpenSSL_1_1_0-stable branch. This commit fixes the collision by
doing a 'double swap'.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6278)
The GOST engine needs to be loaded before we initialise libssl. Otherwise
the GOST ciphersuites are not enabled. However the SSL conf module must
be loaded before we initialise libcrypto. Otherwise we will fail to read
the SSL config from a config file properly.
Another problem is that an application may make use of both libcrypto and
libssl. If it performs libcrypto stuff first and OPENSSL_init_crypto()
is called and loads a config file it will fail if that config file has
any libssl stuff in it.
This commit separates out the loading of the SSL conf module from the
interpretation of its contents. The loading piece doesn't know anything
about SSL so this can be moved to libcrypto. The interpretation of what it
means remains in libssl. This means we can load the SSL conf data before
libssl is there and interpret it when it later becomes available.
Fixes#5809
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5818)
Without actually using EVP_PKEY_FLAG_AUTOARGLEN
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4793)
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)
Renamed to EVP_PKEY_new_raw_private_key()/EVP_new_raw_public_key() as per
feedback.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5520)
Not all algorithms will support this, since their keys are not a simple
block of data. But many can.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5520)
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)
Add -bind option to s_client application to allow specification of
local address for connection.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5272)
This function makes it easier to retrieve a reference to the
authority key identifier (akid->keyid) inside a certificate.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5271)
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)
It's a convenient complement to OSSL_STORE_ctrl()
Suggested by Norm Green
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5363)
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)
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)
Add a -rsigopt option to the ocsp command that allows signature parameters to be provided for the signing of OCSP responses. The parameters that may be provided to -rsigopt are the same as may be provided to -sigopt in the ca, req, and x509 commands.
This PR also defines a OCSP_basic_sign_ctx() function, which functions in the same way as OCSP_basic_sign(), except that it accepts a EVP_MD_CTX rather than a key and digest. The OCSP_basic_sign_ctx() function is used to implement the -rsigopt option in the ocsp command.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4190)
Support added for these two digests, available only via the EVP interface.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5093)
