PROVIDER-RAND(7ossl)

πŸ“¦ version 3.5.0, in opensuse-leap 16.0

πŸ’– NAME πŸ’–

okay so bestie, welcome to provider-rand β€” that's provider-rand(7ossl) if you're being all formal about it β€” and it's literally the random number generation library ↔ provider functions. that's the whole vibe. it's the page that tells your provider how to be the source of all randomness, the main character of entropy, the one everybody's asking for numbers at 3am. 🎲✨


✨ SYNOPSIS ✨

here's the whole thing, and ngl it's a lot of function-pointer energy. no cap, i'm putting it here exactly as it lives:

#include <openssl/core_dispatch.h>
#include <openssl/core_names.h>

/*
 * None of these are actual functions, but are displayed like this for
 * the function signatures for functions that are offered as function
 * pointers in OSSL_DISPATCH arrays.
 */

/* Context management */
void *OSSL_FUNC_rand_newctx(void *provctx, void *parent,
                            const OSSL_DISPATCH *parent_calls);
void OSSL_FUNC_rand_freectx(void *ctx);

/* Random number generator functions: NIST */
int OSSL_FUNC_rand_instantiate(void *ctx, unsigned int strength,
                               int prediction_resistance,
                               const unsigned char *pstr, size_t pstr_len,
                               const OSSL_PARAM params[]);
int OSSL_FUNC_rand_uninstantiate(void *ctx);
int OSSL_FUNC_rand_generate(void *ctx, unsigned char *out, size_t outlen,
                            unsigned int strength, int prediction_resistance,
                            const unsigned char *addin, size_t addin_len);
int OSSL_FUNC_rand_reseed(void *ctx, int prediction_resistance,
                          const unsigned char *ent, size_t ent_len,
                          const unsigned char *addin, size_t addin_len);

/* Random number generator functions: additional */
size_t OSSL_FUNC_rand_nonce(void *ctx, unsigned char *out, size_t outlen,
                            int strength, size_t min_noncelen,
                            size_t max_noncelen);
size_t OSSL_FUNC_rand_get_seed(void *ctx, unsigned char **buffer,
                               int entropy, size_t min_len, size_t max_len,
                               int prediction_resistance,
                               const unsigned char *adin, size_t adin_len);
void OSSL_FUNC_rand_clear_seed(void *ctx, unsigned char *buffer, size_t b_len);
int OSSL_FUNC_rand_verify_zeroization(void *ctx);

/* Context Locking */
int OSSL_FUNC_rand_enable_locking(void *ctx);
int OSSL_FUNC_rand_lock(void *ctx);
void OSSL_FUNC_rand_unlock(void *ctx);

/* RAND parameter descriptors */
const OSSL_PARAM *OSSL_FUNC_rand_gettable_params(void *provctx);
const OSSL_PARAM *OSSL_FUNC_rand_gettable_ctx_params(void *ctx, void *provctx);
const OSSL_PARAM *OSSL_FUNC_rand_settable_ctx_params(void *ctx, void *provctx);

/* RAND parameters */
int OSSL_FUNC_rand_get_params(OSSL_PARAM params[]);
int OSSL_FUNC_rand_get_ctx_params(void *ctx, OSSL_PARAM params[]);
int OSSL_FUNC_rand_set_ctx_params(void *ctx, const OSSL_PARAM params[]);

the one thing you gotta internalise, bestie, is that comment at the top: none of these are actual functions. they're displayed like this so you can read the function signatures for the functions that get offered as function pointers inside OSSL_DISPATCH arrays. so it's like a lookbook, not an actual wardrobe. πŸ’…


in this part we've got the context management pair (OSSL_FUNC_rand_newctx and OSSL_FUNC_rand_freectx), the NIST RNG crew (instantiate, uninstantiate, generate, reseed), the additional RNG functions (nonce, get_seed, clear_seed, verify_zeroization), the context locking trio (enable_locking, lock, unlock), the RAND parameter descriptors (gettable_params, gettable_ctx_params, settable_ctx_params), and then the RAND parameters themselves (get_params, get_ctx_params, set_ctx_params). πŸ¦‹

and yes, every single one of them takes an OSSL_PARAM array somewhere, because of course it does. it's giving ✨consistency✨. πŸŽ€

ngl this is only the beginning β€” keep reading bestie, there's more of this page and we're not done yet. 🫢

πŸ’– DESCRIPTION πŸ’–

okay so this page is primarily for provider authors, bestie β€” that's the target audience. If you want the bigger picture, go read provider(7) ✨

The RAND operation is what lets providers implement random number generation algorithms and random number sources, and then serve them up to applications through the API function EVP_RAND(3). That's the whole vibe. πŸŽ€


🧚 Context Management Functions 🧚

  • OSSL_FUNC_rand_newctx() β€” this one should create and return a pointer to a provider-side structure that holds all the context info during a rand operation. That context pointer gets passed back to you in a bunch of the other rand operation function calls, so keep it safe πŸ’…

The parameter provctx is the provider context that got generated during provider initialisation (peep provider(7) for that). The parameter parent specifies another rand instance to be used for seeding purposes β€” and if it's NULL and this specific instance supports it, the operating system will be used for seeding instead. Iconic. The parameter parent_calls points to the dispatch table for parent, which means the parent sooo doesn't need to be from the same provider as the new instance. cross-provider friendship slay 🫢

  • OSSL_FUNC_rand_freectx() β€” gets handed a pointer to the provider side rand context in the mctx parameter. If it receives NULL as the ctx value, it should not do anything other than return (literally just return, no extra credit). Otherwise, this function should free any resources associated with that context.

πŸ”₯ Random Number Generator Functions: NIST πŸ”₯

These functions correspond to those defined in NIST SP 800-90A and SP 800-90C. fancy πŸ’…

  • OSSL_FUNC_rand_instantiate() β€” used to instantiate the DRBG ctx at a requested security strength. On top of that, prediction_resistance can be requested. Additional input addin of length addin_len bytes can optionally be provided. The parameters specified in params configure the DRBG, and ngl these should be processed before instantiation. order matters bestie.
  • OSSL_FUNC_rand_uninstantiate() β€” used to uninstantiate the DRBG ctx. And once a DRBG is uninstantiated, it is unable to produce output until it is instantiated anew. it's giving "closed for business" 😭
  • OSSL_FUNC_rand_generate() β€” used to generate random bytes from the DRBG ctx. It will generate outlen bytes and place them into the buffer pointed to by out. The generated bytes will meet the specified security strength and, if prediction_resistance is true, the bytes will be produced after reseeding from a live entropy source. Additional input addin of length addin_len bytes can optionally be provided.

🌈 Random Number Generator Functions: Additional 🌈

  • OSSL_FUNC_rand_nonce() β€” used to generate a nonce of the given strength with a length from min_noncelen to max_noncelen. If the output buffer out is NULL, then the length of the nonce should be returned. sneaky little length check, love that for us ✨
  • OSSL_FUNC_rand_get_seed() β€” deterministic generators use this to obtain their seeding material from their parent. The seed bytes will meet the specified security level of entropy bits, and there will be between min_len and max_len inclusive bytes in total. If prediction_resistance is true, the bytes will be produced from a live entropy source. Additional input addin of length addin_len bytes can optionally be provided. A pointer to the seed material is returned in *buffer, and this must be freed by a later call to OSSL_FUNC_rand_clear_seed(). don't forget, or it's a leak, and leaks are NOT the moment πŸ’€
  • OSSL_FUNC_rand_clear_seed() β€” frees a seed buffer of length b_len bytes which was previously allocated by OSSL_FUNC_rand_get_seed().
  • OSSL_FUNC_rand_verify_zeroization() β€” used to determine if the internal state of the DRBG is zero. This capability is mandated by NIST as part of the self tests, and it is unlikely to be useful in other circumstances. genuinely just a self-test thing, no cap.

πŸ¦‹ Context Locking πŸ¦‹

When DRBGs are used by multiple threads, there must be locking employed to ensure their proper operation. But because locking introduces an overhead, it is disabled by default. (the tradeoff is real πŸ™ˆ)

  • OSSL_FUNC_rand_enable_locking() β€” allows locking to be turned on for a DRBG and all of its parent DRBGs. From this call onwards, the DRBG can be used in a thread safe manner. main character energy for your threads πŸ‘‘
  • OSSL_FUNC_rand_lock() β€” used to lock a DRBG. Once locked, exclusive access is guaranteed. nobody else gets in, periodt.
  • OSSL_FUNC_rand_unlock() β€” used to unlock a DRBG.

🌸 Rand Parameters 🌸

See OSSL_PARAM(3) for further details on the parameters structure used by these functions.

  • OSSL_FUNC_rand_get_params() β€” gets details of parameter values associated with the provider algorithm and stores them in params.
  • OSSL_FUNC_rand_set_ctx_params() β€” sets rand parameters associated with the given provider side rand context ctx to params. Any parameter settings are additional to any that were previously set. Passing NULL for params should return true.
  • OSSL_FUNC_rand_get_ctx_params() β€” gets details of currently set parameter values associated with the given provider side rand context ctx and stores them in params. Passing NULL for params should return true.
  • OSSL_FUNC_rand_gettable_params(), OSSL_FUNC_rand_gettable_ctx_params(), and OSSL_FUNC_rand_settable_ctx_params() β€” all three return constant OSSL_PARAM(3) arrays as descriptors of the parameters that OSSL_FUNC_rand_get_params(), OSSL_FUNC_rand_get_ctx_params(), and OSSL_FUNC_rand_set_ctx_params() can handle, respectively. OSSL_FUNC_rand_gettable_ctx_params() and OSSL_FUNC_rand_settable_ctx_params() will return the parameters associated with the provider side context ctx in its current state if it is not NULL. Otherwise, they return the parameters associated with the provider side algorithm provctx. iykyk πŸ’…

Parameters currently recognised by built-in rands are as follows. Not all parameters are relevant to, or are understood by all rands:

  • "state" (OSSL_RAND_PARAM_STATE) <integer> β€” Returns the state of the random number generator.
  • "strength" (OSSL_RAND_PARAM_STRENGTH) <unsigned integer> β€” Returns the bit strength of the random number generator.
  • "fips-indicator" (OSSL_RAND_PARAM_FIPS_APPROVED_INDICATOR) <integer> β€” A getter that returns 1 if the operation is FIPS approved, or 0 otherwise. This option is used by the OpenSSL FIPS provider and is not supported by all EVP_RAND sources.

For rands that are also deterministic random bit generators (DRBGs), these additional parameters are recognised. Not all parameters are relevant to, or are understood by all DRBG rands:

  • "reseed_requests" (OSSL_DRBG_PARAM_RESEED_REQUESTS) <unsigned integer> β€” Reads or set the number of generate requests before reseeding the associated RAND ctx.
  • "reseed_time_interval" (OSSL_DRBG_PARAM_RESEED_TIME_INTERVAL) <integer> β€” Reads or set the number of elapsed seconds before reseeding the associated RAND ctx.
  • "max_request" (OSSL_DRBG_PARAM_RESEED_REQUESTS) <unsigned integer> β€” Specifies the maximum number of bytes that can be generated in a single call to OSSL_FUNC_rand_generate.
  • "min_entropylen" (OSSL_DRBG_PARAM_MIN_ENTROPYLEN) <unsigned integer> and "max_entropylen" (OSSL_DRBG_PARAM_MAX_ENTROPYLEN) <unsigned integer> β€” Specify the minimum and maximum number of bytes of random material that can be used to seed the DRBG.
  • "min_noncelen" (OSSL_DRBG_PARAM_MIN_NONCELEN) <unsigned integer> and "max_noncelen" (OSSL_DRBG_PARAM_MAX_NONCELEN) <unsigned integer> β€” Specify the minimum and maximum number of bytes of nonce that can be used to instantiate the DRBG.
  • "max_perslen" (OSSL_DRBG_PARAM_MAX_PERSLEN) <unsigned integer> and "max_adinlen" (OSSL_DRBG_PARAM_MAX_ADINLEN) <unsigned integer> β€” Specify the minimum and maximum number of bytes of personalisation string that can be used with the DRBG.
  • "reseed_counter" (OSSL_DRBG_PARAM_RESEED_COUNTER) <unsigned integer> β€” Specifies the number of times the DRBG has been seeded or reseeded.
  • "digest" (OSSL_DRBG_PARAM_DIGEST) <UTF8 string>, "cipher" (OSSL_DRBG_PARAM_CIPHER) <UTF8 string>, and "mac" (OSSL_DRBG_PARAM_MAC) <UTF8 string> β€” Sets the name of the underlying cipher, digest or MAC to be used. It must name a suitable algorithm for the DRBG that's being used.
  • "properties" (OSSL_DRBG_PARAM_PROPERTIES) <UTF8 string> β€” Sets the properties to be queried when trying to fetch an underlying algorithm. This must be given together with the algorithm naming parameter to be considered valid. package deal, bestie πŸŽ€

The OpenSSL FIPS provider also supports the following parameters:

  • "fips-indicator" (OSSL_DRBG_PARAM_FIPS_APPROVED_INDICATOR) <integer> β€” A getter that returns 1 if the operation is FIPS approved, or 0 otherwise. This may be used after calling OSSL_FUNC_rand_generate(). It may return 0 if the "digest-check" is set to 0.
  • "digest-check" (OSSL_DRBG_PARAM_FIPS_DIGEST_CHECK) <integer> β€” If required this parameter should be set before the digest is set. The default value of 1 causes an error when the digest is set if the digest is not FIPS approved (e.g. truncated digests). Setting this to 0 will ignore the error and set the approved "fips-indicator" to 0.
⚠️ heads up: this option breaks FIPS compliance if it causes the approved "fips-indicator" to return 0. like, actually breaks it. not a vibe. πŸ’€

⭐ RETURN VALUES ⭐

  • OSSL_FUNC_rand_newctx() should return the newly created provider side rand context, or NULL on failure.
  • OSSL_FUNC_rand_gettable_params(), OSSL_FUNC_rand_gettable_ctx_params() and OSSL_FUNC_rand_settable_ctx_params() should return a constant OSSL_PARAM(3) array, or NULL if none is offered.
  • OSSL_FUNC_rand_nonce() returns the size of the generated nonce, or 0 on error.
  • OSSL_FUNC_rand_get_seed() returns the size of the generated seed, or 0 on error.
  • All of the remaining functions should return 1 for success or 0 on error. simple as that πŸ’…

πŸ› NOTES πŸ›

The RAND life-cycle is described in life_cycle-rand(7). Providers should ensure that the various transitions listed there are supported. And yeah β€” at some point the EVP layer will begin enforcing the listed transitions, so like, don't be the one caught off guard πŸ™ˆ


πŸ‘€ SEE ALSO πŸ‘€

provider(7), RAND(7), EVP_RAND(7), life_cycle-rand(7), EVP_RAND(3)


πŸ“œ HISTORY πŸ“œ

The provider RAND interface was introduced in OpenSSL 3.0. The Rand Parameters "fips-indicator" and "digest-check" were added in OpenSSL 3.4.


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


and that's the whole page, bestie 🫢 this one's from the 3.5.0 era, dated 2026-09-25, filed under PROVIDER-RAND(7ossl) β€” go forth and rand responsibly πŸŽ€βœ¨πŸ“

πŸ“¦ where this page comes from