first cut at KEM & key management skeletons

Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.or

first cut at KEM & key management skeletons

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

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 ...

Drop libimplementations.a

libimplementations.a was a nice idea, but had a few flaws:

1. The idea to have common code in libimplementations.a and FIPS
sensitive helper funct

Drop libimplementations.a

libimplementations.a was a nice idea, but had a few flaws:

1. The idea to have common code in libimplementations.a and FIPS
sensitive helper functions in libfips.a / libnonfips.a didn't
catch on, and we saw full implementation ending up in them instead
and not appearing in libimplementations.a at all.

2. Because more or less ALL algorithm implementations were included
in libimplementations.a (the idea being that the appropriate
objects from it would be selected automatically by the linker when
building the shared libraries), it's very hard to find only the
implementation source that should go into the FIPS module, with
the result that the FIPS checksum mechanism include source files
that it shouldn't

To mitigate, we drop libimplementations.a, but retain the idea of
collecting implementations in static libraries. With that, we not
have:

libfips.a

Includes all implementations that should become part of the FIPS
provider.

liblegacy.a

Includes all implementations that should become part of the legacy
provider.

libdefault.a

Includes all implementations that should become part of the
default and base providers.

With this, libnonfips.a becomes irrelevant and is dropped.
libcommon.a is retained to include common provider code that can be
used uniformly by all providers.

Fixes #15157

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

show more ...

Add SM2 private key range validation

According to the relevant standards, the valid range for SM2 private
keys is [1, n-1), where n is the order of the curve generator.

For this

Add SM2 private key range validation

According to the relevant standards, the valid range for SM2 private
keys is [1, n-1), where n is the order of the curve generator.

For this reason we cannot reuse the EC validation function as it is, and
we introduce a new internal function `sm2_key_private_check()`.

Partially fixes https://github.com/openssl/openssl/issues/8435

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

show more ...

Swap to FIPS186-2 DSA generation outside of the FIPS module

Inside the FIPS module we continue to use FIPS186-4. We prefer FIPS186-2
in the default provider for backwards compatibility r

Swap to FIPS186-2 DSA generation outside of the FIPS module

Inside the FIPS module we continue to use FIPS186-4. We prefer FIPS186-2
in the default provider for backwards compatibility reasons.

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

show more ...

Swap to DH_PARAMGEN_TYPE_GENERATOR as the default outside of the FIPS module

The documentation claimed this was already the default but it wasn't. This
was causing the dhparam applicatio

Swap to DH_PARAMGEN_TYPE_GENERATOR as the default outside of the FIPS module

The documentation claimed this was already the default but it wasn't. This
was causing the dhparam application to change behaviour when compared to
1.1.1

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

show more ...

Improve code reuse in the provider MAC bridge

We reuse concepts such as PROV_CIPHER, and make use of some common code
in provider_util.c

Reviewed-by: Paul Dale <paul.dale@oracle

Improve code reuse in the provider MAC bridge

We reuse concepts such as PROV_CIPHER, and make use of some common code
in provider_util.c

Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12637)

show more ...

Implement key management for the EVP_PKEY MAC to EVP_MAC provider bridge

Some MAC implementations were available before the current EVP_MAC API. They
were used via EVP_DigestSign*. There

Implement key management for the EVP_PKEY MAC to EVP_MAC provider bridge

Some MAC implementations were available before the current EVP_MAC API. They
were used via EVP_DigestSign*. There exists a bridge between the old API and
the EVP_MAC API however this bridge itself uses a legacy EVP_PKEY_METHOD.
This commit implements the key management for provider side bridge without
having to useany legacy code.

Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12637)

show more ...

Implement a EVP_PKEY KDF to KDF provider bridge

Some KDF implementations were available before the current EVP_KDF API.
They were used via EVP_PKEY_derive. There exists a bridge between

Implement a EVP_PKEY KDF to KDF provider bridge

Some KDF implementations were available before the current EVP_KDF API.
They were used via EVP_PKEY_derive. There exists a bridge between the old
API and the EVP_KDF API however this bridge itself uses a legacy
EVP_PKEY_METHOD. This commit implements a provider side bridge without
having to use any legacy code.

Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12573)

show more ...

ecx: add key generation support.

Specifically for x25519, x448, ed25519 and ed448.

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

ecx: add key generation support.

Specifically for x25519, x448, ed25519 and ed448.

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

show more ...

Add EVP_PKEY_gettable_params support for accessing EVP_PKEY key data fields

Currently only RSA, EC and ECX are supported (DH and DSA need to be added to the keygen
PR's seperately becaus

Add EVP_PKEY_gettable_params support for accessing EVP_PKEY key data fields

Currently only RSA, EC and ECX are supported (DH and DSA need to be added to the keygen
PR's seperately because the fields supported have changed significantly).

The API's require the keys to be provider based.

Made the keymanagement export and get_params functions share the same code by supplying
support functions that work for both a OSSL_PARAM_BLD as well as a OSSL_PARAM[].
This approach means that complex code is not required to build an
empty OSSL_PARAM[] with the correct sized fields before then doing a second
pass to populate the array.

The RSA factor arrays have been changed to use unique key names to simplify the interface
needed by the user.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11365)

show more ...

[PROV][KMGMT][KEXCH][EC] Implement EC keymgtm and ECDH

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Shane Lontis <shan

[PROV][KMGMT][KEXCH][EC] Implement EC keymgtm and ECDH

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10631)

show more ...

Fix no-ec build

Don't attempt to build ecx related source files in a "no-ec" build.

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.o

Fix no-ec build

Don't attempt to build ecx related source files in a "no-ec" build.

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11065)

show more ...

Implement Provider side Key Management for X25519 and X448

Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from ht

Implement Provider side Key Management for X25519 and X448

Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10964)

show more ...

New RSA keymgmt implementation to handle import / export of RSA keys

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

Providers: move common exchange,kdfs,keymgmt,macs,signature

From providers/common/ to providers/implementations/

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https:

Providers: move common exchange,kdfs,keymgmt,macs,signature

From providers/common/ to providers/implementations/

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

show more ...