EVP_RAND(3SSL)
π NAME π
okay bestie, this is the EVP_RAND page from the 3SSL manual (that's OpenSSL's own docs, no cap) and it's a big one so we're doing it in parts. buckle up π
so what even lives here? literally the entire EVP RAND routines family, and it's a lot of names, so let's do a roll call π
EVP_RAND,EVP_RAND_fetch,EVP_RAND_free,EVP_RAND_up_refEVP_RAND_CTX,EVP_RAND_CTX_new,EVP_RAND_CTX_free,EVP_RAND_CTX_up_refEVP_RAND_instantiate,EVP_RAND_uninstantiate,EVP_RAND_generate,EVP_RAND_reseed,EVP_RAND_nonceEVP_RAND_enable_locking,EVP_RAND_verify_zeroizationEVP_RAND_get_strength,EVP_RAND_get_stateEVP_RAND_get0_provider,EVP_RAND_CTX_get0_rand,EVP_RAND_is_a,EVP_RAND_get0_name,EVP_RAND_names_do_all,EVP_RAND_get0_descriptionEVP_RAND_CTX_get_params,EVP_RAND_CTX_set_params,EVP_RAND_do_all_provided,EVP_RAND_get_paramsEVP_RAND_gettable_ctx_params,EVP_RAND_settable_ctx_params,EVP_RAND_CTX_gettable_params,EVP_RAND_CTX_settable_params,EVP_RAND_gettable_paramsEVP_RAND_STATE_UNINITIALISED,EVP_RAND_STATE_READY,EVP_RAND_STATE_ERROR
all of those = the EVP RAND routines. yes, every single one, we're not skipping anybody π
β¨ SYNOPSIS β¨
the way you summon all of this into your file is giving:
#include <openssl/evp.h>
typedef struct evp_rand_st EVP_RAND;
typedef struct evp_rand_ctx_st EVP_RAND_CTX;
EVP_RAND *EVP_RAND_fetch(OSSL_LIB_CTX *libctx, const char *algorithm,
const char *properties);
int EVP_RAND_up_ref(EVP_RAND *rand);
void EVP_RAND_free(EVP_RAND *rand);
EVP_RAND_CTX *EVP_RAND_CTX_new(EVP_RAND *rand, EVP_RAND_CTX *parent);
void EVP_RAND_CTX_free(EVP_RAND_CTX *ctx);
int EVP_RAND_CTX_up_ref(EVP_RAND_CTX *ctx);
EVP_RAND *EVP_RAND_CTX_get0_rand(EVP_RAND_CTX *ctx);
int EVP_RAND_get_params(EVP_RAND *rand, OSSL_PARAM params[]);
int EVP_RAND_CTX_get_params(EVP_RAND_CTX *ctx, OSSL_PARAM params[]);
int EVP_RAND_CTX_set_params(EVP_RAND_CTX *ctx, const OSSL_PARAM params[]);
const OSSL_PARAM *EVP_RAND_gettable_params(const EVP_RAND *rand);
const OSSL_PARAM *EVP_RAND_gettable_ctx_params(const EVP_RAND *rand);
const OSSL_PARAM *EVP_RAND_settable_ctx_params(const EVP_RAND *rand);
const OSSL_PARAM *EVP_RAND_CTX_gettable_params(EVP_RAND_CTX *ctx);
const OSSL_PARAM *EVP_RAND_CTX_settable_params(EVP_RAND_CTX *ctx);
const char *EVP_RAND_get0_name(const EVP_RAND *rand);
const char *EVP_RAND_get0_description(const EVP_RAND *rand);
int EVP_RAND_is_a(const EVP_RAND *rand, const char *name);
const OSSL_PROVIDER *EVP_RAND_get0_provider(const EVP_RAND *rand);
void EVP_RAND_do_all_provided(OSSL_LIB_CTX *libctx,
void (*fn)(EVP_RAND *rand, void *arg),
void *arg);
int EVP_RAND_names_do_all(const EVP_RAND *rand,
void (*fn)(const char *name, void *data),
void *data);
int EVP_RAND_instantiate(EVP_RAND_CTX *ctx, unsigned int strength,
int prediction_resistance,
const unsigned char *pstr, size_t pstr_len,
const OSSL_PARAM params[]);
int EVP_RAND_uninstantiate(EVP_RAND_CTX *ctx);
int EVP_RAND_generate(EVP_RAND_CTX *ctx, unsigned char *out, size_t outlen,
unsigned int strength, int prediction_resistance,
const unsigned char *addin, size_t addin_len);
int EVP_RAND_reseed(EVP_RAND_CTX *ctx, int prediction_resistance,
const unsigned char *ent, size_t ent_len,
const unsigned char *addin, size_t addin_len);
int EVP_RAND_nonce(EVP_RAND_CTX *ctx, unsigned char *out, size_t outlen);
int EVP_RAND_enable_locking(EVP_RAND_CTX *ctx);
int EVP_RAND_verify_zeroization(EVP_RAND_CTX *ctx);
unsigned int EVP_RAND_get_strength(EVP_RAND_CTX *ctx);
int EVP_RAND_get_state(EVP_RAND_CTX *ctx);
#define EVP_RAND_STATE_UNINITIALISED 0
#define EVP_RAND_STATE_READY 1
#define EVP_RAND_STATE_ERROR 2
okay so first thing, notice those two typedefs up top, EVP_RAND and EVP_RAND_CTX β they're the two β¨iconicβ¨ opaque types you'll be passing around forever. EVP_RAND is the algorithm itself, EVP_RAND_CTX is your actual working instance of it. bestie energy: one is the recipe, the other is the cake π
and then boom, three little #defines at the bottom:
EVP_RAND_STATE_UNINITIALISEDis0EVP_RAND_STATE_READYis1EVP_RAND_STATE_ERRORis2
those are the vibes your RAND context can be in, and EVP_RAND_get_state is literally how you check which one π
πΈ to be continued, bestie β the plot thickens next part πΈ
β¨ DESCRIPTION β¨
okay bestie, gather round π the EVP RAND routines are a high-level interface to random number generators β both deterministic and not (yes, both flavors are on the menu).
But real talk first: if all you wanna do is generate some random bytes, you do not need any of this. Just call RAND_bytes() or RAND_priv_bytes() and go live your life πΈ. It's only when you want to do more than that, that you reach for these calls β and when you do, use them instead of the older RAND functions. (The old ones are giving expired milk, no cap.)
So here's the whole vibe π¦ after you create an EVP_RAND_CTX for whatever algorithm you need using EVP_RAND_CTX_new(), you feed inputs to the algorithm one of two ways:
- by passing them straight in as part of the
EVP_RAND_instantiate()call, or - by making calls to
EVP_RAND_CTX_set_params()before you callEVP_RAND_instantiate().
And then, finally, you call EVP_RAND_generate() to produce cryptographically secure random bytes. slay. π
π Types π
EVP_RANDβ a type that holds the implementation of a RAND.EVP_RAND_CTXβ a context type that holds the algorithm inputs. and bestie,EVP_RAND_CTXstructures are reference counted. periodt.
π Algorithm implementation fetching π
EVP_RAND_fetch()β fetches you an implementation of a RAND algorithm, given a library contextlibctxand a set of properties. Wanna know more? Go read "ALGORITHM FETCHING" incrypto(7). iykyk π
What you get back must eventually be freed with EVP_RAND_free(3). Don't leave it hanging, that's not cute.
EVP_RAND_up_ref()β bumps up the reference count of a RAND you already fetched. π₯EVP_RAND_free()β frees a fetched algorithm. And pssst:NULLis a totally valid parameter here, and when you pass it, this function is a no-op. Nothing happens. Chill.
π Context manipulation functions π
EVP_RAND_CTX_new()β creates a shiny new context for the RAND implementationrand. If it's not NULL,parentspecifies the seed source for this implementation. Heads up: not all random number generators need a seed source specified. And if a parent is required but you pass NULL, it'll utilise the operating system entropy sources instead.
okay listen, small PSA π it is recommended to minimise the number of random number generators that rely on the operating system for their randomness, because that stuff is often scarce. Don't be greedy with the OS entropy, bestie.
EVP_RAND_CTX_free()β frees up the contextctx. IfctxisNULL, nothing is done. Simple as that. π«ΆEVP_RAND_CTX_get0_rand()β returns theEVP_RANDassociated with the contextctx.
π₯ Random Number Generator Functions π₯
EVP_RAND_instantiate()β processes any parameters sitting inparams, and then instantiates the RANDctxwith a minimum security strength of strength and a personalisation stringpstrof length pstr_len. Ifprediction_resistanceis specified, fresh entropy from a live source will be sought. π This call operates as per NIST SP 800-90A and SP 800-90C.EVP_RAND_uninstantiate()β uninstantiates the RANDctx, as per NIST SP 800-90A and SP 800-90C. After this call, the RAND cannot be used to generate bytes anymore. It can only be freed or instantiated again. It's giving β¨closed for businessβ¨.EVP_RAND_generate()β produces random bytes from the RANDctx, with the additional inputaddinof lengthaddin_len. The bytes it produces will meet the security strength. Ifprediction_resistanceis specified, fresh entropy from a live source will be sought. This call operates as per NIST SP 800-90A and SP 800-90C. πEVP_RAND_reseed()β reseeds the RAND with new entropy. You can supply entropyentof lengthent_lenbytes, and you can also supply additional inputaddinof lengthaddin_lenbytes. In the FIPS provider, both are treated as additional input as per NIST SP-800-90Ar1, Sections 9.1 and 9.2. Additional seed material is also drawn from the RAND's parent or the operating system. And ifprediction_resistanceis specified, fresh entropy from a live source will be sought. This call operates as per NIST SP 800-90A and SP 800-90C.EVP_RAND_nonce()β creates a nonce inoutof lengthoutlenbytes, from the RANDctx. iconic.EVP_RAND_enable_locking()β enables locking for the RANDctxand all of its parents. After this, thectxwill operate in a thread safe manner β albeit more slowly. π’
β οΈ real talk: this function is not itself thread safe if you call it with the samectxfrom multiple threads. Typically you should enable locking before actxis shared across multiple threads. do it early, bestie, don't play yourself.
EVP_RAND_get_params()β retrieves details about the implementationrand. The set of parameters you give withparamsdetermines exactly which parameters get retrieved. And note: a parameter that is unknown in the underlying context is simply ignored. no drama.EVP_RAND_CTX_get_params()β retrieves chosen parameters, given the contextctxand its underlying context. The set of parameters you give withparamsdetermines exactly which parameters get retrieved. Same deal: a parameter unknown in the underlying context is simply ignored. πEVP_RAND_CTX_set_params()β passes chosen parameters to the underlying context, given a contextctx. The set of parameters you give withparamsdetermines exactly which parameters get passed down. Note that a parameter unknown in the underlying context is simply ignored. And also β what happens when a needed parameter isn't passed down? That's defined by the implementation. so uh, ask your provider. πEVP_RAND_gettable_params()β returns anOSSL_PARAM(3)array that describes the retrievable and settable parameters. Specifically,EVP_RAND_gettable_params()returns parameters that can be used withEVP_RAND_get_params().EVP_RAND_gettable_ctx_params()andEVP_RAND_CTX_gettable_params()β return constantOSSL_PARAM(3)arrays that describe the retrievable parameters that can be used withEVP_RAND_CTX_get_params().EVP_RAND_gettable_ctx_params()returns the parameters that can be retrieved from the algorithm, whereasEVP_RAND_CTX_gettable_params()returns the parameters that can be retrieved in the context's current state. two different vibes, keep them straight bestie πEVP_RAND_settable_ctx_params()andEVP_RAND_CTX_settable_params()β return constantOSSL_PARAM(3)arrays that describe the settable parameters that can be used withEVP_RAND_CTX_set_params().EVP_RAND_settable_ctx_params()returns the parameters that can be retrieved from the algorithm, whereasEVP_RAND_CTX_settable_params()returns the parameters that can be retrieved in the context's current state.
π¦ Information functions π¦
EVP_RAND_get_strength()β returns the security strength of the RANDctx. πͺEVP_RAND_get_state()β returns the current state of the RANDctx. The states defined by the OpenSSL RNGs are:EVP_RAND_STATE_UNINITIALISEDβ this RNG is currently uninitialised. The instantiate call will change this to the ready state.EVP_RAND_STATE_READYβ this RNG is currently ready to generate output. πEVP_RAND_STATE_ERRORβ this RNG is in an error state. π
EVP_RAND_is_a()β returns1ifrandis an implementation of an algorithm that's identifiable withname, otherwise0.EVP_RAND_get0_provider()β returns the provider that holds the implementation of the givenrand.EVP_RAND_do_all_provided()β traverses all RAND implemented by all activated providers in the given library contextlibctx, and for each of the implementations, calls the given functionfnwith the implementation method and the givenargas argument. a little tour of the whole neighborhood πΆββοΈEVP_RAND_get0_name()β returns the canonical name ofrand.EVP_RAND_names_do_all()β traverses all names forrand, and callsfnwith each name anddata.EVP_RAND_get0_description()β returns a description of therand, meant for display and human consumption. The description is at the discretion of therandimplementation β so don't @ it, it writes its own bio.EVP_RAND_verify_zeroization()β confirms whether the internal DRBG state is currently zeroed. This is used by the FIPS provider to support the mandatory self tests. β
β PARAMETERS β
The standard parameter names are:
"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 returns1if the operation is FIPS approved, or0otherwise. This option is used by the OpenSSL FIPS provider and is not supported by all EVP_RAND sources. so don't come for it if your provider doesn't have it π
For rands that are also deterministic random bit generators (DRBGs), these additional parameters are recognised. And heads up: 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 RANDctx."reseed_time_interval"(OSSL_DRBG_PARAM_RESEED_TIME_INTERVAL)<integer>β Reads or set the number of elapsed seconds before reseeding the associated RANDctx."max_request"(OSSL_RAND_PARAM_MAX_REQUEST)<unsigned integer>β Specifies the maximum number of bytes that can be generated in a single call toOSSL_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 seed 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."properties"(OSSL_RAND_PARAM_PROPERTIES)<UTF8 string>,"digest"(OSSL_RAND_PARAM_DIGEST)<UTF8 string>, and"cipher"(OSSL_RAND_PARAM_CIPHER)<UTF8 string>β For RAND implementations that use an underlying digest or cipher, these parameters set what the algorithm should be.
The value is always the name of the intended algorithm, or the properties in the case of OSSL_RAND_PARAM_PROPERTIES. π
π NOTES π
okay bestie, listen up, this part is the "read before you wreck stuff" part π«Ά
- The
prediction_resistanceargument toEVP_RAND_instantiate(),EVP_RAND_generate()orEVP_RAND_reseed()β when you set it to a nonzero value β is something you should use sparingly. like, not every day. as a lil treat. β¨ In the default setup, this will cause all public and private DRBGs to be reseeded on next use. And since by default public and private DRBGs are allocated on a per thread basis, that can result in significant overhead for highly multi-threaded applications. π so yeah, it's giving expensive. - For normal use-cases, the default
reseed_requestsandreseed_time_intervalthresholds already ensure sufficient prediction resistance over time, so you're fine. And if you think they're too high, you can just reduce those values. lowkey customizable, highkey fine. π - Explicitly requesting prediction resistance is intended for more special use-cases, like generating long-term secrets. that's the moment. that's when you use it. π
An EVP_RAND_CTX needs to have locking enabled if it acts as the parent of more than one child and the children can be accessed concurrently. ngl this doesn't just happen by itself β this must be done by explicitly calling EVP_RAND_enable_locking(). no cap, you have to ask for it. π
The RAND life-cycle is described in life_cycle-rand(7). In the future, the transitions described there will be enforced. π«£ And when this is done, it will not be considered a breaking change to the API. so don't come for the API later, bestie, it told you in advance.
π RETURN VALUES π
here's the vibe check on what everything hands back to you:
EVP_RAND_fetch()β returns a pointer to a newly fetchedEVP_RAND, orNULLif allocation failed.EVP_RAND_get0_provider()β returns a pointer to the provider for the RAND, orNULLon error.EVP_RAND_CTX_get0_rand()β returns a pointer to theEVP_RANDassociated with the context.EVP_RAND_get0_name()β returns the name of the random number generation algorithm. πEVP_RAND_up_ref()β returns1on success,0on error.EVP_RAND_names_do_all()β returns1if the callback was called for all names. A return value of0means that the callback was not called for any names.EVP_RAND_CTX_new()β returns either the newly allocatedEVP_RAND_CTXstructure orNULLif an error occurred.EVP_RAND_CTX_free()β does not return a value. it just frees and dips. π¦EVP_RAND_CTX_up_ref()β returns1on success,0on error.EVP_RAND_nonce()β returns1on success,0on error.EVP_RAND_get_strength()β returns the strength of the random number generator in bits. π₯EVP_RAND_gettable_params(),EVP_RAND_gettable_ctx_params()andEVP_RAND_settable_ctx_params()β return an array ofOSSL_PARAMs.EVP_RAND_verify_zeroization()β returns1if the internal DRBG state is currently zeroed, and0if not. π
And the remaining functions? They return 1 for success and 0 or a negative value for failure. that's the whole rule, fr fr.
π SEE ALSO π
go read these next, bestie, they're all part of the lore:
RAND_bytes(3)EVP_RAND-CTR-DRBG(7)EVP_RAND-HASH-DRBG(7)EVP_RAND-HMAC-DRBG(7)EVP_RAND-TEST-RAND(7)provider-rand(7)life_cycle-rand(7)
π HISTORY π
EVP_RAND_CTX_up_ref()was added in OpenSSL 3.1. β¨- The remaining functions were added in OpenSSL 3.0.
so yeah, EVP_RAND_CTX_up_ref() is the baby of the family. πΌ
π COPYRIGHT π
Copyright 2020-2026 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 a wrap on EVP_RAND(3SSL), bestie π this one came from OpenSSL 4.0.3, dated 2026-09-29 β go forth and generate randomness responsibly, ily, bye! πβ¨π¦
π¦ where this page comes from
- ubuntu stonking: libssl-doc 4.0.3-1ubuntu1 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms