fips: continuous random bit generator tests

For FIPS 140-3 the continuous tests specified in SP 800-90B need to be
included on the output of any entropy source.

They are impleme

fips: continuous random bit generator tests

For FIPS 140-3 the continuous tests specified in SP 800-90B need to be
included on the output of any entropy source.

They are implemented here as a replacement for the primary DRBG in the FIPS
provider. This results in a setup that looks like this:

+-------------+
| |
| Seed Source |
| |
+------+------+
|
|
v
+-------------+
| |
| CRNG Test |
| |
++----------+-+
| |
| |
v v
+--------------+ +--------------+
| | | |
| Public DRBG | | Private DRBG |
| | | |
+--------------+ +--------------+

An additional benefit, that of avoiding DRBG chains, is also gained.
The current standards do not permit the output of one DRBG to be used
as the input for a second (i.e. a chain).

This also leaves open the future possibility of incorporating a seed
source inside the FIPS boundary.

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

show more ...

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

Remove trailing whitespace

Found by running the checkpatch.pl Linux script to enforce coding style.

Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: David von Oheimb

Remove trailing whitespace

Found by running the checkpatch.pl Linux script to enforce coding style.

Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22097)

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

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

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

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

kdf: Add PVK KDF to providers.

Add PIN Verification Key key derevation function to providers.

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

kdf: Add PVK KDF to providers.

Add PIN Verification Key key derevation function to providers.

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

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)

tls/prov: move the TLS 1.3 KDF code to providers

This function needs to be power up tested as part of the FIPS validation and
thus it needs to be inside the provider boundary. This is r

tls/prov: move the TLS 1.3 KDF code to providers

This function needs to be power up tested as part of the FIPS validation and
thus it needs to be inside the provider boundary. This is realised by
introducing a new KDF "TLS13-KDF" which does the required massaging of
parameters but is otherwise functionally equivalent to HKDF.

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

provider: use #define for PBKDF1 algorithm name

This seems to be standard practice so bringing PBKDF1 into line.

Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https:/

provider: use #define for PBKDF1 algorithm name

This seems to be standard practice so bringing PBKDF1 into line.

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

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