To allow re-use of the already reviewed openSSL crypto code for RISC-V in
other projects - like the Linux kernel, add a second license (2-clause BSD)
to the 32+64bit aes implementations using the Zkn extension.
Signed-off-by: Heiko Stuebner <heiko.stuebner@vrull.eu>
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/21018)
To allow re-use of the already reviewed openSSL crypto code for RISC-V in
other projects - like the Linux kernel, add a second license (2-clause BSD)
to the recently added GCM ghash functions.
Signed-off-by: Heiko Stuebner <heiko.stuebner@vrull.eu>
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/20649)
wvalue is always initialized at the beginning of each cycle
and used only within the cycle
Reviewed-by: Matt Caswell <matt@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/21145)
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Anton Arapov <anton@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21131)
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Anton Arapov <anton@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21131)
The asn1parse command now supports three different input formats:
openssl asn1parse -inform PEM|DER|B64
PEM: base64 encoded data enclosed by PEM markers (RFC7462)
DER: der encoded binary data
B64: raw base64 encoded data
The PEM input format is the default format. It is equivalent
to the former `-strictpem` option which is now marked obsolete
and kept for backward compatibility only.
The B64 is equivalent to the former default input format of the
asn1parse command (without `-strictpem`)
Fixes#7317
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7320)
- split OPT_FMT_PEMDER flag into OPT_FMT_PEM and OPT_FMT_DER
- add OPT_FMT_B64 option (`-inform b64`)
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7320)
1. Update manual, add SM4-CBC to CMAC cipher algorithm list.
2. Add test case for SM4-CBC CMAC, add "data length is greater
than 4 block-length" cases for aes-128-cbc, aes-192-cbc,
aes-256-cbc and des-ede3-cbc.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21102)
Concatenation tests are provider version specific, limit them to supporting
versions.
Fixes#21134
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21140)
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21136)
The DEPEND statement, when applied on files generated with GENERATE, may
be used to specify script modules that the template to be generated from
depends on. In short, this sort of depend:
DEPEND[generated]=util/perl/OpenSSL/something.pm
... would generate a perl run that has the inclusion directory
'util/perl/OpenSSL' and 'something' as the module to be loaded. However,
the package name for this module is 'OpenSSL::something', so to load it the
way it's expected, the inclusion directory should be 'util/perl', and the
module to be loaded should be specified as 'OpenSSL/something' (to be
massaged into a proper module name by the build file template).
To allow this, we introduce a file syntax, where a single '|' is used as a
directory separator, to delineate what part should be used as the inclustion
directory, and which part the module name to be loaded should be derived
from:
DEPEND[generated]=util/perl|OpenSSL/something.pm
Fixes#21112
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21117)
ENGINE_pkey_asn1_find_str() does not make any modifications to fields
controlled by the global_engine_lock. The only change made is the struct_ref
field which is controlled separately. Therefore we can afford to only take
a read lock. This also impacts EVP_PKEY_asn1_find_str().
This lock ends up being obtained indirectly from numerous public API
functions including EVP_PKEY_key_gen(), EVP_PKEY_new_raw_public_key_ex(),
EVP_PKEY_copy_parameters() etc. This occurs even if no engines are actually
in use.
Some tests showed this lock being obtained 6 times after a "warmed up"
s_server instance with default configuration processed a handshake from a
default s_client. When processing a resumption handshake from s_client it
was obtained 8 times.
Partially fixes#20286
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20950)
We use atomic primitives to up ref and down the struct_ref field rather
than relying on the global lock for this.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20950)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20866)
OBJ_obj2txt() would translate any size OBJECT IDENTIFIER to canonical
numeric text form. For gigantic sub-identifiers, this would take a very
long time, the time complexity being O(n^2) where n is the size of that
sub-identifier.
To mitigate this, a restriction on the size that OBJ_obj2txt() will
translate to canonical numeric text form is added, based on RFC 2578
(STD 58), which says this:
> 3.5. OBJECT IDENTIFIER values
>
> An OBJECT IDENTIFIER value is an ordered list of non-negative numbers.
> For the SMIv2, each number in the list is referred to as a sub-identifier,
> there are at most 128 sub-identifiers in a value, and each sub-identifier
> has a maximum value of 2^32-1 (4294967295 decimal).
Fixesotc/security#96
Fixes CVE-2023-2650
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
ossl_x509_store_ctx_get_by_subject() was taking a write lock for the
store, but was only (usually) retrieving a value from the stack of
objects. We take a read lock instead.
Partially fixes#20286
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20952)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21107)
deprecated since OpenSSL 3.0
openssl-genrsa is not deprecated however the OpenSSL documentation
states that it is the case from OpenSSL 3.0. This has been fixed in the
documentation, specifically in manpage 1.
Fixes#21055
CLA: trivial
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21059)
The separate file is a Perl script that generates the appropriate define
directives for inclusion in core_names.h. By having this separation it
will be possible to prebuild data structures to give faster access when
looking up parameters by name.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20935)
We refactor ossl_provider_doall_activated() so that we only need to take
a read lock instead of a write lock for the flag_lock. This should improve
performance by avoiding the lock contention. We achieve this by protecting
the activatecnt via atomics rather than via a lock and by avoiding the full
provider activation/deactivation procedure where it is not needed.
Partial fix for #20286
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20927)
Even if a DRBG has locking enabled on it, there are certain parameters
which are still safe to obtain even without a lock. The max_request
value is constant for all our DRBGs. The reseed_counter does not matter
if we get it wrong - so it is safe to avoid the lock. So if all we are
reading are those parameters then we take no lock at all.
Partially fixes#20286
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20970)
Previously the EVP layer would call lock and unlock functions on the
underlying DRBG implementation to say when a lock should be acquired and
released. This gives the DRBG implementation no say as to what kind of
lock should obtained (e.g. read/write) or even whether a lock is actually
needed or not.
In reality we know whether a DRBG is supposed to be in locking mode or
not because the "enable_locking()" function will have been called if
locks should be used. Therefore we re-interpret the lock and unlock
functions as "hints" from the EVP layer which we ignore. Instead we
acquire locks only when we need them. By knowing the context we can obtain
either a read or a write lock as appropriate.
This may mean that in some rare cases we acquire the locks more than once
for a single EVP call, if the EVP call makes several calls to the underlying
DRBG. But in practice almost all EVP calls only make one such call.
EVP_RAND_generate() is an example of a call where multiple DRBG calls may
be made. One of these gets the "max_request" parameter (which is constant
for all of our own DRBGs) and it may make several calls to the DRBG generate
call - but only if the requested size is very large which will rarely be
the case.
Partially fixes#20286
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20970)
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/21086)
