title: EVP_RAND(7ossl)

summary: the random bit generator

text:
# EVP_RAND(7ossl)

## NAME
EVP_RAND - the random bit generator

## SYNOPSIS

```
 #include <openssl/evp.h>
 #include <rand.h>
```

## DESCRIPTION
The default OpenSSL RAND method is based on the EVP_RAND classes to provide non-deterministic inputs to other cryptographic algorithms.

While the RAND API is the 'frontend' which is intended to be used by application developers for obtaining random bytes, the EVP_RAND API serves as the 'backend', connecting the former with the operating systems's entropy sources and providing access to deterministic random bit generators (DRBG) and their configuration parameters. A DRBG is a certain type of cryptographically-secure pseudo-random number generator (CSPRNG), which is described in [NIST SP 800-90A Rev. 1].

### Disclaimer
Unless you have very specific requirements for your random generator, it is in general not necessary to utilize the EVP_RAND API directly. The usual way to obtain random bytes is to use RAND_bytes(3) or RAND_priv_bytes(3), see also RAND(7).

### Typical Use Cases
Typical examples for such special use cases are the following:

- You want to use your own private DRBG instances. Multiple DRBG instances which are accessed only by a single thread provide additional security (because their internal states are independent) and better scalability in multithreaded applications (because they don't need to be locked).

- You need to integrate a previously unsupported entropy source. Refer to provider-rand(7) for the implementation details to support adding randomness sources to EVP_RAND.

- You need to change the default settings of the standard OpenSSL RAND implementation to meet specific requirements.

## EVP_RAND CHAINING
An EVP_RAND instance can be used as the entropy source of another EVP_RAND instance, provided it has itself access to a valid entropy source. The EVP_RAND instance which acts as entropy source is called the parent, the other instance the child. Typically, the child will be a DRBG because it does not make sense for the child to be an entropy source.

This is called chaining. A chained EVP_RAND instance is created by passing a pointer to the parent EVP_RAND_CTX as argument to the EVP_RAND_CTX_new() call. It is possible to create chains of more than two DRBG in a row. It is also possible to use any EVP_RAND_CTX class as the parent, however, only a live entropy source may ignore and not use its parent.

## THE THREE SHARED DRBG INSTANCES
Currently, there are three shared DRBG instances, the <primary>, <public>, and <private> DRBG. While the <primary> DRBG is a single global instance, the <public> and <private> DRBG are created per thread and accessed through thread-local storage.

By default, the functions RAND_bytes(3) and RAND_priv_bytes(3) use the thread-local <public> and <private> DRBG instance, respectively.

### The <primary> DRBG instance
The <primary> DRBG is not used directly by the application, only for reseeding the two other two DRBG instances. It reseeds itself by obtaining randomness either from os entropy sources or by consuming randomness which was added previously by RAND_add(3).

### The <public> DRBG instance
This instance is used per default by RAND_bytes(3).

### The <private> DRBG instance
This instance is used per default by RAND_priv_bytes(3)

## LOCKING
The <primary> DRBG is intended to be accessed concurrently for reseeding by its child DRBG instances. The necessary locking is done internally. It is not thread-safe to access the <primary> DRBG directly via the EVP_RAND interface. The <public> and <private> DRBG are thread-local, i.e. there is an instance of each per thread. So they can safely be accessed without locking via the EVP_RAND interface.

Pointers to these DRBG instances can be obtained using RAND_get0_primary(), RAND_get0_public() and RAND_get0_private(), respectively. Note that it is not allowed to store a pointer to one of the thread-local DRBG instances in a variable or other memory location where it will be accessed and used by multiple threads.

All other DRBG instances created by an application don't support locking, because they are intended to be used by a single thread. Instead of accessing a single DRBG instance concurrently from different threads, it is recommended to instantiate a separate DRBG instance per thread. Using the <primary> DRBG as entropy source for multiple DRBG instances on different threads is thread-safe, because the DRBG instance will lock the <primary> DRBG automatically for obtaining random input.

## THE OVERALL PICTURE
The following picture gives an overview over how the DRBG instances work together and are being used.

```
               +--------------------+
               | os entropy sources |
               +--------------------+
                        |
                        v           +-----------------------------+
     RAND_add() ==> <primary>     <-| shared DRBG (with locking)  |
                      /   \         +-----------------------------+
                     /     \              +---------------------------+
              <public>     <private>   <- | per-thread DRBG instances |
                 |             |          +---------------------------+
                 v             v
               RAND_bytes()   RAND_priv_bytes()
                    |               ^
                    |               |
    +------------------+      +------------------------------------+
    | general purpose  |      | used for secrets like session keys |
    | random generator |      | and private keys for certificates  |
    +------------------+      +------------------------------------+
```

The usual way to obtain random bytes is to call RAND_bytes(...) or RAND_priv_bytes(...). These calls are roughly equivalent to calling EVP_RAND_generate(<public>, ...) and EVP_RAND_generate(<private>, ...), respectively.

## RESEEDING
A DRBG instance seeds itself automatically, pulling random input from its entropy source. The entropy source can be either a trusted operating system entropy source, or another DRBG with access to such a source.

Automatic reseeding occurs after a predefined number of generate requests. The selection of the trusted entropy sources is configured at build time using the --with-rand-seed option. The following sections explain the reseeding process in more detail.

### Automatic Reseeding
Before satisfying a generate request (EVP_RAND_generate(3)), the DRBG reseeds itself automatically, if one of the following conditions holds:

- the DRBG was not instantiated (=seeded) yet or has been uninstantiated.

- the number of generate requests since the last reseeding exceeds a certain threshold, the so called reseed_interval. This behaviour can be disabled by setting the reseed_interval to 0.

- the time elapsed since the last reseeding exceeds a certain time interval, the so called reseed_time_interval. This can be disabled by setting the reseed_time_interval to 0.

- the DRBG is in an error state.

Note: An error state is entered if the entropy source fails while the DRBG is seeding or reseeding. The last case ensures that the DRBG automatically recovers from the error as soon as the entropy source is available again.

### Manual Reseeding
In addition to automatic reseeding, the caller can request an immediate reseeding of the DRBG with fresh entropy by setting the prediction resistance parameter to 1 when calling EVP_RAND_generate(3).

The document [NIST SP 800-90C] describes prediction resistance requests in detail and imposes strict conditions on the entropy sources that are approved for providing prediction resistance. A request for prediction resistance can only be satisfied by pulling fresh entropy from a live entropy source (section 5.5.2 of [NIST SP 800-90C]). It is up to the user to ensure that a live entropy source is configured and is being used.

For the three shared DRBGs (and only for these) there is another way to reseed them manually: If RAND_add(3) is called with a positive randomness argument (or RAND_seed(3)), then this will immediately reseed the <primary> DRBG. The <public> and <private> DRBG will detect this on their next generate call and reseed, pulling randomness from <primary>.

The last feature has been added to support the common practice used with previous OpenSSL versions to call RAND_add() before calling RAND_bytes().

### Entropy Input and Additional Data
The DRBG distinguishes two different types of random input: entropy, which comes from a trusted source, and additional input', which can optionally be added by the user and is considered untrusted. It is possible to add additional input not only during reseeding, but also for every generate request.

### Configuring the Random Seed Source
In most cases OpenSSL will automatically choose a suitable seed source for automatically seeding and reseeding its <primary> DRBG. The default seed source can be configured when OpenSSL is compiled by setting -DOPENSSL_DEFAULT_SEED_SRC=SEED-SRC. If not set then "SEED-SRC" is used. One can specify a third-party provider seed-source, or -DOPENSSL_DEFAULT_SEED_SRC=JITTER if available.

In some cases however, it will be necessary to explicitly specify a seed source used by "SEED-SRC" during configuration, using the --with-rand-seed option. For more information, see the INSTALL instructions. There are also operating systems where no seed source is available and automatic reseeding is disabled by default.

The following two sections describe the reseeding process of the primary DRBG, depending on whether automatic reseeding is available or not.

### Reseeding the primary DRBG with automatic seeding enabled
Calling RAND_poll() or RAND_add() is not necessary, because the DRBG pulls the necessary entropy from its source automatically. However, both calls are permitted, and do reseed the RNG.

RAND_add() can be used to add both kinds of random input, depending on the value of the randomness argument:

randomness == 0:

The random bytes are mixed as additional input into the current state of the DRBG. Mixing in additional input is not considered a full reseeding, hence the reseed counter is not reset.

randomness > 0:

The random bytes are used as entropy input for a full reseeding (resp. reinstantiation) if the DRBG is instantiated (resp. uninstantiated or in an error state). The number of random bits required for reseeding is determined by the security strength of the DRBG. Currently it defaults to 256 bits (32 bytes). It is possible to provide less randomness than required. In this case the missing randomness will be obtained by pulling random input from the trusted entropy sources.

NOTE: Manual reseeding is *not allowed* in FIPS mode, because [NIST SP-800-90Ar1] mandates that entropy *shall not* be provided by the consuming application for instantiation (Section 9.1) or reseeding (Section 9.2). For that reason, the randomness argument is ignored and the random bytes provided by the RAND_add(3) and RAND_seed(3) calls are treated as additional data.

### Reseeding the primary DRBG with automatic seeding disabled
Calling RAND_poll() will always fail.

RAND_add() needs to be called for initial seeding and periodic reseeding. At least 48 bytes (384 bits) of randomness have to be provided, otherwise the (re-)seeding of the DRBG will fail. This corresponds to one and a half times the security strength of the DRBG. The extra half is used for the nonce during instantiation.

More precisely, the number of bytes needed for seeding depend on the security strength of the DRBG, which is set to 256 by default.

## SEE ALSO
RAND(7), EVP_RAND(3)

## HISTORY
This functionality was added in OpenSSL 3.0.

## COPYRIGHT
Copyright 2017-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


package: openssl

title: EVP_RAND-CRNG-TEST(7ossl)

summary: The FIPS health testing EVP_RAND filter

text:
# EVP_RAND-CRNG-TEST(7ossl)

## NAME
EVP_RAND-CRNG-TEST - The FIPS health testing EVP_RAND filter

## DESCRIPTION
This EVP_RAND object acts as a filter between the entropy source and its users. It performs CRNG health tests as defined in SP 800-90B <https://csrc.nist.gov/pubs/sp/800/90/b/final> Section 4 "Health Tests". Most requests are forwarded to the entropy source, either via its parent reference or via the provider entropy upcalls.

### Identity
"CRNG-TEST" is the name for this implementation; it can be used with the EVP_RAND_fetch() function.

### Supported parameters
If a parent EVP_RAND is specified on context creation, the parent's parameters are supported because the request is forwarded to the parent seed source for processing.

If no parent EVP_RAND is specified on context creation, the following parameters are supported:

"state" (OSSL_RAND_PARAM_STATE) <integer>

"strength" (OSSL_RAND_PARAM_STRENGTH) <unsigned integer>

"max_request" (OSSL_RAND_PARAM_MAX_REQUEST) <unsigned integer>

These parameters work as described in "PARAMETERS" in EVP_RAND(3).

"fips-indicator" (OSSL_DRBG_PARAM_FIPS_APPROVED_INDICATOR) <integer>

This parameter works as described in "PARAMETERS" in provider-rand(7).

## NOTES
This EVP_RAND is only implemented by the OpenSSL FIPS provider.

A context for a health test filter can be obtained by calling:

```
 EVP_RAND *parent = ...;
 EVP_RAND *rand = EVP_RAND_fetch(NULL, "CRNG-TEST", NULL);
 EVP_RAND_CTX *rctx = EVP_RAND_CTX_new(rand, parent);
```

## SEE ALSO
EVP_RAND(3), OSSL_PROVIDER-FIPS(7)

## HISTORY
This functionality was added in OpenSSL 3.4.

## COPYRIGHT
Copyright 2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

branch: sisyphus


title: EVP_RAND-CTR-DRBG(7ossl)

summary: The CTR DRBG EVP_RAND implementation

text:
# EVP_RAND-CTR-DRBG(7ossl)

## NAME
EVP_RAND-CTR-DRBG - The CTR DRBG EVP_RAND implementation

## DESCRIPTION
Support for the counter deterministic random bit generator through the EVP_RAND API.

### Identity
"CTR-DRBG" is the name for this implementation; it can be used with the EVP_RAND_fetch() function.

### Supported parameters
The supported parameters are:

"state" (OSSL_RAND_PARAM_STATE) <integer>

"strength" (OSSL_RAND_PARAM_STRENGTH) <unsigned integer>

"max_request" (OSSL_RAND_PARAM_MAX_REQUEST) <unsigned integer>

"reseed_requests" (OSSL_DRBG_PARAM_RESEED_REQUESTS) <unsigned integer>

"reseed_time_interval" (OSSL_DRBG_PARAM_RESEED_TIME_INTERVAL) <integer>

"min_entropylen" (OSSL_DRBG_PARAM_MIN_ENTROPYLEN) <unsigned integer>

"max_entropylen" (OSSL_DRBG_PARAM_MAX_ENTROPYLEN) <unsigned integer>

"min_noncelen" (OSSL_DRBG_PARAM_MIN_NONCELEN) <unsigned integer>

"max_noncelen" (OSSL_DRBG_PARAM_MAX_NONCELEN) <unsigned integer>

"max_perslen" (OSSL_DRBG_PARAM_MAX_PERSLEN) <unsigned integer>

"max_adinlen" (OSSL_DRBG_PARAM_MAX_ADINLEN) <unsigned integer>

"reseed_counter" (OSSL_DRBG_PARAM_RESEED_COUNTER) <unsigned integer>

"properties" (OSSL_DRBG_PARAM_PROPERTIES) <UTF8 string>

"cipher" (OSSL_DRBG_PARAM_CIPHER) <UTF8 string>

These parameters work as described in "PARAMETERS" in EVP_RAND(3).

"use_derivation_function" (OSSL_DRBG_PARAM_USE_DF) <integer>

This Boolean indicates if a derivation function should be used or not. A nonzero value (the default) uses the derivation function. A zero value does not.

## NOTES
A context for CTR DRBG can be obtained by calling:

```
 EVP_RAND *rand = EVP_RAND_fetch(NULL, "CTR-DRBG", NULL);
 EVP_RAND_CTX *rctx = EVP_RAND_CTX_new(rand, NULL);
```

The default CTR-DRBG implementation attempts to fetch the required internal algorithms from the provider they are built into (eg the default provider) regardless of the properties provided. Should the provider not implement the required algorithms then properties will be used to find a different implementation.

## EXAMPLES

```
 EVP_RAND *rand;
 EVP_RAND_CTX *rctx;
 unsigned char bytes[100];
 OSSL_PARAM params[2], *p = params;
 unsigned int strength = 128;
 rand = EVP_RAND_fetch(NULL, "CTR-DRBG", NULL);
 rctx = EVP_RAND_CTX_new(rand, NULL);
 EVP_RAND_free(rand);
 *p++ = OSSL_PARAM_construct_utf8_string(OSSL_DRBG_PARAM_CIPHER,
                                         SN_aes_256_ctr, 0);
 *p = OSSL_PARAM_construct_end();
 EVP_RAND_instantiate(rctx, strength, 0, NULL, 0, params);
 EVP_RAND_generate(rctx, bytes, sizeof(bytes), strength, 0, NULL, 0);
 EVP_RAND_CTX_free(rctx);
```

## CONFORMING TO
NIST SP 800-90A and SP 800-90B

## SEE ALSO
EVP_RAND(3), "PARAMETERS" in EVP_RAND(3)

## COPYRIGHT
Copyright 2020-2025 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: EVP_RAND-HASH-DRBG(7ossl)

summary: The HASH DRBG EVP_RAND implementation

text:
# EVP_RAND-HASH-DRBG(7ossl)

## NAME
EVP_RAND-HASH-DRBG - The HASH DRBG EVP_RAND implementation

## DESCRIPTION
Support for the hash deterministic random bit generator through the EVP_RAND API.

### Identity
"HASH-DRBG" is the name for this implementation; it can be used with the EVP_RAND_fetch() function.

### Supported parameters
The supported parameters are:

"state" (OSSL_RAND_PARAM_STATE) <integer>

"strength" (OSSL_RAND_PARAM_STRENGTH) <unsigned integer>

"max_request" (OSSL_RAND_PARAM_MAX_REQUEST) <unsigned integer>

"reseed_requests" (OSSL_DRBG_PARAM_RESEED_REQUESTS) <unsigned integer>

"reseed_time_interval" (OSSL_DRBG_PARAM_RESEED_TIME_INTERVAL) <integer>

"min_entropylen" (OSSL_DRBG_PARAM_MIN_ENTROPYLEN) <unsigned integer>

"max_entropylen" (OSSL_DRBG_PARAM_MAX_ENTROPYLEN) <unsigned integer>

"min_noncelen" (OSSL_DRBG_PARAM_MIN_NONCELEN) <unsigned integer>

"max_noncelen" (OSSL_DRBG_PARAM_MAX_NONCELEN) <unsigned integer>

"max_perslen" (OSSL_DRBG_PARAM_MAX_PERSLEN) <unsigned integer>

"max_adinlen" (OSSL_DRBG_PARAM_MAX_ADINLEN) <unsigned integer>

"reseed_counter" (OSSL_DRBG_PARAM_RESEED_COUNTER) <unsigned integer>

"properties" (OSSL_DRBG_PARAM_PROPERTIES) <UTF8 string>

"digest" (OSSL_DRBG_PARAM_DIGEST) <UTF8 string>

These parameters work as described in "PARAMETERS" in EVP_RAND(3).

"fips-indicator" (OSSL_DRBG_PARAM_FIPS_APPROVED_INDICATOR) <integer>

"digest-check" (OSSL_DRBG_PARAM_FIPS_DIGEST_CHECK) <integer>

These parameters work as described in "PARAMETERS" in provider-rand(7).

## NOTES
When the FIPS provider is installed using the -no_drbg_truncated_digests option to fipsinstall, only these digests are permitted (as per FIPS 140-3 IG D.R <https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf>):

The default HASH-DRBG implementation attempts to fetch the required internal algorithms from the provider they are built into (eg the default provider) regardless of the properties provided. Should the provider not implement the required algorithms then properties will be used to find a different implementation.

SHA-1

SHA2-256

SHA2-512

SHA3-256

SHA3-512

A context for HASH DRBG can be obtained by calling:

```
 EVP_RAND *rand = EVP_RAND_fetch(NULL, "HASH-DRBG", NULL);
 EVP_RAND_CTX *rctx = EVP_RAND_CTX_new(rand, NULL);
```

## EXAMPLES

```
 EVP_RAND *rand;
 EVP_RAND_CTX *rctx;
 unsigned char bytes[100];
 OSSL_PARAM params[2], *p = params;
 unsigned int strength = 128;
 rand = EVP_RAND_fetch(NULL, "HASH-DRBG", NULL);
 rctx = EVP_RAND_CTX_new(rand, NULL);
 EVP_RAND_free(rand);
 *p++ = OSSL_PARAM_construct_utf8_string(OSSL_DRBG_PARAM_DIGEST, SN_sha512, 0);
 *p = OSSL_PARAM_construct_end();
 EVP_RAND_instantiate(rctx, strength, 0, NULL, 0, params);
 EVP_RAND_generate(rctx, bytes, sizeof(bytes), strength, 0, NULL, 0);
 EVP_RAND_CTX_free(rctx);
```

## CONFORMING TO
NIST SP 800-90A and SP 800-90B

## SEE ALSO
EVP_RAND(3), "PARAMETERS" in EVP_RAND(3), openssl-fipsinstall(1)

## HISTORY
OpenSSL 3.1.1 introduced the -no_drbg_truncated_digests option to fipsinstall which restricts the permitted digests when using the FIPS provider in a complaint manner. For details refer to FIPS 140-3 IG D.R <https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf>.

## COPYRIGHT
Copyright 2020-2025 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: EVP_RAND-HMAC-DRBG(7ossl)

summary: The HMAC DRBG EVP_RAND implementation

text:
# EVP_RAND-HMAC-DRBG(7ossl)

## NAME
EVP_RAND-HMAC-DRBG - The HMAC DRBG EVP_RAND implementation

## DESCRIPTION
Support for the HMAC deterministic random bit generator through the EVP_RAND API.

### Identity
"HMAC-DRBG" is the name for this implementation; it can be used with the EVP_RAND_fetch() function.

### Supported parameters
The supported parameters are:

"state" (OSSL_RAND_PARAM_STATE) <integer>

"strength" (OSSL_RAND_PARAM_STRENGTH) <unsigned integer>

"max_request" (OSSL_RAND_PARAM_MAX_REQUEST) <unsigned integer>

"reseed_requests" (OSSL_DRBG_PARAM_RESEED_REQUESTS) <unsigned integer>

"reseed_time_interval" (OSSL_DRBG_PARAM_RESEED_TIME_INTERVAL) <integer>

"min_entropylen" (OSSL_DRBG_PARAM_MIN_ENTROPYLEN) <unsigned integer>

"max_entropylen" (OSSL_DRBG_PARAM_MAX_ENTROPYLEN) <unsigned integer>

"min_noncelen" (OSSL_DRBG_PARAM_MIN_NONCELEN) <unsigned integer>

"max_noncelen" (OSSL_DRBG_PARAM_MAX_NONCELEN) <unsigned integer>

"max_perslen" (OSSL_DRBG_PARAM_MAX_PERSLEN) <unsigned integer>

"max_adinlen" (OSSL_DRBG_PARAM_MAX_ADINLEN) <unsigned integer>

"reseed_counter" (OSSL_DRBG_PARAM_RESEED_COUNTER) <unsigned integer>

"properties" (OSSL_DRBG_PARAM_PROPERTIES) <UTF8 string>

"mac" (OSSL_DRBG_PARAM_MAC) <UTF8 string>

"digest" (OSSL_DRBG_PARAM_DIGEST) <UTF8 string>

These parameters work as described in "PARAMETERS" in EVP_RAND(3).

"fips-indicator" (OSSL_DRBG_PARAM_FIPS_APPROVED_INDICATOR) <integer>

"digest-check" (OSSL_DRBG_PARAM_FIPS_DIGEST_CHECK) <integer>

These parameters work as described in "PARAMETERS" in provider-rand(7).

## NOTES
When using the FIPS provider, only these digests are permitted (as per FIPS 140-3 IG D.R <https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf>):

The default HMAC-DRBG implementation attempts to fetch the required internal algorithms from the provider they are built into (eg the default provider) regardless of the properties provided. Should the provider not implement the required algorithms then properties will be used to find a different implementation.

SHA-1

SHA2-256

SHA2-512

SHA3-256

SHA3-512

A context for HMAC DRBG can be obtained by calling:

```
 EVP_RAND *rand = EVP_RAND_fetch(NULL, "HMAC-DRBG", NULL);
 EVP_RAND_CTX *rctx = EVP_RAND_CTX_new(rand, NULL);
```

## EXAMPLES

```
 EVP_RAND *rand;
 EVP_RAND_CTX *rctx;
 unsigned char bytes[100];
 OSSL_PARAM params[3], *p = params;
 unsigned int strength = 128;
 rand = EVP_RAND_fetch(NULL, "HMAC-DRBG", NULL);
 rctx = EVP_RAND_CTX_new(rand, NULL);
 EVP_RAND_free(rand);
 *p++ = OSSL_PARAM_construct_utf8_string(OSSL_DRBG_PARAM_MAC, SN_hmac, 0);
 *p++ = OSSL_PARAM_construct_utf8_string(OSSL_DRBG_PARAM_DIGEST, SN_sha256, 0);
 *p = OSSL_PARAM_construct_end();
 EVP_RAND_instantiate(rctx, strength, 0, NULL, 0, params);
 EVP_RAND_generate(rctx, bytes, sizeof(bytes), strength, 0, NULL, 0);
 EVP_RAND_CTX_free(rctx);
```

## CONFORMING TO
NIST SP 800-90A and SP 800-90B

## SEE ALSO
EVP_RAND(3), "PARAMETERS" in EVP_RAND(3), openssl-fipsinstall(1)

## HISTORY
OpenSSL 3.1.1 introduced the -no_drbg_truncated_digests option to fipsinstall which restricts the permitted digests when using the FIPS provider in a complaint manner. For details refer to FIPS 140-3 IG D.R <https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf>).

## COPYRIGHT
Copyright 2020-2025 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: EVP_RAND-JITTER(7ossl)

text:
# EVP_RAND-JITTER(7ossl)

## NAME
EVP_RAND-JITTER - The randomness seed source EVP_RAND implementation

## DESCRIPTION
Support for deterministic random number generator seeding through the EVP_RAND API.

This software seed source produces randomness based on tiny CPU "jitter" fluctuations.

It is available when OpenSSL is compiled with enable-jitter option. When available it is listed in openssl list -random-generators and openssl info -seeds.

### Identity
"JITTER" is the name for this implementation; it can be used with the EVP_RAND_fetch() function.

### Supported parameters
The supported parameters are:

"state" (OSSL_RAND_PARAM_STATE) <integer>

"strength" (OSSL_RAND_PARAM_STRENGTH) <unsigned integer>

"max_request" (OSSL_RAND_PARAM_MAX_REQUEST) <unsigned integer>

These parameters work as described in "PARAMETERS" in EVP_RAND(3).

## NOTES
A context for the seed source can be obtained by calling:

```
 EVP_RAND *rand = EVP_RAND_fetch(NULL, "JITTER", NULL);
 EVP_RAND_CTX *rctx = EVP_RAND_CTX_new(rand, NULL);
```

The enable-jitter option was added in OpenSSL 3.4.

By specifying the enable-fips-jitter configuration option, the FIPS provider will use an internal jitter source for its entropy. Enabling this option will cause the FIPS provider to operate in a non-compliant mode unless an entropy assessment ESV <https://csrc.nist.gov/Projects/cryptographic-module-validation-program/entropy-validations> and validation through the CMVP <https://csrc.nist.gov/projects/cryptographic-module-validation-program> are additionally conducted. This option was added in OpenSSL 3.5.

## EXAMPLES

```
 EVP_RAND *rand;
 EVP_RAND_CTX *seed, *rctx;
 unsigned char bytes[100];
 OSSL_PARAM params[2], *p = params;
 unsigned int strength = 128;
 /* Create and instantiate a seed source */
 rand = EVP_RAND_fetch(NULL, "JITTER", NULL);
 seed = EVP_RAND_CTX_new(rand, NULL);
 EVP_RAND_instantiate(seed, strength, 0, NULL, 0, NULL);
 EVP_RAND_free(rand);
 /* Feed this into a DRBG */
 rand = EVP_RAND_fetch(NULL, "CTR-DRBG", NULL);
 rctx = EVP_RAND_CTX_new(rand, seed);
 EVP_RAND_free(rand);
 /* Configure the DRBG */
 *p++ = OSSL_PARAM_construct_utf8_string(OSSL_DRBG_PARAM_CIPHER,
                                         SN_aes_256_ctr, 0);
 *p = OSSL_PARAM_construct_end();
 EVP_RAND_instantiate(rctx, strength, 0, NULL, 0, params);
 EVP_RAND_generate(rctx, bytes, sizeof(bytes), strength, 0, NULL, 0);
 EVP_RAND_CTX_free(rctx);
 EVP_RAND_CTX_free(seed);
```

## SEE ALSO
EVP_RAND(3), "PARAMETERS" in EVP_RAND(3)

## COPYRIGHT
Copyright 2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: EVP_RAND-SEED-SRC(7ossl)

text:
# EVP_RAND-SEED-SRC(7ossl)

## NAME
EVP_RAND-SEED-SRC - The randomness seed source EVP_RAND implementation

## DESCRIPTION
Support for deterministic random number generator seeding through the EVP_RAND API.

The seed sources used are specified at the time OpenSSL is configured for building using the --with-rand-seed= option. By default, operating system randomness sources are used.

### Identity
"SEED-SRC" is the name for this implementation; it can be used with the EVP_RAND_fetch() function.

### Supported parameters
The supported parameters are:

"state" (OSSL_RAND_PARAM_STATE) <integer>

"strength" (OSSL_RAND_PARAM_STRENGTH) <unsigned integer>

"max_request" (OSSL_RAND_PARAM_MAX_REQUEST) <unsigned integer>

These parameters work as described in "PARAMETERS" in EVP_RAND(3).

## NOTES
A context for the seed source can be obtained by calling:

```
 EVP_RAND *rand = EVP_RAND_fetch(NULL, "SEED-SRC", NULL);
 EVP_RAND_CTX *rctx = EVP_RAND_CTX_new(rand, NULL);
```

## EXAMPLES

```
 EVP_RAND *rand;
 EVP_RAND_CTX *seed, *rctx;
 unsigned char bytes[100];
 OSSL_PARAM params[2], *p = params;
 unsigned int strength = 128;
 /* Create and instantiate a seed source */
 rand = EVP_RAND_fetch(NULL, "SEED-SRC", NULL);
 seed = EVP_RAND_CTX_new(rand, NULL);
 EVP_RAND_instantiate(seed, strength, 0, NULL, 0, NULL);
 EVP_RAND_free(rand);
 /* Feed this into a DRBG */
 rand = EVP_RAND_fetch(NULL, "CTR-DRBG", NULL);
 rctx = EVP_RAND_CTX_new(rand, seed);
 EVP_RAND_free(rand);
 /* Configure the DRBG */
 *p++ = OSSL_PARAM_construct_utf8_string(OSSL_DRBG_PARAM_CIPHER,
                                         SN_aes_256_ctr, 0);
 *p = OSSL_PARAM_construct_end();
 EVP_RAND_instantiate(rctx, strength, 0, NULL, 0, params);
 EVP_RAND_generate(rctx, bytes, sizeof(bytes), strength, 0, NULL, 0);
 EVP_RAND_CTX_free(rctx);
 EVP_RAND_CTX_free(seed);
```

## SEE ALSO
EVP_RAND(3), "PARAMETERS" in EVP_RAND(3)

## COPYRIGHT
Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: EVP_RAND-TEST-RAND(7ossl)

summary: The test EVP_RAND implementation

text:
# EVP_RAND-TEST-RAND(7ossl)

## NAME
EVP_RAND-TEST-RAND - The test EVP_RAND implementation

## DESCRIPTION
Support for a test generator through the EVP_RAND API. This generator is for test purposes only, it does not generate random numbers.

### Identity
"TEST-RAND" is the name for this implementation; it can be used with the EVP_RAND_fetch() function.

### Supported parameters
The supported parameters are:

"state" (OSSL_RAND_PARAM_STATE) <integer>

"fips-indicator" (OSSL_RAND_PARAM_FIPS_APPROVED_INDICATOR) <integer>

These parameter works as described in "PARAMETERS" in EVP_RAND(3).

"strength" (OSSL_RAND_PARAM_STRENGTH) <unsigned integer>

"reseed_requests" (OSSL_DRBG_PARAM_RESEED_REQUESTS) <unsigned integer>

"reseed_time_interval" (OSSL_DRBG_PARAM_RESEED_TIME_INTERVAL) <integer>

"max_request" (OSSL_DRBG_PARAM_RESEED_REQUESTS) <unsigned integer>

"min_entropylen" (OSSL_DRBG_PARAM_MIN_ENTROPYLEN) <unsigned integer>

"max_entropylen" (OSSL_DRBG_PARAM_MAX_ENTROPYLEN) <unsigned integer>

"min_noncelen" (OSSL_DRBG_PARAM_MIN_NONCELEN) <unsigned integer>

"max_noncelen" (OSSL_DRBG_PARAM_MAX_NONCELEN) <unsigned integer>

"max_perslen" (OSSL_DRBG_PARAM_MAX_PERSLEN) <unsigned integer>

"max_adinlen" (OSSL_DRBG_PARAM_MAX_ADINLEN) <unsigned integer>

"reseed_counter" (OSSL_DRBG_PARAM_RESEED_COUNTER) <unsigned integer>

These parameters work as described in "PARAMETERS" in EVP_RAND(3), except that they can all be set as well as read.

"test_entropy" (OSSL_RAND_PARAM_TEST_ENTROPY) <octet string>

Sets the bytes returned when the test generator is sent an entropy request. The current position is remembered across generate calls. If there are insufficient data present to satisfy a call, an error is returned.

"test_nonce" (OSSL_RAND_PARAM_TEST_NONCE) <octet string>

Sets the bytes returned when the test generator is sent a nonce request. Each nonce request will return all of the bytes.

"generate" (OSSL_RAND_PARAM_GENERATE) <integer>

If this parameter is zero, it will only emit the nonce and entropy data supplied via the aforementioned parameters. Otherwise, low quality non-cryptographic pseudorandom output is produced. This parameter defaults to zero.

## NOTES
A context for a test generator can be obtained by calling:

```
 EVP_RAND *rand = EVP_RAND_fetch(NULL, "TEST-RAND", NULL);
 EVP_RAND_CTX *rctx = EVP_RAND_CTX_new(rand, NULL);
```

## EXAMPLES

```
 EVP_RAND *rand;
 EVP_RAND_CTX *rctx;
 unsigned char bytes[100];
 OSSL_PARAM params[4], *p = params;
 unsigned char entropy[1000] = { ... };
 unsigned char nonce[20] = { ... };
 unsigned int strength = 48;
 rand = EVP_RAND_fetch(NULL, "TEST-RAND", NULL);
 rctx = EVP_RAND_CTX_new(rand, NULL);
 EVP_RAND_free(rand);
 *p++ = OSSL_PARAM_construct_uint(OSSL_RAND_PARAM_STRENGTH, &strength);
 *p++ = OSSL_PARAM_construct_octet_string(OSSL_RAND_PARAM_TEST_ENTROPY,
                                          entropy, sizeof(entropy));
 *p++ = OSSL_PARAM_construct_octet_string(OSSL_RAND_PARAM_TEST_NONCE,
                                          nonce, sizeof(nonce));
 *p = OSSL_PARAM_construct_end();
 EVP_RAND_instantiate(rctx, strength, 0, NULL, 0, params);
 EVP_RAND_generate(rctx, bytes, sizeof(bytes), strength, 0, NULL, 0);
 EVP_RAND_CTX_free(rctx);
```

## SEE ALSO
EVP_RAND(3), "PARAMETERS" in EVP_RAND(3)

## HISTORY
This functionality was added in OpenSSL 3.0.

## COPYRIGHT
Copyright 2020-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: EVP_SIGNATURE-DSA(7ossl)

summary: DSA

text:
# EVP_SIGNATURE-DSA(7ossl)

## NAME
EVP_SIGNATURE-DSA - The EVP_PKEY DSA signature implementation

## DESCRIPTION
Support for computing DSA signatures. The signature produced with EVP_PKEY_sign(3) is DER encoded ASN.1 in the form described in RFC 3279, section 2.2.2. See EVP_PKEY-DSA(7) for information related to DSA keys.

As part of FIPS 140-3 DSA is not longer FIPS approved for key generation and signature validation, but is still allowed for signature verification.

### Algorithm Names
In this list, names are grouped together to signify that they are the same algorithm having multiple names. This also includes the OID in canonical decimal form (which means that they are possible to fetch if the caller has a mere OID which came out in this form after a call to OBJ_obj2txt(3)).

"DSA", "dsaEncryption", "1.2.840.10040.4.1"

The base signature algorithm, supported explicitly fetched with EVP_PKEY_sign_init_ex2(3), and implicitly fetched (through EC keys) with EVP_DigestSignInit(3) and EVP_DigestVerifyInit(3). It can't be used with EVP_PKEY_sign_message_init(3)

"DSA-SHA1", "DSA-SHA-1", "dsaWithSHA1", "1.2.840.10040.4.3"

"DSA-SHA2-224", "DSA-SHA224", "dsa_with_SHA224", "2.16.840.1.101.3.4.3.1"

"DSA-SHA2-256", "DSA-SHA256", "dsa_with_SHA256", "2.16.840.1.101.3.4.3.2"

"DSA-SHA2-384", "DSA-SHA384", "dsa_with_SHA384", "id-dsa-with-sha384", "1.2.840.1.101.3.4.3.3"

"DSA-SHA2-512", "DSA-SHA512", "dsa_with_SHA512", "id-dsa-with-sha512", "1.2.840.1.101.3.4.3.4"

"DSA-SHA3-224", "dsa_with_SHA3-224", "id-dsa-with-sha3-224", "2.16.840.1.101.3.4.3.5"

"DSA-SHA3-256", "dsa_with_SHA3-256", "id-dsa-with-sha3-256", "2.16.840.1.101.3.4.3.6"

"DSA-SHA3-384", "dsa_with_SHA3-384", "id-dsa-with-sha3-384", "2.16.840.1.101.3.4.3.7"

"DSA-SHA3-512", "dsa_with_SHA3-512", "id-dsa-with-sha3-512", "2.16.840.1.101.3.4.3.8"

DSA signature schemes with diverse message digest algorithms. They are all supported explicitly fetched with EVP_PKEY_sign_init_ex2(3) and EVP_PKEY_sign_message_init(3).

### Signature Parameters
The following signature parameters can be set using EVP_PKEY_CTX_set_params(). This may be called after EVP_PKEY_sign_init() or EVP_PKEY_verify_init(), and before calling EVP_PKEY_sign() or EVP_PKEY_verify(). They may also be set using EVP_PKEY_sign_init_ex() or EVP_PKEY_verify_init_ex().

"digest" (OSSL_SIGNATURE_PARAM_DIGEST) <UTF8 string>

"properties" (OSSL_SIGNATURE_PARAM_PROPERTIES) <UTF8 string>

These two are not supported with the DSA signature schemes that already include a message digest algorithm, See "Algorithm Names" above.

"nonce-type" (OSSL_SIGNATURE_PARAM_NONCE_TYPE) <unsigned integer>

"key-check" (OSSL_SIGNATURE_PARAM_FIPS_KEY_CHECK) <integer>

"digest-check" (OSSL_SIGNATURE_PARAM_FIPS_DIGEST_CHECK) <integer>

"sign-check" (OSSL_SIGNATURE_PARAM_FIPS_SIGN_CHECK) <int>

The settable parameters are described in provider-signature(7).

The following signature parameters can be retrieved using EVP_PKEY_CTX_get_params().

"algorithm-id" (OSSL_SIGNATURE_PARAM_ALGORITHM_ID) <octet string>

"digest" (OSSL_SIGNATURE_PARAM_DIGEST) <UTF8 string>

"nonce-type" (OSSL_SIGNATURE_PARAM_NONCE_TYPE) <unsigned integer>

"fips-indicator" (OSSL_SIGNATURE_PARAM_FIPS_APPROVED_INDICATOR) <integer>

The gettable parameters are described in provider-signature(7).

## SEE ALSO
EVP_PKEY_CTX_set_params(3), EVP_PKEY_sign(3), EVP_PKEY_verify(3), provider-signature(7),

## HISTORY
DSA Key generation and signature generation are no longer FIPS approved in OpenSSL 3.4. See "FIPS indicators" in fips_module(7) for more information.

## COPYRIGHT
Copyright 2020-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: EVP_SIGNATURE-ECDSA(7ossl)

text:
# EVP_SIGNATURE-ECDSA(7ossl)

## NAME
EVP_SIGNATURE-ECDSA - The EVP_PKEY ECDSA signature implementation.

## DESCRIPTION
Support for computing ECDSA signatures. See EVP_PKEY-EC(7) for information related to EC keys.

### Algorithm Names
In this list, names are grouped together to signify that they are the same algorithm having multiple names. This also includes the OID in canonical decimal form (which means that they are possible to fetch if the caller has a mere OID which came out in this form after a call to OBJ_obj2txt(3)).

"ECDSA"

The base signature algorithm, supported explicitly fetched with EVP_PKEY_sign_init_ex2(3), and implicitly fetched (through EC keys) with EVP_DigestSignInit(3) and EVP_DigestVerifyInit(3). It can't be used with EVP_PKEY_sign_message_init(3)

"ECDSA-SHA1", "ECDSA-SHA-1", "ecdsa-with-SHA1", "1.2.840.10045.4.1"

"ECDSA-SHA2-224", "ECDSA-SHA224", "ecdsa-with-SHA224", "1.2.840.10045.4.3.1"

"ECDSA-SHA2-256", "ECDSA-SHA256", "ecdsa-with-SHA256", "1.2.840.10045.4.3.2"

"ECDSA-SHA2-384", "ECDSA-SHA384", "ecdsa-with-SHA384", "1.2.840.10045.4.3.3"

"ECDSA-SHA2-512", "ECDSA-SHA512", "ecdsa-with-SHA512", "1.2.840.10045.4.3.4"

"ECDSA-SHA3-224", "ecdsa_with_SHA3-224", "id-ecdsa-with-sha3-224", "2.16.840.1.101.3.4.3.9"

"ECDSA-SHA3-256", "ecdsa_with_SHA3-256", "id-ecdsa-with-sha3-256", "2.16.840.1.101.3.4.3.10"

"ECDSA-SHA3-384", "ecdsa_with_SHA3-384", "id-ecdsa-with-sha3-384", "2.16.840.1.101.3.4.3.11"

"ECDSA-SHA3-512", "ecdsa_with_SHA3-512", "id-ecdsa-with-sha3-512", "2.16.840.1.101.3.4.3.12"

ECDSA signature schemes with diverse message digest algorithms. They are all supported explicitly fetched with EVP_PKEY_sign_init_ex2(3) and EVP_PKEY_sign_message_init(3).

### ECDSA Signature Parameters
The following signature parameters can be set using EVP_PKEY_CTX_set_params(). This may be called after EVP_PKEY_sign_init() or EVP_PKEY_verify_init(), and before calling EVP_PKEY_sign() or EVP_PKEY_verify().

"digest" (OSSL_SIGNATURE_PARAM_DIGEST) <UTF8 string>

"properties" (OSSL_SIGNATURE_PARAM_PROPERTIES) <UTF8 string>

These two are not supported with the ECDSA signature schemes that already include a message digest algorithm, See "Algorithm Names" above.

"nonce-type" (OSSL_SIGNATURE_PARAM_NONCE_TYPE) <unsigned integer>

"key-check" (OSSL_SIGNATURE_PARAM_FIPS_KEY_CHECK) <integer>

"digest-check" (OSSL_SIGNATURE_PARAM_FIPS_DIGEST_CHECK) <integer>

These parameters are described in provider-signature(7).

The following signature parameters can be retrieved using EVP_PKEY_CTX_get_params().

"algorithm-id" (OSSL_SIGNATURE_PARAM_ALGORITHM_ID) <octet string>

"digest" (OSSL_SIGNATURE_PARAM_DIGEST) <UTF8 string>

"nonce-type" (OSSL_SIGNATURE_PARAM_NONCE_TYPE) <unsigned integer>

"fips-indicator" (OSSL_SIGNATURE_PARAM_FIPS_APPROVED_INDICATOR) <integer>

"verify-message" (OSSL_SIGNATURE_PARAM_FIPS_VERIFY_MESSAGE <integer>

The parameters are described in provider-signature(7).

## SEE ALSO
EVP_PKEY_CTX_set_params(3), EVP_PKEY_sign(3), EVP_PKEY_verify(3), provider-signature(7),

## COPYRIGHT
Copyright 2020-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: EVP_SIGNATURE-ED25519(7ossl)

text:
# EVP_SIGNATURE-ED25519(7ossl)

## NAME
EVP_SIGNATURE-ED25519, EVP_SIGNATURE-ED448, Ed25519, Ed448 - EVP_PKEY Ed25519 and Ed448 support

## DESCRIPTION
The Ed25519 and Ed448 EVP_PKEY implementation supports key generation, one-shot digest-sign and digest-verify using the EdDSA signature schemes described in RFC 8032. It has associated private and public key formats compatible with RFC 8410.

### EdDSA Instances
RFC 8032 describes five EdDSA instances: Ed25519, Ed25519ctx, Ed25519ph, Ed448, Ed448ph.

The instances Ed25519, Ed25519ctx, Ed448 are referred to as PureEdDSA schemes. For these three instances, the sign and verify procedures require access to the complete message (not a digest of the message).

The instances Ed25519ph, Ed448ph are referred to as HashEdDSA schemes. For these two instances, the sign and verify procedures do not require access to the complete message; they operate on a hash of the message. For Ed25519ph, the hash function is SHA512. For Ed448ph, the hash function is SHAKE256 with an output length of 512 bits.

The instances Ed25519ctx, Ed25519ph, Ed448, Ed448ph accept an optional context-string as input to sign and verify operations (and for Ed25519ctx, the context-string must be nonempty). For the Ed25519 instance, a nonempty context-string is not permitted.

These instances can be specified as signature parameters when using EVP_DigestSignInit(3) and EVP_DigestVerifyInit(3), see "ED25519 and ED448 Signature Parameters" below.

These instances are also explicitly fetchable as algorithms using EVP_SIGNATURE_fetch(3), which can be used with EVP_PKEY_sign_init_ex2(3), EVP_PKEY_verify_init_ex2(3), EVP_PKEY_sign_message_init(3) and EVP_PKEY_verify_message_init(3).

### ED25519 and ED448 Signature Parameters
Two parameters can be set during signing or verification: the EdDSA instance name and the context-string value. They can be set by passing an OSSL_PARAM array to EVP_DigestSignInit_ex().

- "instance" (OSSL_SIGNATURE_PARAM_INSTANCE) <utf8 string> One of the five strings "Ed25519", "Ed25519ctx", "Ed25519ph", "Ed448", "Ed448ph".

"Ed25519", "Ed25519ctx", "Ed25519ph" are valid only for an Ed25519 EVP_PKEY.

"Ed448", "Ed448ph" are valid only for an Ed448 EVP_PKEY.

- "context-string" (OSSL_SIGNATURE_PARAM_CONTEXT_STRING) <octet string> A string of octets with length at most 255.

Both of these parameters are optional.

When using EVP_DigestSignInit(3) or EVP_DigestVerifyInit(3), the signature algorithm is derived from the key type name. The key type name ("Ed25519" or "Ed448") is also the default for the instance, but this can be changed with the "instance" parameter.

Note that a message digest name must NOT be specified when signing or verifying.

When using EVP_PKEY_sign_init_ex2(3), EVP_PKEY_verify_init_ex2(3), EVP_PKEY_sign_message_init(3) or EVP_PKEY_verify_message_init(3), the instance is the explicit signature algorithm name, and may not be changed (trying to give one with the "instance" parameter is therefore an error).

If a context-string is not specified, then an empty context-string is used.

See EVP_PKEY-X25519(7) for information related to X25519 and X448 keys.

The following signature parameters can be retrieved using EVP_PKEY_CTX_get_params().

- "algorithm-id" (OSSL_SIGNATURE_PARAM_ALGORITHM_ID) <octet string>

- "instance" (OSSL_SIGNATURE_PARAM_INSTANCE) <utf8 string>

- "context-string" (OSSL_SIGNATURE_PARAM_CONTEXT_STRING) <octet string>

The parameters are described in provider-signature(7).

## NOTES
The PureEdDSA instances do not support the streaming mechanism of other signature algorithms using, for example, EVP_DigestUpdate(). The message to sign or verify must be passed using the one-shot EVP_DigestSign() and EVP_DigestVerify() functions.

The HashEdDSA instances do not yet support the streaming mechanisms (so the one-shot functions must be used with HashEdDSA as well).

When calling EVP_DigestSignInit() or EVP_DigestVerifyInit(), the digest type parameter MUST be set to NULL.

Applications wishing to sign certificates (or other structures such as CRLs or certificate requests) using Ed25519 or Ed448 can either use X509_sign() or X509_sign_ctx() in the usual way.

Ed25519 or Ed448 private keys can be set directly using EVP_PKEY_new_raw_private_key(3) or loaded from a PKCS#8 private key file using PEM_read_bio_PrivateKey(3) (or similar function). Completely new keys can also be generated (see the example below). Setting a private key also sets the associated public key.

Ed25519 or Ed448 public keys can be set directly using EVP_PKEY_new_raw_public_key(3) or loaded from a SubjectPublicKeyInfo structure in a PEM file using PEM_read_bio_PUBKEY(3) (or similar function).

Ed25519 and Ed448 can be tested with the openssl-speed(1) application since version 1.1.1. Valid algorithm names are ed25519, ed448 and eddsa. If eddsa is specified, then both Ed25519 and Ed448 are benchmarked.

## EXAMPLES
To sign a message using an ED25519 EVP_PKEY structure:

```
    void do_sign(EVP_PKEY *ed_key, unsigned char *msg, size_t msg_len)
    {
        size_t sig_len;
        unsigned char *sig = NULL;
        EVP_MD_CTX *md_ctx = EVP_MD_CTX_new();
        const OSSL_PARAM params[] = {
            OSSL_PARAM_utf8_string ("instance", "Ed25519ctx", 10),
            OSSL_PARAM_octet_string("context-string", (unsigned char *)"A protocol defined context string", 33),
            OSSL_PARAM_END
        };
        /* The input "params" is not needed if default options are acceptable.
           Use NULL in place of "params" in that case. */
        EVP_DigestSignInit_ex(md_ctx, NULL, NULL, NULL, NULL, ed_key, params);
        /* Calculate the required size for the signature by passing a NULL buffer. */
        EVP_DigestSign(md_ctx, NULL, &sig_len, msg, msg_len);
        sig = OPENSSL_zalloc(sig_len);
        EVP_DigestSign(md_ctx, sig, &sig_len, msg, msg_len);
        ...
        OPENSSL_free(sig);
        EVP_MD_CTX_free(md_ctx);
    }
```

## SEE ALSO
EVP_PKEY-X25519(7) provider-signature(7), EVP_DigestSignInit(3), EVP_DigestVerifyInit(3),

## COPYRIGHT
Copyright 2017-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: EVP_SIGNATURE-HMAC(7ossl)

summary: HMAC, EVP_SIGNATURE\-Siphash, EVP_SIGNATURE\-Poly1305,

text:
# EVP_SIGNATURE-HMAC(7ossl)

## NAME
EVP_SIGNATURE-HMAC, EVP_SIGNATURE-Siphash, EVP_SIGNATURE-Poly1305, EVP_SIGNATURE-CMAC - The legacy EVP_PKEY MAC signature implementations

## DESCRIPTION
The algorithms described here have legacy support for creating MACs using EVP_DigestSignInit(3) and related functions. This is not the preferred way of creating MACs. Instead you should use the newer EVP_MAC_init(3) functions. This mechanism is provided for backwards compatibility with older versions of OpenSSL.

The same signature parameters can be set using EVP_PKEY_CTX_set_params() as can be set via EVP_MAC_CTX_set_params() for the underlying EVP_MAC. See EVP_MAC-HMAC(7), EVP_MAC-Siphash(7), EVP_MAC-Poly1305(7) and EVP_MAC-CMAC(7) for details.

```
 See L<EVP_PKEY-HMAC(7)>, L<EVP_PKEY-Siphash(7)>, L<EVP_PKEY-Poly1305(7)> or
 L<EVP_PKEY-CMAC(7)> for details about parameters that are supported during the
 creation of an EVP_PKEY.
```

## SEE ALSO
EVP_MAC_init(3), EVP_DigestSignInit(3), EVP_PKEY-HMAC(7), EVP_PKEY-Siphash(7), EVP_PKEY-Poly1305(7), EVP_PKEY-CMAC(7), EVP_MAC-HMAC(7), EVP_MAC-Siphash(7), EVP_MAC-Poly1305(7), EVP_MAC-CMAC(7), provider-signature(7),

## COPYRIGHT
Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: EVP_SIGNATURE-ML-DSA(7ossl)

summary: ML\-DSA,

text:
# EVP_SIGNATURE-ML-DSA(7ossl)

## NAME
EVP_SIGNATURE-ML-DSA, EVP_SIGNATURE-ML-DSA-44, EVP_SIGNATURE-ML-DSA-65, EVP_SIGNATURE-ML-DSA-87, - EVP_SIGNATURE ML-DSA support

## DESCRIPTION
The ML-DSA-44, ML-DSA-65 and ML-DSA-87 EVP_PKEY implementations support key generation, and one-shot sign and verify using the ML-DSA signature schemes described in FIPS 204 <https://csrc.nist.gov/pubs/fips/204/final>.

The different algorithms names correspond to the parameter sets defined in FIPS 204 <https://csrc.nist.gov/pubs/fips/204/final> Section 4 Table 1. (The signatures range in size from ~2.5K to ~4.5K depending on the type chosen). There are 3 different security categories also depending on the type.

EVP_SIGNATURE_fetch(3) can be used to explicitely fetch one of the 3 algorithms which can then be used with EVP_PKEY_sign_message_init(3), EVP_PKEY_sign(3), EVP_PKEY_verify_message_init(3), and EVP_PKEY_verify(3) to perform one-shot message signing or signature verification.

The normal signing process (called Pure ML-DSA Signature Generation) encodes the message internally as 0x00 || len(ctx) || ctx || message. where ctx is some optional value of size 0x00..0xFF. This process is defined in FIPS 204 <https://csrc.nist.gov/pubs/fips/204/final> Algorithm 2 step 10 and Algorithm 3 step 5. OpenSSL also allows the message to not be encoded which is required for testing. OpenSSL does not support Pre Hash ML-DSA Signature Generation, but this may be done by the user by doing Pre hash encoding externally and then choosing the option to not encode the message.

### ML-DSA Signature Parameters
The following parameter can be used for both signing and verification. it may be set by passing an OSSL_PARAM array to EVP_PKEY_sign_message_init(3) or EVP_PKEY_verify_message_init(3)

"context-string" (OSSL_SIGNATURE_PARAM_CONTEXT_STRING) <octet string>

A string of octets with length at most 255. By default it is the empty string.

The following parameters can be used when signing: They can be set by passing an OSSL_PARAM array to EVP_PKEY_sign_init_ex2(3).

"message-encoding" (OSSL_SIGNATURE_PARAM_MESSAGE_ENCODING) <integer>

The default value of 1 uses 'Pure ML-DSA Signature Generation' as described above. Setting it to 0 does not encode the message, which is used for testing. The message encoding steps are defined in FIPS 204 <https://csrc.nist.gov/pubs/fips/204/final> Algorithm 2 step 10 and Algorithm 3 step 5.

"test-entropy" (OSSL_SIGNATURE_PARAM_TEST_ENTROPY) <octet string>

Used for testing to pass an optional deterministic per message random value. If set the size must be 32 bytes.

"deterministic" (OSSL_SIGNATURE_PARAM_DETERMINISTIC) <integer>

The default value of 0 causes the per message randomness to be randomly generated using a DRBG. Setting this to 1 causes the per message randomness to be set to 32 bytes of zeros. This value is ignored if "test-entropy" is set.

"mu" (OSSL_SIGNATURE_PARAM_MU) <integer>

The default value of 0 causes sign and verify operations to process a raw message. Setting this to 1 causes those operations to assume the input is the "mu" value from FIPS 204 <https://csrc.nist.gov/pubs/fips/204/final> Algorithm 7 step 6 and Algorithm 8 step 7. Note that the message encoding steps from FIPS 204 <https://csrc.nist.gov/pubs/fips/204/final> Algorithm 2 step 10 and Algorithm 3 step 5 are omitted when this setting is 1.

See EVP_PKEY-ML-DSA(7) for information related to ML-DSA keys.

## NOTES
For backwards compatability reasons EVP_DigestSignInit_ex(), EVP_DigestSign(), EVP_DigestVerifyInit_ex() and EVP_DigestVerify() may also be used, but the digest passed in mdname must be NULL.

## EXAMPLES
To sign a message using an ML-DSA EVP_PKEY structure:

```
    void do_sign(EVP_PKEY *key, unsigned char *msg, size_t msg_len)
    {
        size_t sig_len;
        unsigned char *sig = NULL;
        const OSSL_PARAM params[] = {
            OSSL_PARAM_octet_string("context-string", (unsigned char *)"A context string", 16),
            OSSL_PARAM_END
        };
        EVP_PKEY_CTX *sctx = EVP_PKEY_CTX_new_from_pkey(NULL, pkey, NULL);
        EVP_SIGNATURE *sig_alg = EVP_SIGNATURE_fetch(NULL, "ML-DSA-65", NULL);
        EVP_PKEY_sign_message_init(sctx, sig_alg, params);
        /* Calculate the required size for the signature by passing a NULL buffer. */
        EVP_PKEY_sign(sctx, NULL, &sig_len, msg, msg_len);
        sig = OPENSSL_zalloc(sig_len);
        EVP_PKEY_sign(sctx, sig, &sig_len, msg, msg_len);
        ...
        OPENSSL_free(sig);
        EVP_SIGNATURE_free(sig_alg);
        EVP_PKEY_CTX_free(sctx);
    }
```

## SEE ALSO
EVP_PKEY-ML-DSA(7) provider-signature(7), EVP_PKEY_sign(3), EVP_PKEY_verify(3), FIPS 204 <https://csrc.nist.gov/pubs/fips/204/final>

## HISTORY
This functionality was added in OpenSSL 3.5.

## COPYRIGHT
Copyright 2025 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: EVP_SIGNATURE-RSA(7ossl)

summary: RSA

text:
# EVP_SIGNATURE-RSA(7ossl)

## NAME
EVP_SIGNATURE-RSA - The EVP_PKEY RSA signature implementation

## DESCRIPTION
Support for computing RSA signatures. See EVP_PKEY-RSA(7) for information related to RSA keys.

### Algorithm Names
In this list, names are grouped together to signify that they are the same algorithm having multiple names. This also includes the OID in canonical decimal form (which means that they are possible to fetch if the caller has a mere OID which came out in this form after a call to OBJ_obj2txt(3)).

"RSA", "rsaEncryption", "1.2.840.113549.1.1.1"

The base signature algorithm, supported explicitly fetched with EVP_PKEY_sign_init_ex2(3), and implicitly fetched (through RSA keys) with EVP_DigestSignInit(3) and EVP_DigestVerifyInit(3). It can't be used with EVP_PKEY_sign_message_init(3)

"RSA-RIPEMD160", "ripemd160WithRSA", "1.3.36.3.3.1.2"

"RSA-SHA2-256", "RSA-SHA256", "sha256WithRSAEncryption", "1.2.840.113549.1.1.11"

"RSA-SHA2-384", "RSA-SHA384", "sha384WithRSAEncryption", "1.2.840.113549.1.1.12"

"RSA-SHA2-512", "RSA-SHA512", "sha512WithRSAEncryption", "1.2.840.113549.1.1.13"

"RSA-SHA2-224", "RSA-SHA224", "sha224WithRSAEncryption", "1.2.840.113549.1.1.14"

"RSA-SHA2-512/224", "RSA-SHA512-224", "sha512-224WithRSAEncryption", "1.2.840.113549.1.1.15"

"RSA-SHA2-512/256", "RSA-SHA512-256", "sha512-256WithRSAEncryption", "1.2.840.113549.1.1.16"

"RSA-SHA3-224", "id-rsassa-pkcs1-v1_5-with-sha3-224", "2.16.840.1.101.3.4.3.13"

"RSA-SHA3-256", "id-rsassa-pkcs1-v1_5-with-sha3-256", "2.16.840.1.101.3.4.3.14"

"RSA-SHA3-384", "id-rsassa-pkcs1-v1_5-with-sha3-384", "2.16.840.1.101.3.4.3.15"

"RSA-SHA3-512", "id-rsassa-pkcs1-v1_5-with-sha3-512", "2.16.840.1.101.3.4.3.16"

"RSA-SM3", "sm3WithRSAEncryption", "1.2.156.10197.1.504"

PKCS#1 v1.5 RSA signature schemes with diverse message digest algorithms. They are all supported explicitly fetched with EVP_PKEY_sign_init_ex2(3) and EVP_PKEY_sign_message_init(3). They are all pre-set to use the pad mode "pkcs1". This cannot be changed.

### Signature Parameters
The following signature parameters can be set using EVP_PKEY_CTX_set_params(). This may be called after EVP_PKEY_sign_init() or EVP_PKEY_verify_init(), and before calling EVP_PKEY_sign() or EVP_PKEY_verify(). They may also be set using EVP_PKEY_sign_init_ex() or EVP_PKEY_verify_init_ex().

"digest" (OSSL_SIGNATURE_PARAM_DIGEST) <UTF8 string>

"properties" (OSSL_SIGNATURE_PARAM_PROPERTIES) <UTF8 string>

These are not supported with the RSA signature schemes that already include a message digest algorithm, See "Algorithm Names" above. These common parameters are described in provider-signature(7).

"pad-mode" (OSSL_SIGNATURE_PARAM_PAD_MODE) <UTF8 string>

The type of padding to be used. Its value can be one of the following:

"none" (OSSL_PKEY_RSA_PAD_MODE_NONE)

"pkcs1" (OSSL_PKEY_RSA_PAD_MODE_PKCSV15)

"x931" (OSSL_PKEY_RSA_PAD_MODE_X931)

This padding mode is no longer supported by the FIPS provider for signature generation, but may be used for signature verification for legacy use cases. (This is a FIPS 140-3 requirement)

"pss" (OSSL_PKEY_RSA_PAD_MODE_PSS)

"mgf1-digest" (OSSL_SIGNATURE_PARAM_MGF1_DIGEST) <UTF8 string>

The digest algorithm name to use for the maskGenAlgorithm used by "pss" mode.

"mgf1-properties" (OSSL_SIGNATURE_PARAM_MGF1_PROPERTIES) <UTF8 string>

Sets the name of the property query associated with the "mgf1-digest" algorithm. NULL is used if this optional value is not set.

"saltlen" (OSSL_SIGNATURE_PARAM_PSS_SALTLEN) <integer> or <UTF8 string>

The "pss" mode minimum salt length. The value can either be an integer, a string value representing a number or one of the following string values:

"digest" (OSSL_PKEY_RSA_PSS_SALT_LEN_DIGEST)

Use the same length as the digest size.

"max" (OSSL_PKEY_RSA_PSS_SALT_LEN_MAX)

Use the maximum salt length.

"auto" (OSSL_PKEY_RSA_PSS_SALT_LEN_AUTO)

Auto detect the salt length.

"auto-digestmax" (OSSL_PKEY_RSA_PSS_SALT_LEN_AUTO_DIGEST_MAX)

Auto detect the salt length when verifying. Maximize the salt length up to the digest size when signing to comply with FIPS 186-4 section 5.5.

The OpenSSL FIPS provider also supports the following parameters:

"key-check" (OSSL_SIGNATURE_PARAM_FIPS_KEY_CHECK) <integer>

"digest-check" (OSSL_SIGNATURE_PARAM_FIPS_DIGEST_CHECK) <integer>

"sign-x931-pad-check" (OSSL_SIGNATURE_PARAM_FIPS_SIGN_X931_PAD_CHECK) <integer>

These parameters are described in provider-signature(7).

"rsa-pss-saltlen-check" (OSSL_SIGNATURE_PARAM_FIPS_RSA_PSS_SALTLEN_CHECK) <integer>

The default value of 1 causes an error during signature generation or verification if salt length (OSSL_SIGNATURE_PARAM_PSS_SALTLEN) is not between zero and the output block size of the digest function (inclusive). Setting this to zero will ignore the error and set the approved "fips-indicator" to 0. This option breaks FIPS compliance if it causes the approved "fips-indicator" to return 0.

The following signature parameters can be retrieved using EVP_PKEY_CTX_get_params().

"algorithm-id" (OSSL_SIGNATURE_PARAM_ALGORITHM_ID) <octet string>

"fips-indicator" (OSSL_SIGNATURE_PARAM_FIPS_APPROVED_INDICATOR) <integer>

"verify-message" (OSSL_SIGNATURE_PARAM_FIPS_VERIFY_MESSAGE <integer>

These common parameter are described in provider-signature(7).

"digest" (OSSL_SIGNATURE_PARAM_DIGEST) <UTF8 string>

"pad-mode" (OSSL_SIGNATURE_PARAM_PAD_MODE) <UTF8 string>

"mgf1-digest" (OSSL_SIGNATURE_PARAM_MGF1_DIGEST) <UTF8 string>

"saltlen" (OSSL_SIGNATURE_PARAM_PSS_SALTLEN) <integer> or <UTF8 string>

These parameters are as described above.

## SEE ALSO
EVP_PKEY_CTX_set_params(3), EVP_PKEY_sign(3), EVP_PKEY_verify(3), provider-signature(7),

## COPYRIGHT
Copyright 2020-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: EVP_SIGNATURE-SLH-DSA(7ossl)

summary: SLH\-DSA,

text:
# EVP_SIGNATURE-SLH-DSA(7ossl)

## NAME
EVP_SIGNATURE-SLH-DSA, EVP_SIGNATURE-SLH-DSA-SHA2-128s, EVP_SIGNATURE-SLH-DSA-SHA2-128f, EVP_SIGNATURE-SLH-DSA-SHA2-192s, EVP_SIGNATURE-SLH-DSA-SHA2-192f, EVP_SIGNATURE-SLH-DSA-SHA2-256s, EVP_SIGNATURE-SLH-DSA-SHA2-256f, EVP_SIGNATURE-SLH-DSA-SHAKE-128s, EVP_SIGNATURE-SLH-DSA-SHAKE-128f, EVP_SIGNATURE-SLH-DSA-SHAKE-192s, EVP_SIGNATURE-SLH-DSA-SHAKE-192f, EVP_SIGNATURE-SLH-DSA-SHAKE-256s, EVP_SIGNATURE-SLH-DSA-SHAKE-256f - EVP_PKEY SLH-DSA support

## DESCRIPTION
The SLH-DSA-SHA2-128s, EVP_PKEY-SLH-DSA-SHA2-128f, SLH-DSA-SHA2-192s, EVP_PKEY-SLH-DSA-SHA2-192f, SLH-DSA-SHA2-256s, EVP_PKEY-SLH-DSA-SHA2-256f, SLH-DSA-SHAKE-128s, EVP_PKEY-SLH-DSA-SHAKE-128f, SLH-DSA-SHAKE-192s, EVP_PKEY-SLH-DSA-SHAKE-192f, SLH-DSA-SHAKE-256s and EVP_PKEY-SLH-DSA-SHAKE-256f EVP_PKEY implementations supports key generation, one-shot sign and verify using the SLH-DSA signature schemes described in FIPS 205.

The different algorithms names correspond to the parameter sets defined in FIPS 205 Section 11 Table 2. "s" types have smaller signature sizes, and the "f" variants are faster, (The signatures range from ~8K to ~50K depending on the type chosen). There are 3 different security categories also depending on the type.

EVP_SIGNATURE_fetch(3) can be used to explicitely fetch one of the 12 algorithms which can then be used with EVP_PKEY_sign_message_init(3), EVP_PKEY_sign(3), EVP_PKEY_verify_message_init(3), and EVP_PKEY_verify(3) to perform one-shot message signing or verification.

The normal signing process (called Pure SLH-DSA Signature Generation) encodes the message internally as 0x00 || len(ctx) || ctx || message. where ctx is some optional value of size 0x00..0xFF. OpenSSL also allows the message to not be encoded which is required for testing. OpenSSL does not support Pre Hash SLH-DSA Signature Generation, but this may be done by the user by doing Pre hash encoding externally and then chosing the option to not encode the message.

### SLH-DSA Signature Parameters
The "context-string" parameter, described below, can be used for both signing and verification. It may be set by passing an OSSL_PARAM array to EVP_PKEY_sign_init_ex2(3) or EVP_PKEY_verify_init_ex2(3)

"context-string" (OSSL_SIGNATURE_PARAM_CONTEXT_STRING) <octet string>

A string of octets with length at most 255. By default it is the empty string.

The following parameters can be used when signing: They can be set by passing an OSSL_PARAM array to EVP_PKEY_sign_init_ex2(3).

"message-encoding" (OSSL_SIGNATURE_PARAM_MESSAGE_ENCODING) <integer>

The default value of 1 uses 'Pure SLH-DSA Signature Generation' as described above. Setting it to 0 does not encode the message, which is used for testing, but can also be used for 'Pre Hash SLH-DSA Signature Generation'.

"test-entropy" (OSSL_SIGNATURE_PARAM_TEST_ENTROPY <octet string

Used for testing to pass a optional random value.

"deterministic" (OSSL_SIGNATURE_PARAM_DETERMINISTIC) <integer>

The default value of 0 generates a random value (using a DRBG) this is used when processing the message. Setting this to 1 causes the private key seed to be used instead. This value is ignored if "test-entropy" is set.

See EVP_PKEY-SLH-DSA(7) for information related to SLH-DSA keys.

## NOTES
For backwards compatibility reasons EVP_DigestSignInit_ex(), EVP_DigestSign(), EVP_DigestVerifyInit_ex() and EVP_DigestVerify() may also be used, but the digest passed in mdname must be NULL.

## EXAMPLES
To sign a message using an SLH-DSA EVP_PKEY structure:

```
    void do_sign(EVP_PKEY *key, unsigned char *msg, size_t msg_len)
    {
        size_t sig_len;
        unsigned char *sig = NULL;
        const OSSL_PARAM params[] = {
            OSSL_PARAM_octet_string("context-string", (unsigned char *)"A context string", 33),
            OSSL_PARAM_END
        };
        EVP_PKEY_CTX *sctx = EVP_PKEY_CTX_new_from_pkey(NULL, pkey, NULL);
        EVP_SIGNATURE *sig_alg = EVP_SIGNATURE_fetch(NULL, "SLH-DSA-SHA2-128s", NULL);
        EVP_PKEY_sign_message_init(sctx, sig_alg, params);
        /* Calculate the required size for the signature by passing a NULL buffer. */
        EVP_PKEY_sign(sctx, NULL, &sig_len, msg, msg_len);
        sig = OPENSSL_zalloc(sig_len);
        EVP_PKEY_sign(sctx, sig, &sig_len, msg, msg_len);
        ...
        OPENSSL_free(sig);
        EVP_SIGNATURE_free(sig_alg);
        EVP_PKEY_CTX_free(sctx);
    }
```

## SEE ALSO
EVP_PKEY-SLH-DSA(7) provider-signature(7), EVP_PKEY_sign(3), EVP_PKEY_verify(3),

## HISTORY
This functionality was added in OpenSSL 3.5.

## COPYRIGHT
Copyright 2024-2025 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: OSSL_PROVIDER-FIPS(7ossl)

summary: OpenSSL FIPS provider

text:
# OSSL_PROVIDER-FIPS(7ossl)

## NAME
OSSL_PROVIDER-FIPS - OpenSSL FIPS provider

## DESCRIPTION
The OpenSSL FIPS provider is a special provider that conforms to the Federal Information Processing Standards (FIPS) specified in FIPS 140-3. This 'module' contains an approved set of cryptographic algorithms that is validated by an accredited testing laboratory.

### Properties
The implementations in this provider specifically have these properties defined for approved algorithms:

"provider=fips"

"fips=yes"

It may be used in a property query string with fetching functions such as EVP_MD_fetch(3) or EVP_CIPHER_fetch(3), as well as with other functions that take a property query string, such as EVP_PKEY_CTX_new_from_name(3).

To be FIPS compliant, it is mandatory to include "fips=yes" as part of all property queries. This ensures that only FIPS approved implementations are used for cryptographic operations. The "fips=yes" query may also include other non-crypto support operations that are not in the FIPS provider, such as asymmetric key encoders, see "Asymmetric Key Management" in OSSL_PROVIDER-default(7).

It is not mandatory to include "provider=fips" as part of your property query. Including "provider=fips" in your property query guarantees that the OpenSSL FIPS provider is used for cryptographic operations rather than other FIPS capable providers.

### Approved algorithms
Algorithms that are fetched using "fips=yes" may still be unapproved if certain conditions are not met. See "FIPS indicators" in fips_module(7) for additional information.

### Provider parameters
See "Provider parameters" in provider-base(7) for a list of base parameters. The OpenSSL FIPS provider also handles FIPS indicator related parameters as specified by "FIPS indicator options" in fips_config(5).

## OPERATIONS AND ALGORITHMS
The OpenSSL FIPS provider supports these operations and algorithms:

### Hashing Algorithms / Message Digests
SHA1, see EVP_MD-SHA1(7)

SHA2, see EVP_MD-SHA2(7)

SHA3, see EVP_MD-SHA3(7)

KECCAK-KMAC, see EVP_MD-KECCAK-KMAC(7)

SHAKE, see EVP_MD-SHAKE(7)

### Symmetric Ciphers
AES, see EVP_CIPHER-AES(7)

3DES, see EVP_CIPHER-DES(7)

### Message Authentication Code (MAC)
CMAC, see EVP_MAC-CMAC(7)

GMAC, see EVP_MAC-GMAC(7)

HMAC, see EVP_MAC-HMAC(7)

KMAC, see EVP_MAC-KMAC(7)

### Key Derivation Function (KDF)
HKDF, see EVP_KDF-HKDF(7)

TLS13-KDF, see EVP_KDF-TLS13_KDF(7)

SSKDF, see EVP_KDF-SS(7)

PBKDF2, see EVP_KDF-PBKDF2(7)

SSHKDF, see EVP_KDF-SSHKDF(7)

TLS1-PRF, see EVP_KDF-TLS1_PRF(7)

KBKDF, see EVP_KDF-KB(7)

X942KDF-ASN1, see EVP_KDF-X942-ASN1(7)

X942KDF-CONCAT, see EVP_KDF-X942-CONCAT(7)

X963KDF, see EVP_KDF-X963(7)

### Key Exchange
DH, see EVP_KEYEXCH-DH(7)

ECDH, see EVP_KEYEXCH-ECDH(7)

X25519, see EVP_KEYEXCH-X25519(7)

X448, see EVP_KEYEXCH-X448(7)

ML-KEM, see EVP_KEM-ML-KEM(7)

TLS1-PRF

HKDF

### Asymmetric Signature
RSA, see EVP_SIGNATURE-RSA(7)

The X931 padding mode "OSSL_PKEY_RSA_PAD_MODE_X931" is no longer supported for signature generation, but may be used for verification for legacy use cases. (This is a FIPS 140-3 requirement)

DSA, see EVP_SIGNATURE-DSA(7)

ED25519, see EVP_SIGNATURE-ED25519(7)

ED448, see EVP_SIGNATURE-ED448(7)

ECDSA, see EVP_SIGNATURE-ECDSA(7)

ML-DSA-44, see EVP_SIGNATURE-ML-DSA(7)

ML-DSA-65, see EVP_SIGNATURE-ML-DSA(7)

ML-DSA-87, see EVP_SIGNATURE-ML-DSA(7)

SLH-DSA, see EVP_SIGNATURE-SLH-DSA(7)

HMAC, see EVP_SIGNATURE-HMAC(7)

CMAC, see EVP_SIGNATURE-CMAC(7)

### Asymmetric Cipher
RSA, see EVP_ASYM_CIPHER-RSA(7)

### Asymmetric Key Encapsulation
RSA, see EVP_KEM-RSA(7)

### Asymmetric Key Management
DH, see EVP_KEYMGMT-DH(7)

DHX, see EVP_KEYMGMT-DHX(7)

DSA, see EVP_KEYMGMT-DSA(7)

RSA, see EVP_KEYMGMT-RSA(7)

RSA-PSS

EC, see EVP_KEYMGMT-EC(7)

ED25519, see EVP_KEYMGMT-ED25519(7)

ED448, see EVP_KEYMGMT-ED448(7)

X25519, see EVP_KEYMGMT-X25519(7)

This is an unapproved algorithm. The FIPS 140-3 IG states that "Curves that are included in SP 800-186 but not included in SP 800-56Arev3 are not approved for key agreement".

X448, see EVP_KEYMGMT-X448(7)

This is an unapproved algorithm. The FIPS 140-3 IG states that "Curves that are included in SP 800-186 but not" included in SP 800-56Arev3 are not approved for key agreement".

TLS1-PRF

HKDF

HMAC, see EVP_KEYMGMT-HMAC(7)

CMAC, see EVP_KEYMGMT-CMAC(7)

ML-DSA-44, see EVP_KEYMGMT-ML-DSA(7)

ML-DSA-65, see EVP_KEYMGMT-ML-DSA(7)

ML-DSA-87, see EVP_KEYMGMT-ML-DSA(7)

SLH-DSA-SHA2-128s, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHA2-128f, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHA2-192s, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHA2-192f, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHA2-256s, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHA2-256f, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHAKE-128s, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHAKE-128f, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHAKE-192s, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHAKE-192f, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHAKE-256s, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHAKE-256f, see EVP_KEYMGMT-SLH-DSA(7)

### Random Number Generation
CRNG-TEST, see EVP_RAND-CRNG-TEST(7)

CTR-DRBG, see EVP_RAND-CTR-DRBG(7)

HASH-DRBG, see EVP_RAND-HASH-DRBG(7)

HMAC-DRBG, see EVP_RAND-HMAC-DRBG(7)

TEST-RAND, see EVP_RAND-TEST-RAND(7)

TEST-RAND is an unapproved algorithm.

## SELF TESTING
A requirement of FIPS modules is to run cryptographic algorithm self tests. FIPS 140-3 requires known answer tests to be run on startup as well as conditional tests that run during cryptographic operations.

An optional callback mechanism is available to return information to the user using OSSL_SELF_TEST_set_callback(3).

The parameters passed to the callback are described in OSSL_SELF_TEST_new(3)

The OpenSSL FIPS module uses the following mechanism to provide information about the self tests as they run. This is useful for debugging if a self test is failing. The callback also allows forcing any self test to fail, in order to check that it operates correctly on failure. Note that all self tests run even if a self test failure occurs.

The FIPS module passes the following type(s) to OSSL_SELF_TEST_onbegin().

"Module_Integrity" (OSSL_SELF_TEST_TYPE_MODULE_INTEGRITY)

Uses HMAC SHA256 on the module file to validate that the module has not been modified. The integrity value is compared to a value written to a configuration file during installation.

"KAT_Integrity" (OSSL_SELF_TEST_TYPE_KAT_INTEGRITY)

Used during the Module Integrity test to perform a known answer test on HMAC SHA256 prior to using it.

"KAT_Cipher" (OSSL_SELF_TEST_TYPE_KAT_CIPHER)

Known answer test for a symmetric cipher.

"KAT_AsymmetricCipher" (OSSL_SELF_TEST_TYPE_KAT_ASYM_CIPHER)

Known answer test for a asymmetric cipher.

"KAT_Digest" (OSSL_SELF_TEST_TYPE_KAT_DIGEST)

Known answer test for a digest.

"KAT_AsymmetricKeyGeneration" (OSSL_SELF_TEST_TYPE_KAT_ASYM_KEYGEN)

Known answer test for asymmetric key generation.

"KAT_Signature" (OSSL_SELF_TEST_TYPE_KAT_SIGNATURE)

Known answer test for a signature.

"PCT_Signature" (OSSL_SELF_TEST_TYPE_PCT_SIGNATURE)

Pairwise Consistency check for a signature.

"KAT_KDF" (OSSL_SELF_TEST_TYPE_KAT_KDF)

Known answer test for a key derivation function.

"KAT_KA" (OSSL_SELF_TEST_TYPE_KAT_KA)

Known answer test for key agreement.

"KAT_KEM" (OSSL_SELF_TEST_TYPE_KAT_KEM)

Known answer test for key encapsulation.

"DRBG" (OSSL_SELF_TEST_TYPE_DRBG)

Known answer test for a Deterministic Random Bit Generator.

"Conditional_PCT" (OSSL_SELF_TEST_TYPE_PCT)

Conditional test that is run during the generation of key pairs.

"Import_PCT" (OSSL_SELF_TEST_TYPE_PCT_IMPORT)

Conditional test that is run during the import of key pairs.

"Conditional_KAT" (OSSL_SELF_TEST_TYPE_PCT_KAT)

Conditional test run during generation that derive the public key from the private key and checks that the public key matches. This is a SP 800-56A requirement.

"Continuous_RNG_Test" (OSSL_SELF_TEST_TYPE_CRNG)

Continuous random number generator test.

"Install_Integrity" (OSSL_SELF_TEST_TYPE_INSTALL_INTEGRITY)

This is deprecated. The option is no longer used since FIPS 140-3 requires self tests to always run on startup. Previous FIPS 140-2 validations allowed the self tests to be run just once.

The FIPS module passes the following descriptions(s) to OSSL_SELF_TEST_onbegin().

"HMAC" (OSSL_SELF_TEST_DESC_INTEGRITY_HMAC)

"Module_Integrity" uses this.

"RSA" (OSSL_SELF_TEST_DESC_PCT_RSA_PKCS1)

"RSA" (OSSL_SELF_TEST_DESC_PCT_RSA)

"ECDSA" (OSSL_SELF_TEST_DESC_PCT_ECDSA)

"EDDSA" (OSSL_SELF_TEST_DESC_PCT_EDDSA)

"DSA" (OSSL_SELF_TEST_DESC_PCT_DSA)

"ML-DSA" (OSSL_SELF_TEST_DESC_PCT_ML_DSA)

"ML-KEM" (OSSL_SELF_TEST_DESC_PCT_ML_KEM)

"SLH-DSA" (OSSL_SELF_TEST_DESC_PCT_SLH_DSA)

Key generation tests used with the "Pairwise_Consistency_Test" type.

"RSA_Encrypt" (OSSL_SELF_TEST_DESC_ASYM_RSA_ENC)

"RSA_Decrypt" (OSSL_SELF_TEST_DESC_ASYM_RSA_DEC)

"KAT_AsymmetricCipher" uses this to indicate an encrypt or decrypt KAT.

"ML-DSA" (OSSL_SELF_TEST_DESC_KEYGEN_ML_DSA)

"ML-KEM" (OSSL_SELF_TEST_DESC_KEYGEN_ML_KEM)

"SLH-DSA" (OSSL_SELF_TEST_DESC_KEYGEN_SLH_DSA)

"KAT_AsymmetricKeyGeneration" uses this to indicate a key generation KAT.

"AES_GCM" (OSSL_SELF_TEST_DESC_CIPHER_AES_GCM)

"AES_ECB_Decrypt" (OSSL_SELF_TEST_DESC_CIPHER_AES_ECB)

"TDES" (OSSL_SELF_TEST_DESC_CIPHER_TDES)

Symmetric cipher tests used with the "KAT_Cipher" type.

"SHA1" (OSSL_SELF_TEST_DESC_MD_SHA1)

"SHA2" (OSSL_SELF_TEST_DESC_MD_SHA2)

"SHA3" (OSSL_SELF_TEST_DESC_MD_SHA3)

Digest tests used with the "KAT_Digest" type.

"DSA" (OSSL_SELF_TEST_DESC_SIGN_DSA)

"RSA" (OSSL_SELF_TEST_DESC_SIGN_RSA)

"ECDSA" (OSSL_SELF_TEST_DESC_SIGN_ECDSA)

"EDDSA" (OSSL_SELF_TEST_DESC_SIGN_EDDSA)

"ML-DSA" (OSSL_SELF_TEST_DESC_SIGN_ML_DSA)

"SLH-DSA" (OSSL_SELF_TEST_DESC_SIGN_SLH_DSA)

Signature tests used with the "KAT_Signature" type.

"ECDH" (OSSL_SELF_TEST_DESC_KA_ECDH)

"DH" (OSSL_SELF_TEST_DESC_KA_DH)

Key agreement tests used with the "KAT_KA" type.

"HKDF" (OSSL_SELF_TEST_DESC_KDF_HKDF)

"TLS13_KDF_EXTRACT" (OSSL_SELF_TEST_DESC_KDF_TLS13_EXTRACT)

"TLS13_KDF_EXPAND" (OSSL_SELF_TEST_DESC_KDF_TLS13_EXPAND)

"SSKDF" (OSSL_SELF_TEST_DESC_KDF_SSKDF)

"X963KDF" (OSSL_SELF_TEST_DESC_KDF_X963KDF)

"X942KDF" (OSSL_SELF_TEST_DESC_KDF_X942KDF)

"PBKDF2" (OSSL_SELF_TEST_DESC_KDF_PBKDF2)

"SSHKDF" (OSSL_SELF_TEST_DESC_KDF_SSHKDF)

"TLS12_PRF" (OSSL_SELF_TEST_DESC_KDF_TLS12_PRF)

"KBKDF" (OSSL_SELF_TEST_DESC_KDF_KBKDF)

Key Encapsulation Function tests used with the "KAT_KEM" type.

"KEM_Encap" (OSSL_SELF_TEST_DESC_ENCAP_KEM)

"KEM_Decap" (OSSL_SELF_TEST_DESC_DECAP_KEM)

"KEM_Decap_Reject" (OSSL_SELF_TEST_DESC_DECAP_REJ_KEM)

Key Derivation Function tests used with the "KAT_KDF" type.

"CTR" (OSSL_SELF_TEST_DESC_DRBG_CTR)

"HASH" (OSSL_SELF_TEST_DESC_DRBG_HASH)

"HMAC" (OSSL_SELF_TEST_DESC_DRBG_HMAC)

DRBG tests used with the "DRBG" type.

"RNG" (OSSL_SELF_TEST_DESC_RNG)

"Continuous_RNG_Test" uses this.

## EXAMPLES
A simple self test callback is shown below for illustrative purposes.

```
  #include <openssl/self_test.h>
  static OSSL_CALLBACK self_test_cb;
  static int self_test_cb(const OSSL_PARAM params[], void *arg)
  {
    int ret = 0;
    const OSSL_PARAM *p = NULL;
    const char *phase = NULL, *type = NULL, *desc = NULL;
    p = OSSL_PARAM_locate_const(params, OSSL_PROV_PARAM_SELF_TEST_PHASE);
    if (p == NULL || p->data_type != OSSL_PARAM_UTF8_STRING)
        goto err;
    phase = (const char *)p->data;
    p = OSSL_PARAM_locate_const(params, OSSL_PROV_PARAM_SELF_TEST_DESC);
    if (p == NULL || p->data_type != OSSL_PARAM_UTF8_STRING)
        goto err;
    desc = (const char *)p->data;
    p = OSSL_PARAM_locate_const(params, OSSL_PROV_PARAM_SELF_TEST_TYPE);
    if (p == NULL || p->data_type != OSSL_PARAM_UTF8_STRING)
        goto err;
    type = (const char *)p->data;
    /* Do some logging */
    if (strcmp(phase, OSSL_SELF_TEST_PHASE_START) == 0)
        BIO_printf(bio_out, "%s : (%s) : ", desc, type);
    if (strcmp(phase, OSSL_SELF_TEST_PHASE_PASS) == 0
            || strcmp(phase, OSSL_SELF_TEST_PHASE_FAIL) == 0)
        BIO_printf(bio_out, "%s\n", phase);
    /* Corrupt the SHA1 self test during the 'corrupt' phase by returning 0 */
    if (strcmp(phase, OSSL_SELF_TEST_PHASE_CORRUPT) == 0
            && strcmp(desc, OSSL_SELF_TEST_DESC_MD_SHA1) == 0) {
        BIO_printf(bio_out, "%s %s", phase, desc);
        return 0;
    }
    ret = 1;
  err:
    return ret;
  }
```

## NOTES
Some released versions of OpenSSL do not include a validated FIPS provider. To determine which versions have undergone the validation process, please refer to the OpenSSL Downloads page <https://www.openssl.org/source/>. If you require FIPS-approved functionality, it is essential to build your FIPS provider using one of the validated versions listed there. Normally, it is possible to utilize a FIPS provider constructed from one of the validated versions alongside libcrypto and libssl compiled from any release within the same major release series. This flexibility enables you to address bug fixes and CVEs that fall outside the FIPS boundary.

You can load the FIPS provider into multiple library contexts as any other provider. However the following restriction applies. The FIPS provider cannot be used by multiple copies of OpenSSL libcrypto in a single process.

As the provider saves core callbacks to the libcrypto obtained in the OSSL_provider_init() call to global data it will fail if subsequent invocations of its OSSL_provider_init() function yield different addresses of these callbacks than in the initial call. This happens when different copies of libcrypto are present in the memory of the process and both try to load the same FIPS provider. A workaround is to have a different copy of the FIPS provider loaded for each of the libcrypto instances in the process.

## SEE ALSO
openssl-fipsinstall(1), fips_config(5), OSSL_SELF_TEST_set_callback(3), OSSL_SELF_TEST_new(3), OSSL_PARAM(3), openssl-core.h(7), openssl-core_dispatch.h(7), provider(7), <https://www.openssl.org/source/>

## HISTORY
This functionality was added in OpenSSL 3.0.

## COPYRIGHT
Copyright 2019-2025 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: OSSL_PROVIDER-base(7ossl)

summary: OpenSSL base provider

text:
# OSSL_PROVIDER-base(7ossl)

## NAME
OSSL_PROVIDER-base - OpenSSL base provider

## DESCRIPTION
The OpenSSL base provider supplies the encoding for OpenSSL's asymmetric cryptography.

### Properties
The implementations in this provider specifically have this property defined:

"provider=base"

It may be used in a property query string with fetching functions.

It isn't mandatory to query for this property, except to make sure to get implementations of this provider and none other.

"type=parameters"

"type=private"

"type=public"

These may be used in a property query string with fetching functions to select which data are to be encoded. Either the private key material, the public key material or the domain parameters can be selected.

"format=der"

"format=pem"

"format=text"

These may be used in a property query string with fetching functions to select the encoding output format. Either the DER, PEM and plaintext are currently permitted.

## OPERATIONS AND ALGORITHMS
The OpenSSL base provider supports these operations and algorithms:

### Random Number Generation
SEED-SRC, see EVP_RAND-SEED-SRC(7)

JITTER, see EVP_RAND-JITTER(7)

In addition to this provider, the "SEED-SRC" and "JITTER" algorithms are also available in the default provider.

### Asymmetric Key Encoder
RSA

RSA-PSS

DH

DHX

DSA

EC

ED25519

ED448

X25519

X448

SM2

ML-DSA-44

ML-DSA-65

ML-DSA-87

ML-KEM-512

ML-KEM-768

ML-KEM-1024

SLH-DSA-SHA2-128s

SLH-DSA-SHA2-128f

SLH-DSA-SHA2-192s

SLH-DSA-SHA2-192f

SLH-DSA-SHA2-256s

SLH-DSA-SHA2-256f

SLH-DSA-SHAKE-128s

SLH-DSA-SHAKE-128f

SLH-DSA-SHAKE-192s

SLH-DSA-SHAKE-192f

SLH-DSA-SHAKE-256s

SLH-DSA-SHAKE-256f

In addition to this provider, all of these encoding algorithms are also available in the default provider. Some of these algorithms may be used in combination with the FIPS provider.

### Asymmetric Key Decoder
RSA

RSA-PSS

DH

DHX

DSA

EC

ED25519

ED448

X25519

X448

SM2

DER

ML-DSA-44

ML-DSA-65

ML-DSA-87

ML-KEM-512

ML-KEM-768

ML-KEM-1024

SLH-DSA-SHA2-128s

SLH-DSA-SHA2-128f

SLH-DSA-SHA2-192s

SLH-DSA-SHA2-192f

SLH-DSA-SHA2-256s

SLH-DSA-SHA2-256f

SLH-DSA-SHAKE-128s

SLH-DSA-SHAKE-128f

SLH-DSA-SHAKE-192s

SLH-DSA-SHAKE-192f

SLH-DSA-SHAKE-256s

SLH-DSA-SHAKE-256f

In addition to this provider, all of these decoding algorithms are also available in the default provider. Some of these algorithms may be used in combination with the FIPS provider.

### Stores
file

org.openssl.winstore, see OSSL_STORE-winstore(7)

In addition to this provider, all of these store algorithms are also available in the default provider.

## SEE ALSO
OSSL_PROVIDER-default(7), openssl-core.h(7), openssl-core_dispatch.h(7), provider(7)

## HISTORY
This functionality was added in OpenSSL 3.0.

Support for ML-DSA and <ML-KEM> was added in OpenSSL 3.5.

## COPYRIGHT
Copyright 2020-2025 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: OSSL_PROVIDER-default(7ossl)

summary: OpenSSL default provider

text:
# OSSL_PROVIDER-default(7ossl)

## NAME
OSSL_PROVIDER-default - OpenSSL default provider

## DESCRIPTION
The OpenSSL default provider supplies the majority of OpenSSL's diverse algorithm implementations. If an application doesn't specify anything else explicitly (e.g. in the application or via config), then this is the provider that will be used as fallback: It is loaded automatically the first time that an algorithm is fetched from a provider or a function acting on providers is called and no other provider has been loaded yet.

If an attempt to load a provider has already been made (whether successful or not) then the default provider won't be loaded automatically. Therefore if the default provider is to be used in conjunction with other providers then it must be loaded explicitly. Automatic loading of the default provider only occurs a maximum of once; if the default provider is explicitly unloaded then the default provider will not be automatically loaded again.

### Properties
The implementations in this provider specifically have this property defined:

"provider=default"

It may be used in a property query string with fetching functions such as EVP_MD_fetch(3) or EVP_CIPHER_fetch(3), as well as with other functions that take a property query string, such as EVP_PKEY_CTX_new_from_name(3).

It isn't mandatory to query for this property, except to make sure to get implementations of this provider and none other.

Some implementations may define additional properties. Exact information is listed below

## OPERATIONS AND ALGORITHMS
The OpenSSL default provider supports these operations and algorithms:

### Hashing Algorithms / Message Digests
SHA1, see EVP_MD-SHA1(7)

SHA2, see EVP_MD-SHA2(7)

SHA3, see EVP_MD-SHA3(7)

KECCAK, see EVP_MD-KECCAK(7)

KECCAK-KMAC, see EVP_MD-KECCAK-KMAC(7)

SHAKE, see EVP_MD-SHAKE(7)

BLAKE2, see EVP_MD-BLAKE2(7)

SM3, see EVP_MD-SM3(7)

MD5, see EVP_MD-MD5(7)

MD5-SHA1, see EVP_MD-MD5-SHA1(7)

RIPEMD160, see EVP_MD-RIPEMD160(7)

NULL, see EVP_MD-NULL(7)

### Symmetric Ciphers
AES, see EVP_CIPHER-AES(7)

ARIA, see EVP_CIPHER-ARIA(7)

CAMELLIA, see EVP_CIPHER-CAMELLIA(7)

3DES, see EVP_CIPHER-DES(7)

SM4, see EVP_CIPHER-SM4(7)

ChaCha20, see EVP_CIPHER-CHACHA(7)

ChaCha20-Poly1305, see EVP_CIPHER-CHACHA(7)

NULL, see EVP_CIPHER-NULL(7)

### Message Authentication Code (MAC)
BLAKE2, see EVP_MAC-BLAKE2(7)

CMAC, see EVP_MAC-CMAC(7)

GMAC, see EVP_MAC-GMAC(7)

HMAC, see EVP_MAC-HMAC(7)

KMAC, see EVP_MAC-KMAC(7)

SIPHASH, see EVP_MAC-Siphash(7)

POLY1305, see EVP_MAC-Poly1305(7)

### Key Derivation Function (KDF)
HKDF, see EVP_KDF-HKDF(7)

TLS13-KDF, see EVP_KDF-TLS13_KDF(7)

SSKDF, see EVP_KDF-SS(7)

PBKDF2, see EVP_KDF-PBKDF2(7)

PKCS12KDF, see EVP_KDF-PKCS12KDF(7)

SSHKDF, see EVP_KDF-SSHKDF(7)

TLS1-PRF, see EVP_KDF-TLS1_PRF(7)

KBKDF, see EVP_KDF-KB(7)

X942KDF-ASN1, see EVP_KDF-X942-ASN1(7)

X942KDF-CONCAT, see EVP_KDF-X942-CONCAT(7)

X963KDF, see EVP_KDF-X963(7)

SCRYPT, see EVP_KDF-SCRYPT(7)

KRB5KDF, see EVP_KDF-KRB5KDF(7)

HMAC-DRBG, see EVP_KDF-HMAC-DRBG(7)

ARGON2, see EVP_KDF-ARGON2(7)

### Key Exchange
DH, see EVP_KEYEXCH-DH(7)

ECDH, see EVP_KEYEXCH-ECDH(7)

X25519, see EVP_KEYEXCH-X25519(7)

X448, see EVP_KEYEXCH-X448(7)

ML-KEM-512, see EVP_KEM-ML-KEM-512(7)

ML-KEM-768, see EVP_KEM-ML-KEM-768(7)

ML-KEM-1024, see EVP_KEM-ML-KEM-1024(7)

TLS1-PRF

HKDF

SCRYPT

### Asymmetric Signature
DSA, see EVP_SIGNATURE-DSA(7)

RSA, see EVP_SIGNATURE-RSA(7)

ED25519, see EVP_SIGNATURE-ED25519(7)

ED448, see EVP_SIGNATURE-ED448(7)

ECDSA, see EVP_SIGNATURE-ECDSA(7)

SM2

ML-DSA-44, see EVP_SIGNATURE-ML-DSA(7)

ML-DSA-65, see EVP_SIGNATURE-ML-DSA(7)

ML-DSA-87, see EVP_SIGNATURE-ML-DSA(7)

HMAC, see EVP_SIGNATURE-HMAC(7)

SIPHASH, see EVP_SIGNATURE-Siphash(7)

POLY1305, see EVP_SIGNATURE-Poly1305(7)

CMAC, see EVP_SIGNATURE-CMAC(7)

SLH-DSA-SHA2-128s, see EVP_SIGNATURE-SLH-DSA(7)

SLH-DSA-SHA2-128f, see EVP_SIGNATURE-SLH-DSA(7)

SLH-DSA-SHA2-192s, see EVP_SIGNATURE-SLH-DSA(7)

SLH-DSA-SHA2-192f, see EVP_SIGNATURE-SLH-DSA(7)

SLH-DSA-SHA2-256s, see EVP_SIGNATURE-SLH-DSA(7)

SLH-DSA-SHA2-256f, see EVP_SIGNATURE-SLH-DSA(7)

SLH-DSA-SHAKE-128s, see EVP_SIGNATURE-SLH-DSA(7)

SLH-DSA-SHAKE-128f, see EVP_SIGNATURE-SLH-DSA(7)

SLH-DSA-SHAKE-192s, see EVP_SIGNATURE-SLH-DSA(7)

SLH-DSA-SHAKE-192f, see EVP_SIGNATURE-SLH-DSA(7)

SLH-DSA-SHAKE-256s, see EVP_SIGNATURE-SLH-DSA(7)

SLH-DSA-SHAKE-256f, see EVP_SIGNATURE-SLH-DSA(7)

### Asymmetric Cipher
RSA, see EVP_ASYM_CIPHER-RSA(7)

SM2, see EVP_ASYM_CIPHER-SM2(7)

### Asymmetric Key Encapsulation
RSA, see EVP_KEM-RSA(7)

X25519, see EVP_KEM-X25519(7)

X448, see EVP_KEM-X448(7)

EC, see EVP_KEM-EC(7)

ML-KEM-512, see EVP_KEM-ML-KEM-512(7)

ML-KEM-768, see EVP_KEM-ML-KEM-768(7)

ML-KEM-1024, see EVP_KEM-ML-KEM-1024(7)

### Asymmetric Key Management
DSA, see EVP_KEYMGMT-DSA(7)

RSA, see EVP_KEYMGMT-RSA(7)

RSA-PSS

EC, see EVP_KEYMGMT-EC(7)

ED25519, see EVP_KEYMGMT-ED25519(7)

ED448, see EVP_KEYMGMT-ED448(7)

SM2, see EVP_KEYMGMT-SM2(7)

DH, see EVP_KEYMGMT-DH(7)

DHX, see EVP_KEYMGMT-DHX(7)

X25519, see EVP_KEYMGMT-X25519(7)

X448, see EVP_KEYMGMT-X448(7)

ML-DSA-44, see EVP_KEYMGMT-ML-DSA(7)

ML-DSA-65, see EVP_KEYMGMT-ML-DSA(7)

ML-DSA-87, see EVP_KEYMGMT-ML-DSA(7)

MK-KEM-512, see EVP_KEYMGMT-ML-KEM-512(7)

MK-KEM-768, see EVP_KEYMGMT-ML-KEM-768(7)

MK-KEM-1024, see EVP_KEYMGMT-ML-KEM-1024(7)

SLH-DSA-SHA2-128s, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHA2-128f, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHA2-192s, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHA2-192f, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHA2-256s, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHA2-256f, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHAKE-128s, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHAKE-128f, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHAKE-192s, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHAKE-192f, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHAKE-256s, see EVP_KEYMGMT-SLH-DSA(7)

SLH-DSA-SHAKE-256f, see EVP_KEYMGMT-SLH-DSA(7)

TLS1-PRF

HKDF

SCRYPT

HMAC, see EVP_KEYMGMT-HMAC(7)

SIPHASH, see EVP_KEYMGMT-Siphash(7)

POLY1305, see EVP_KEYMGMT-Poly1305(7)

CMAC, see EVP_KEYMGMT-CMAC(7)

### Random Number Generation
CTR-DRBG, see EVP_RAND-CTR-DRBG(7)

HASH-DRBG, see EVP_RAND-HASH-DRBG(7)

HMAC-DRBG, see EVP_RAND-HMAC-DRBG(7)

SEED-SRC, see EVP_RAND-SEED-SRC(7)

JITTER, see EVP_RAND-JITTER(7)

TEST-RAND, see EVP_RAND-TEST-RAND(7)

In addition to this provider, the "SEED-SRC" and "JITTER" algorithms are also available in the base provider.

### Asymmetric Key Encoder
RSA

RSA-PSS

DH

DHX

DSA

EC

ED25519

ED448

X25519

X448

SM2

ML-DSA-44

ML-DSA-65

ML-DSA-87

ML-KEM-512

ML-KEM-768

ML-KEM-1024

SLH-DSA-SHA2-128s

SLH-DSA-SHA2-128f

SLH-DSA-SHA2-192s

SLH-DSA-SHA2-192f

SLH-DSA-SHA2-256s

SLH-DSA-SHA2-256f

SLH-DSA-SHAKE-128s

SLH-DSA-SHAKE-128f

SLH-DSA-SHAKE-192s

SLH-DSA-SHAKE-192f

SLH-DSA-SHAKE-256s

SLH-DSA-SHAKE-256f

In addition to this provider, all of these encoding algorithms are also available in the base provider. Some of these algorithms may be used in combination with the FIPS provider.

### Asymmetric Key Decoder
RSA

RSA-PSS

DH

DHX

DSA

EC

ED25519

ED448

X25519

X448

SM2

ML-DSA-44

ML-DSA-65

ML-DSA-87

ML-KEM-512

ML-KEM-768

ML-KEM-1024

SLH-DSA-SHA2-128s

SLH-DSA-SHA2-128f

SLH-DSA-SHA2-192s

SLH-DSA-SHA2-192f

SLH-DSA-SHA2-256s

SLH-DSA-SHA2-256f

SLH-DSA-SHAKE-128s

SLH-DSA-SHAKE-128f

SLH-DSA-SHAKE-192s

SLH-DSA-SHAKE-192f

SLH-DSA-SHAKE-256s

SLH-DSA-SHAKE-256f

In addition to this provider, all of these decoding algorithms are also available in the base provider. Some of these algorithms may be used in combination with the FIPS provider.

### Stores
file

org.openssl.winstore, see OSSL_STORE-winstore(7)

In addition to this provider, all of these store algorithms are also available in the base provider.

## SEE ALSO
openssl-core.h(7), openssl-core_dispatch.h(7), provider(7), OSSL_PROVIDER-base(7)

## HISTORY
The RIPEMD160 digest was added to the default provider in OpenSSL 3.0.7.

All other functionality was added in OpenSSL 3.0.

## COPYRIGHT
Copyright 2020-2025 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: OSSL_PROVIDER-legacy(7ossl)

summary: OpenSSL legacy provider

text:
# OSSL_PROVIDER-legacy(7ossl)

## NAME
OSSL_PROVIDER-legacy - OpenSSL legacy provider

## DESCRIPTION
The OpenSSL legacy provider supplies OpenSSL implementations of algorithms that have been deemed legacy. Such algorithms have commonly fallen out of use, have been deemed insecure by the cryptography community, or something similar.

We can consider this the retirement home of cryptographic algorithms.

### Properties
The implementations in this provider specifically has this property defined:

"provider=legacy"

It may be used in a property query string with fetching functions such as EVP_MD_fetch(3) or EVP_CIPHER_fetch(3), as well as with other functions that take a property query string, such as EVP_PKEY_CTX_new_from_name(3).

It isn't mandatory to query for any of these properties, except to make sure to get implementations of this provider and none other.

## OPERATIONS AND ALGORITHMS
The OpenSSL legacy provider supports these operations and algorithms:

### Hashing Algorithms / Message Digests
MD2, see EVP_MD-MD2(7)

Disabled by default. Use enable-md2 config option to enable.

MD4, see EVP_MD-MD4(7)

MDC2, see EVP_MD-MDC2(7)

WHIRLPOOL, see EVP_MD-WHIRLPOOL(7)

RIPEMD160, see EVP_MD-RIPEMD160(7)

### Symmetric Ciphers
Not all of these symmetric cipher algorithms are enabled by default.

Blowfish, see EVP_CIPHER-BLOWFISH(7)

CAST, see EVP_CIPHER-CAST(7)

DES, see EVP_CIPHER-DES(7)

The algorithm names are: DES_ECB, DES_CBC, DES_OFB, DES_CFB, DES_CFB1, DES_CFB8 and DESX_CBC.

IDEA, see EVP_CIPHER-IDEA(7)

RC2, see EVP_CIPHER-RC2(7)

RC4, see EVP_CIPHER-RC4(7)

RC5, see EVP_CIPHER-RC5(7)

Disabled by default. Use enable-rc5 config option to enable.

SEED, see EVP_CIPHER-SEED(7)

### Key Derivation Function (KDF)
PBKDF1

PVKKDF

## SEE ALSO
OSSL_PARAM(3), openssl-core.h(7), openssl-core_dispatch.h(7), provider(7)

## HISTORY
This functionality was added in OpenSSL 3.0.

## COPYRIGHT
Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: OSSL_PROVIDER-null(7ossl)

summary: OpenSSL null provider

text:
# OSSL_PROVIDER-null(7ossl)

## NAME
OSSL_PROVIDER-null - OpenSSL null provider

## DESCRIPTION
The OpenSSL null provider supplies no algorithms.

It can used to guarantee that the default library context and a fallback provider will not be accidentally accessed.

### Properties
The null provider defines no properties.

## OPERATIONS AND ALGORITHMS
The OpenSSL null provider supports no operations and algorithms.

## SEE ALSO
provider(7)

## HISTORY
This functionality was added in OpenSSL 3.0.

## COPYRIGHT
Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


title: OSSL_STORE-winstore(7ossl)

summary: OpenSSL built in OSSL_STORE for Windows

text:
# OSSL_STORE-winstore(7ossl)

## NAME
OSSL_STORE-winstore - OpenSSL built in OSSL_STORE for Windows

## DESCRIPTION
The OSSL_STORE implementation for Windows provides access to Windows' system "ROOT" certificate store through URIs, using the URI scheme "org.openssl.winstore".

### Supported URIs
There is only one supported URI:

```
  org.openssl.winstore:
```

No authority (host, etc), no path, no query, no fragment.

### Supported OSSL_STORE_SEARCH operations
OSSL_STORE_SEARCH_by_name(3)

As a matter of fact, this must be used. It is not possible to enumerate all available certificates in the store.

### Windows certificate store features
Apart from diverse constraints present in the certificates themselves, the Windows certificate store also has the ability to associate additional constraining properties alongside a certificate in the store. This includes both documented and undocumented capabilities:

- The documented capability to override EKU

- The undocumented capability to add name constraints

- The undocumented capability to override the certificate expiry date

Such constraints are not checked by this OSSL_STORE implementation, and thereby not honoured.

However, once extracted with OSSL_STORE_load(3), certificates that have constraints in their X.509 extensions will go through the usual constraint checks when used by OpenSSL, and are thereby honoured.

## SEE ALSO
ossl_store(7), OSSL_STORE_open_ex(3), OSSL_STORE_SEARCH(3)

## HISTORY
The winstore ("org.openssl.winstore") implementation was added in OpenSSL 3.2.0.

## NOTES
OpenSSL uses OSSL_DECODER(3) implementations under the hood. To influence what OSSL_DECODER(3) implementations are used, it's advisable to use OSSL_STORE_open_ex(3) and set the propq argument.

## COPYRIGHT
Copyright 2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.