Copyright year updates


Reviewed-by: Neil Horman <nhorman@openssl.org>
Release: yes

Refactor OpenSSL 'ECDSA' EVP_SIGNATURE to also include ECDSA+hash composites

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-b

Refactor OpenSSL 'ECDSA' EVP_SIGNATURE to also include ECDSA+hash composites

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24992)

show more ...

Refactor OpenSSL 'DSA' EVP_SIGNATURE to also include DSA+hash composites

(in the code, "sigalg" is used to refer to these composite algorithms,
which is a nod to libcrypto and libssl, wh

Refactor OpenSSL 'DSA' EVP_SIGNATURE to also include DSA+hash composites

(in the code, "sigalg" is used to refer to these composite algorithms,
which is a nod to libcrypto and libssl, where that term is commonly used
for composite algorithms)

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24992)

show more ...

Refactor OpenSSL 'EdDSA' EVP_SIGNATURE to allow use with EVP_PKEY functions

Add EVP_PKEY_{sign,verify}_message support for our Ed25519 and Ed448
implementations, including ph and ctx var

Refactor OpenSSL 'EdDSA' EVP_SIGNATURE to allow use with EVP_PKEY functions

Add EVP_PKEY_{sign,verify}_message support for our Ed25519 and Ed448
implementations, including ph and ctx variants.

Tests are added with test_evp stanzas.

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24975)

show more ...

Refactor OpenSSL 'RSA' EVP_SIGNATURE to also include RSA+hash composites

(in the code, "sigalg" is used to refer to these composite algorithms,
which is a nod to libcrypto and libssl, wh

Refactor OpenSSL 'RSA' EVP_SIGNATURE to also include RSA+hash composites

(in the code, "sigalg" is used to refer to these composite algorithms,
which is a nod to libcrypto and libssl, where that term is commonly used
for composite algorithms)

To make this implementation possible, wrappers were added around the hash
function itself, allowing the use of existing hash implementations through
their respective OSSL_DISPATCH tables, but also retaining the dynamic fetch
of hash implementations when the digest_sign / digest_verify functionality
is used. This wrapper allows implementing the RSA+hash composites through
simple initializer function and a custom OSSL_DISPATCH table for each.

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23416)

show more ...

jitter: add a new provider containing a jitter entropy source alone

This entropy source can be used instead of SEED-SRC. Sample
openssl.cnf configuration is provided. It is built as a se

jitter: add a new provider containing a jitter entropy source alone

This entropy source can be used instead of SEED-SRC. Sample
openssl.cnf configuration is provided. It is built as a separate
provider, because it is likely to require less frequent updates than
fips provider. The same build likely can span multiple generations of
FIPS 140 standard revisions.

Note that rand-instances currently chain from public/private instances
to primary, prior to consuming the seed. Thus currently a unique ESV
needs to be obtained, and resue of jitterentropy.a certificate is not
possible as is. Separately a patch will be sent to allow for
unchaining public/private RAND instances for the purpose of reusing
ESV.

Also I do wonder if it makes sense to create a fips variant of stock
SEED-SRC entropy source, which in addition to using getrandom() also
verifies that the kernel is operating in FIPS mode and thus is likely
a validated entropy source. As in on Linux, check that
/proc/sys/crypto/fips_enabled is set to 1, and similar checks on
Windows / MacOS and so on.

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24844)

show more ...

Copyright year updates


Reviewed-by: Richard Levitte <levitte@openssl.org>
Release: yes

Add support for SHA256/192

This is defined in NIST SP 800-208 as the truncation to 192 bits of
SHA256. Unlike other truncated hashes in the SHA2 suite, this variant
doesn't have a di

Add support for SHA256/192

This is defined in NIST SP 800-208 as the truncation to 192 bits of
SHA256. Unlike other truncated hashes in the SHA2 suite, this variant
doesn't have a different initial state, it is just a pure truncation
of the output.

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21180)

show more ...

configure: introduce no-ecx to remove ECX related feature

This can effectively reduce the binary size for platforms
that don't need ECX feature(~100KB).

Signed-off-by: Yi Li <yi

configure: introduce no-ecx to remove ECX related feature

This can effectively reduce the binary size for platforms
that don't need ECX feature(~100KB).

Signed-off-by: Yi Li <yi1.li@intel.com>

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20781)

show more ...

Replaced '{ 0, NULL }' with OSSL_DISPATCH_END in OSSL_DISPATCH arrays

Fixes #20710

Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Replaced '{ 0, NULL }' with OSSL_DISPATCH_END in OSSL_DISPATCH arrays

Fixes #20710

Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20745)

show more ...

providers: add Argon2 KDF

https://datatracker.ietf.org/doc/rfc9106/

Signed-off-by: Čestmír Kalina <ckalina@redhat.com>

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Revie

providers: add Argon2 KDF

https://datatracker.ietf.org/doc/rfc9106/

Signed-off-by: Čestmír Kalina <ckalina@redhat.com>

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12256)

show more ...

Implement deterministic ECDSA sign (RFC6979)

This PR is based off the contributions in PR #9223 by Jemmy1228.

It has been modified and reworked to:
(1) Work with providers
(

Implement deterministic ECDSA sign (RFC6979)

This PR is based off the contributions in PR #9223 by Jemmy1228.

It has been modified and reworked to:
(1) Work with providers
(2) Support ECDSA and DSA
(3) Add a KDF HMAC_DRBG implementation that shares code with the RAND HMAC_DRBG.

A nonce_type is passed around inside the Signing API's, in order to support any
future deterministic algorithms.

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18809)

show more ...

providers: Add SM4 XTS implementation

Signed-off-by: Xu Yizhou <xuyizhou1@huawei.com>

Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>

providers: Add SM4 XTS implementation

Signed-off-by: Xu Yizhou <xuyizhou1@huawei.com>

Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19619)

show more ...

default provider: include RIPEMD160

Including RIPEMD160 in both the default and legacy providers shouldn't break
anyone and makes the algorithm available more readily.

Fixes #17

default provider: include RIPEMD160

Including RIPEMD160 in both the default and legacy providers shouldn't break
anyone and makes the algorithm available more readily.

Fixes #17722

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19375)

show more ...

Add HPKE DHKEM provider support for EC, X25519 and X448.

The code is derived from @sftcd's work in PR #17172.
This PR puts the DHKEM algorithms into the provider layer as
KEM algorit

Add HPKE DHKEM provider support for EC, X25519 and X448.

The code is derived from @sftcd's work in PR #17172.
This PR puts the DHKEM algorithms into the provider layer as
KEM algorithms for EC and ECX.

This PR only implements the DHKEM component of HPKE as specified in
RFC 9180.

crypto/hpke/hpke_util.c has been added for fuctions that will
be shared between DHKEM and HPKE.

API's for EVP_PKEY_auth_encapsulate_init() and EVP_PKEY_auth_decapsulate_init()
have been added to support authenticated encapsulation. auth_init() functions
were chosen rather that a EVP_PKEY_KEM_set_auth() interface to support
future algorithms that could possibly need different init functions.

Internal code has been refactored, so that it can be shared between the DHKEM
and other systems. Since DHKEM operates on low level keys it needs to be
able to do low level ECDH and ECXDH calls without converting the keys
back into EVP_PKEY/EVP_PKEY_CTX form. See ossl_ecx_compute_key(),
ossl_ec_public_from_private()

DHKEM requires API's to derive a key using a seed (IKM). This did not sit
well inside the DHKEM itself as dispatch functions. This functionality
fits better inside the EC and ECX keymanagers keygen, since
they are just variations of keygen where the private key is generated
in a different manner. This should mainly be used for testing purposes.
See ossl_ec_generate_key_dhkem().
It supports this by allowing a settable param to be passed to keygen
(See OSSL_PKEY_PARAM_DHKEM_IKM).
The keygen calls code within ec and ecx dhkem implementation to handle this.
See ossl_ecx_dhkem_derive_private() and ossl_ec_dhkem_derive_private().
These 2 functions are also used by the EC/ECX DHKEM implementations to generate
the sender ephemeral keys.

Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19068)

show more ...

Implement AES-GCM-SIV (RFC8452)

Fixes #16721

This uses AES-ECB to create a counter mode AES-CTR32 (32bit counter, I could
not get AES-CTR to work as-is), and GHASH to implement

Implement AES-GCM-SIV (RFC8452)

Fixes #16721

This uses AES-ECB to create a counter mode AES-CTR32 (32bit counter, I could
not get AES-CTR to work as-is), and GHASH to implement POLYVAL. Optimally,
there would be separate polyval assembly implementation(s), but the only one
I could find (and it was SSE2 x86_64 code) was not Apache 2.0 licensed.

This implementation lives only in the default provider; there is no legacy
implementation.

The code offered in #16721 is not used; that implementation sits on top of
OpenSSL, this one is embedded inside OpenSSL.

Full test vectors from RFC8452 are included, except the 0 length plaintext;
that is not supported; and I'm not sure it's worthwhile to do so.

Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18693)

show more ...

Add null digest implementation to the default provider

This is necessary to keep compatibility with 1.1.1.

Fixes #16660

Reviewed-by: Matt Caswell <matt@openssl.org>
(Me

Add null digest implementation to the default provider

This is necessary to keep compatibility with 1.1.1.

Fixes #16660

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17016)

show more ...

providers: Add SM4 GCM implementation

The GCM mode of the SM4 algorithm is specifieded by RFC8998.

Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>

Reviewed-b

providers: Add SM4 GCM implementation

The GCM mode of the SM4 algorithm is specifieded by RFC8998.

Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>

Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16491)

show more ...

Add default provider support for Keccak 224, 256, 384 and 512

Fixes issue openssl#13033

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>

Add default provider support for Keccak 224, 256, 384 and 512

Fixes issue openssl#13033

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16594)

show more ...

Add support for camellia cbc cts mode

Fixes #16276

Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16286)

provider: add TLS13_KDF to the default and FIPS providers

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lo

provider: add TLS13_KDF to the default and FIPS providers

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/16203)

show more ...

PROV: Add OIDs we know to all provider applicable algorithms

The OIDs were extracted with the help of libcrypto's ASN1 OID database.

While doing this, we move all the names strings

PROV: Add OIDs we know to all provider applicable algorithms

The OIDs were extracted with the help of libcrypto's ASN1 OID database.

While doing this, we move all the names strings to macro definitions,
to avoid duplication and conflicting names declarations. Those macros
are all in providers/implementations/include/prov/names.h

Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14498)

show more ...

APPS: Replace the use of OBJ_nid2ln() with name or description calls

With new provided algorithms added, we'd rather rely on the names and
descriptions that we get from the providers.

APPS: Replace the use of OBJ_nid2ln() with name or description calls

With new provided algorithms added, we'd rather rely on the names and
descriptions that we get from the providers.

Specifically with the 'openssl list' command, we now display the
description of all algorithms. For '-public-key-algorithms', we
additionally print key type information a bit more like we do for
legacy methods.

We also add descriptions to all our keymgmt functions, because the
built in EVP_PKEY_ASN1_METHODs had them.

Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14656)

show more ...

Add ossl_provider symbols

Partial fix for #12964

Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14473)

Fix misc external ossl_ symbols.

Partial fix for #12964

Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14473)