PROVIDER-BASE(7ossl)
π provider-base β the basic OpenSSL library β provider functions π
okay so bestie, this is provider-base from the 7ossl manual, and it is literally the group chat between libcrypto and a provider. All the "functions" in here aren't real functions β they're function pointers that get passed around in OSSL_DISPATCH(3) arrays, and they're known as upcalls. Buckle up, this page is a long one, we're doing it in parts π«Ά
β¨ SYNOPSIS β¨
#include <openssl/core_dispatch.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.
*/
/* Functions offered by libcrypto to the providers */
const OSSL_ITEM *core_gettable_params(const OSSL_CORE_HANDLE *handle);
int core_get_params(const OSSL_CORE_HANDLE *handle, OSSL_PARAM params[]);
typedef void (*OSSL_thread_stop_handler_fn)(void *arg);
int core_thread_start(const OSSL_CORE_HANDLE *handle,
OSSL_thread_stop_handler_fn handfn,
void *arg);
OPENSSL_CORE_CTX *core_get_libctx(const OSSL_CORE_HANDLE *handle);
void core_new_error(const OSSL_CORE_HANDLE *handle);
void core_set_error_debug(const OSSL_CORE_HANDLE *handle,
const char *file, int line, const char *func);
void core_vset_error(const OSSL_CORE_HANDLE *handle,
uint32_t reason, const char *fmt, va_list args);
int core_obj_add_sigid(const OSSL_CORE_HANDLE *prov, const char *sign_name,
const char *digest_name, const char *pkey_name);
int core_obj_create(const OSSL_CORE_HANDLE *handle, const char *oid,
const char *sn, const char *ln);
/*
* Some OpenSSL functionality is directly offered to providers via
* dispatch
*/
void *CRYPTO_malloc(size_t num, const char *file, int line);
void *CRYPTO_zalloc(size_t num, const char *file, int line);
void CRYPTO_free(void *ptr, const char *file, int line);
void CRYPTO_clear_free(void *ptr, size_t num,
const char *file, int line);
void *CRYPTO_realloc(void *addr, size_t num,
const char *file, int line);
void *CRYPTO_clear_realloc(void *addr, size_t old_num, size_t num,
const char *file, int line);
void *CRYPTO_secure_malloc(size_t num, const char *file, int line);
void *CRYPTO_secure_zalloc(size_t num, const char *file, int line);
void CRYPTO_secure_free(void *ptr, const char *file, int line);
void CRYPTO_secure_clear_free(void *ptr, size_t num,
const char *file, int line);
int CRYPTO_secure_allocated(const void *ptr);
void OPENSSL_cleanse(void *ptr, size_t len);
unsigned char *OPENSSL_hexstr2buf(const char *str, long *buflen);
OSSL_CORE_BIO *BIO_new_file(const char *filename, const char *mode);
OSSL_CORE_BIO *BIO_new_membuf(const void *buf, int len);
int BIO_read_ex(OSSL_CORE_BIO *bio, void *data, size_t data_len,
size_t *bytes_read);
int BIO_write_ex(OSSL_CORE_BIO *bio, const void *data, size_t data_len,
size_t *written);
int BIO_up_ref(OSSL_CORE_BIO *bio);
int BIO_free(OSSL_CORE_BIO *bio);
int BIO_vprintf(OSSL_CORE_BIO *bio, const char *format, va_list args);
int BIO_vsnprintf(char *buf, size_t n, const char *fmt, va_list args);
void OSSL_SELF_TEST_set_callback(OSSL_LIB_CTX *libctx, OSSL_CALLBACK *cb,
void *cbarg);
size_t get_entropy(const OSSL_CORE_HANDLE *handle,
unsigned char **pout, int entropy,
size_t min_len, size_t max_len);
size_t get_user_entropy(const OSSL_CORE_HANDLE *handle,
unsigned char **pout, int entropy,
size_t min_len, size_t max_len);
void cleanup_entropy(const OSSL_CORE_HANDLE *handle,
unsigned char *buf, size_t len);
void cleanup_user_entropy(const OSSL_CORE_HANDLE *handle,
unsigned char *buf, size_t len);
size_t get_nonce(const OSSL_CORE_HANDLE *handle,
unsigned char **pout, size_t min_len, size_t max_len,
const void *salt, size_t salt_len);
size_t get_user_nonce(const OSSL_CORE_HANDLE *handle,
unsigned char **pout, size_t min_len, size_t max_len,
const void *salt, size_t salt_len);
void cleanup_nonce(const OSSL_CORE_HANDLE *handle,
unsigned char *buf, size_t len);
void cleanup_user_nonce(const OSSL_CORE_HANDLE *handle,
unsigned char *buf, size_t len);
/* Functions for querying the providers in the application library context */
int provider_register_child_cb(const OSSL_CORE_HANDLE *handle,
int (*create_cb)(const OSSL_CORE_HANDLE *provider,
void *cbdata),
int (*remove_cb)(const OSSL_CORE_HANDLE *provider,
void *cbdata),
int (*global_props_cb)(const char *props, void *cbdata),
void *cbdata);
void provider_deregister_child_cb(const OSSL_CORE_HANDLE *handle);
const char *provider_name(const OSSL_CORE_HANDLE *prov);
void *provider_get0_provider_ctx(const OSSL_CORE_HANDLE *prov);
const OSSL_DISPATCH *provider_get0_dispatch(const OSSL_CORE_HANDLE *prov);
int provider_up_ref(const OSSL_CORE_HANDLE *prov, int activate);
int provider_free(const OSSL_CORE_HANDLE *prov, int deactivate);
/* Functions offered by the provider to libcrypto */
void provider_teardown(void *provctx);
const OSSL_ITEM *provider_gettable_params(void *provctx);
int provider_get_params(void *provctx, OSSL_PARAM params[]);
const OSSL_ALGORITHM *provider_query_operation(void *provctx,
int operation_id,
const int *no_store);
void provider_unquery_operation(void *provctx, int operation_id,
const OSSL_ALGORITHM *algs);
const OSSL_ITEM *provider_get_reason_strings(void *provctx);
int provider_get_capabilities(void *provctx, const char *capability,
OSSL_CALLBACK *cb, void *arg);
int provider_self_test(void *provctx);
πΈ NAME πΈ
provider-base β the basic OpenSSL library β provider functions. that's it, that's the whole vibe π
π¦ DESCRIPTION π¦
Okay so first things first, queen: all of the "functions" mentioned here are actually passed as function pointers between libcrypto and the provider, inside OSSL_DISPATCH(3) arrays, and they get passed in the call of the provider initialization function. If you wanna know what that initialization function even is, go read the "Provider" section in provider(7) β it's all laid out there. These bad boys are known as "upcalls", and honestly? iconic name. π
Every single one of these "functions" has a matching function type definition named OSSL_FUNC_{name}_fn, plus a little helper function that fetches the function pointer out of an OSSL_DISPATCH(3) element β that helper is named OSSL_FUNC_{name}. So, for example, the "function" core_gettable_params() comes with these:
typedef OSSL_PARAM *
(OSSL_FUNC_core_gettable_params_fn)(const OSSL_CORE_HANDLE *handle);
static ossl_inline OSSL_NAME_core_gettable_params_fn
OSSL_FUNC_core_gettable_params(const OSSL_DISPATCH *opf);
The entries in that OSSL_DISPATCH(3) array each carry a function_id field, and that's the thing that says which function it is. The function_id numbers are handed to you as macros in openssl-core_dispatch.h(7), like this π
π the mapping (for in)
For in (the OSSL_DISPATCH(3) array passed from libcrypto to the provider):
core_gettable_paramsβOSSL_FUNC_CORE_GETTABLE_PARAMScore_get_paramsβOSSL_FUNC_CORE_GET_PARAMScore_thread_startβOSSL_FUNC_CORE_THREAD_STARTcore_get_libctxβOSSL_FUNC_CORE_GET_LIBCTXcore_new_errorβOSSL_FUNC_CORE_NEW_ERRORcore_set_error_debugβOSSL_FUNC_CORE_SET_ERROR_DEBUGcore_vset_errorβOSSL_FUNC_CORE_VSET_ERRORcore_set_error_markβOSSL_FUNC_CORE_SET_ERROR_MARKcore_clear_last_error_markβOSSL_FUNC_CORE_CLEAR_LAST_ERROR_MARKcore_pop_error_to_markβOSSL_FUNC_CORE_POP_ERROR_TO_MARKcore_count_to_markβOSSL_FUNC_CORE_COUNT_TO_MARKcore_obj_add_sigidβOSSL_FUNC_CORE_OBJ_ADD_SIGIDcore_obj_createβOSSL_FUNC_CORE_OBJ_CREATECRYPTO_mallocβOSSL_FUNC_CRYPTO_MALLOCCRYPTO_zallocβOSSL_FUNC_CRYPTO_ZALLOCCRYPTO_freeβOSSL_FUNC_CRYPTO_FREECRYPTO_clear_freeβOSSL_FUNC_CRYPTO_CLEAR_FREECRYPTO_reallocβOSSL_FUNC_CRYPTO_REALLOCCRYPTO_clear_reallocβOSSL_FUNC_CRYPTO_CLEAR_REALLOCCRYPTO_secure_mallocβOSSL_FUNC_CRYPTO_SECURE_MALLOCCRYPTO_secure_zallocβOSSL_FUNC_CRYPTO_SECURE_ZALLOCCRYPTO_secure_freeβOSSL_FUNC_CRYPTO_SECURE_FREECRYPTO_secure_clear_freeβOSSL_FUNC_CRYPTO_SECURE_CLEAR_FREECRYPTO_secure_allocatedβOSSL_FUNC_CRYPTO_SECURE_ALLOCATEDBIO_new_fileβOSSL_FUNC_BIO_NEW_FILEBIO_new_mem_bufβOSSL_FUNC_BIO_NEW_MEMBUFBIO_read_exβOSSL_FUNC_BIO_READ_EXBIO_write_exβOSSL_FUNC_BIO_WRITE_EXBIO_up_refβOSSL_FUNC_BIO_UP_REFBIO_freeβOSSL_FUNC_BIO_FREEBIO_vprintfβOSSL_FUNC_BIO_VPRINTFBIO_vsnprintfβOSSL_FUNC_BIO_VSNPRINTFBIO_putsβOSSL_FUNC_BIO_PUTSBIO_getsβOSSL_FUNC_BIO_GETSBIO_ctrlβOSSL_FUNC_BIO_CTRLOPENSSL_cleanseβOSSL_FUNC_OPENSSL_CLEANSEOSSL_SELF_TEST_set_callbackβOSSL_FUNC_SELF_TEST_CBossl_rand_get_entropyβOSSL_FUNC_GET_ENTROPYossl_rand_get_user_entropyβOSSL_FUNC_GET_USER_ENTROPYossl_rand_cleanup_entropyβOSSL_FUNC_CLEANUP_ENTROPYossl_rand_cleanup_user_entropyβOSSL_FUNC_CLEANUP_USER_ENTROPYossl_rand_get_nonceβOSSL_FUNC_GET_NONCEossl_rand_get_user_nonceβOSSL_FUNC_GET_USER_NONCEossl_rand_cleanup_nonceβOSSL_FUNC_CLEANUP_NONCEossl_rand_cleanup_user_nonceβOSSL_FUNC_CLEANUP_USER_NONCEprovider_register_child_cbβOSSL_FUNC_PROVIDER_REGISTER_CHILD_CBprovider_deregister_child_cbβOSSL_FUNC_PROVIDER_DEREGISTER_CHILD_CBprovider_nameβOSSL_FUNC_PROVIDER_NAMEprovider_get0_provider_ctxβOSSL_FUNC_PROVIDER_GET0_PROVIDER_CTXprovider_get0_dispatchβOSSL_FUNC_PROVIDER_GET0_DISPATCHprovider_up_refβOSSL_FUNC_PROVIDER_UP_REFprovider_freeβOSSL_FUNC_PROVIDER_FREE
For *out (the OSSL_DISPATCH(3) array passed from the provider to libcrypto):
provider_teardown OSSL_FUNC_PROVIDER_TEARDOWN
provider_gettable_params OSSL_FUNC_PROVIDER_GETTABLE_PARAMS
provider_get_params OSSL_FUNC_PROVIDER_GET_PARAMS
provider_query_operation OSSL_FUNC_PROVIDER_QUERY_OPERATION
provider_unquery_operation OSSL_FUNC_PROVIDER_UNQUERY_OPERATION
provider_get_reason_strings OSSL_FUNC_PROVIDER_GET_REASON_STRINGS
provider_get_capabilities OSSL_FUNC_PROVIDER_GET_CAPABILITIES
provider_self_test OSSL_FUNC_PROVIDER_SELF_TEST
π Core functions π
okay these are the ones the core hands you, the upcalls, the little lifelines back to the mothership π°οΈ β and honestly they lowkey do a lot.
core_gettable_params() gives you back a constant array of descriptor OSSL_PARAM(3) β literally just the list of parameters that core_get_params() is able to handle. A little menu, basically π
core_get_params() retrieves parameters from the core for the given handle. Wanna know which parameters exist right now? Peep "Core parameters" down below π
The core_thread_start() function tells the core that this provider has stated an interest in the current thread. The core will then let the provider know when that thread eventually stops π You gotta pass it the handle for this provider, plus a callback handfn that gets called when the thread stops. That callback is subsequently called β from the thread that's stopping β with the supplied argument arg, and it gets passed the provider context too. Super useful for thread-specific cleanup, like freeing thread-local variables π§Ή
core_get_libctx() retrieves the core context in which the library object for the current provider is stored, and you get at it through the handle.
β οΈ This one is useful ONLY for built-in providers, like the default provider. Never cast this toOSSL_LIB_CTXin a provider that isn't built-in β theOSSL_LIB_CTXof the library loading the provider might be a completely different structure than theOSSL_LIB_CTXof the library the provider is linked to π¬ UseOSSL_LIB_CTX_new_child(3)instead to obtain a proper library context that's linked to the application library context. no cap, this is the classic footgun π
core_new_error(), core_set_error_debug() and core_vset_error() are the building blocks π§± for reporting an error back to the core, with reference to the handle:
core_new_error()β allocates a new thread specific error record. This corresponds to the OpenSSL functionERR_new(3)β¨core_set_error_debug()β sets debugging information in the current thread specific error record. That debug info includes the name of the filefile, the linelineand the function namefuncwhere the error occurred. This corresponds to the OpenSSL functionERR_set_debug(3)πcore_vset_error()β sets the reason for the error, along with any additional data. The reason is a number defined by the provider, and it's used to index the reason strings table that's returned byprovider_get_reason_strings(). The additional data comes in as a format stringfmtand a set of argumentsargs, which are treated in the same manner as withBIO_vsnprintf(). You may also passfileandlineto indicate exactly where the error occurred or was reported. This corresponds to the OpenSSL functionERR_vset_error(3)πcore_set_error_mark()β sets a mark on the current topmost error record, if there is one. This corresponds to the OpenSSL functionERR_set_mark(3)π―core_clear_last_error_mark()β removes the last mark added, if there is one. This corresponds to the OpenSSL functionERR_clear_last_mark(3)π§½core_pop_error_to_mark()β pops the top of the error stack until a mark is found, then removes that mark. If there is no mark, the whole stack gets removed π³ This corresponds to the OpenSSL functionERR_pop_to_mark(3)core_count_to_mark()β returns the number of entries on the error stack above the most recently marked entry, not including that entry. If there's no mark in the error stack, you get the number of entries in the error stack back. This corresponds to the OpenSSL functionERR_count_to_mark(3)π’
The core_obj_create() function registers a new OID plus an associated short name sn and long name ln for the given handle. It's similar to the OpenSSL function OBJ_create(3) β except it returns 1 on success or 0 on failure π«Ά And here's the cute part: it treats the case where the OID already exists as success π
(even if the short name sn or long name ln you passed in differ from those associated with the existing OID β in which case, ngl, the new names just don't get associated. no drama.)
The core_obj_add_sigid() function registers a new composite signature algorithm (sign_name) consisting of an underlying signature algorithm (pkey_name) and a digest algorithm (digest_name) for the given handle 𧬠It assumes the OIDs for the composite signature algorithm, the underlying signature algorithm and the digest algorithm are either already known to OpenSSL or have been registered via a call to core_obj_create().
It corresponds to the OpenSSL function OBJ_add_sigid(3), except the objects are identified by name rather than a numeric NID π Any name works to identify the object β OID, short name or long name. Same energy as before: it treats the case where the composite signature algorithm already exists as success (even if it's registered against a different underlying signature or digest algorithm π). For digest_name, NULL or an empty string is permissible β that's for signature algorithms that don't need a digest to operate correctly. Returns 1 on success or 0 on failure β¨
and now, the guest list ποΈ β these all behave exactly like the public functions with the same name:
CRYPTO_malloc()
CRYPTO_zalloc()
CRYPTO_free()
CRYPTO_clear_free()
CRYPTO_realloc()
CRYPTO_clear_realloc()
CRYPTO_secure_malloc()
CRYPTO_secure_zalloc()
CRYPTO_secure_free()
CRYPTO_secure_clear_free()
CRYPTO_secure_allocated()
BIO_new_file()
BIO_new_mem_buf()
BIO_read_ex()
BIO_write_ex()
BIO_up_ref()
BIO_free()
BIO_vprintf()
BIO_vsnprintf()
BIO_gets()
BIO_puts()
BIO_ctrl()
OPENSSL_cleanse()
OPENSSL_hexstr2buf()
And fr fr, as a matter of fact, the pointers in the OSSL_DISPATCH(3) array are typically direct pointers to those public functions π iconic.
π¨ Note that the BIO functions take anOSSL_CORE_BIOtype rather than the standardBIOtype. Why? To make sure a provider does not mix BIOs from the core with BIOs used on the provider side β the two are not compatible, bestie, do not try it π
OSSL_SELF_TEST_set_callback() is used to set an optional callback that can be passed into a provider. A provider may ignore it, and that's fine π€·ββοΈ
π Entropy & nonces (the randomness girlies)
get_entropy() retrieves seeding material from the operating system π The seeding material will have at least entropy bytes of randomness, and the output will have at least min_len and at most max_len bytes. The buffer address is stored in *pout and the buffer length is returned to the caller. On error, zero is returned π
get_user_entropy() is the same as get_entropy() except that it will attempt to gather seed material via the seed source specified by a call to RAND_set_seed_source_type(3) or via "Random Configuration" in config(5) π
cleanup_entropy() is used to clean up and free the buffer returned by get_entropy(). The entropy pointer returned by get_entropy() is passed in buf and its length in len π§Ό
cleanup_user_entropy() is used to clean up and free the buffer returned by get_user_entropy(). The entropy pointer returned by get_user_entropy() is passed in buf and its length in len π§Ό
get_nonce() retrieves a nonce using the passed salt parameter of length salt_len, plus operating system specific information π§ The salt should contain uniquely identifying information, and this is included, in an unspecified manner, as part of the output. The output is stored in a buffer which contains at least min_len and at most max_len bytes. The buffer address is stored in *pout and the buffer length is returned to the caller. On error, zero is returned β
get_user_nonce() is the same as get_nonce() except that it will attempt to gather seed material via the seed source specified by a call to RAND_set_seed_source_type(3) or via "Random Configuration" in config(5) π
cleanup_nonce() is used to clean up and free the buffer returned by get_nonce(). The nonce pointer returned by get_nonce() is passed in buf and its length in len π§Ό
cleanup_user_nonce() is used to clean up and free the buffer returned by get_user_nonce(). The nonce pointer returned by get_user_nonce() is passed in buf and its length in len π§Ό
π¦ Child provider callbacks
provider_register_child_cb() registers callbacks so you get informed about the loading and unloading of providers in the application's library context π handle is this provider's handle, and cbdata is this provider's data that will be passed back to the callbacks. Returns 1 on success or 0 otherwise.
π¨ Big warning: these callbacks may be called while holding locks in libcrypto. To avoid deadlocks, the callback implementation must not be long running and must not call other OpenSSL API functions or upcalls. like, keep it snappy, bestie β±οΈ
create_cbβ a callback that gets called when a new provider is loaded into the application's library context. It's also called for any providers that are already loaded at the point where this callback is registered. The callback is passed the handle being used for the new provider being loaded, and this provider's data incbdata. It should return1on success or0on failure π«remove_cbβ a callback that gets called when a new provider is unloaded from the application's library context. It's passed the handle being used for the provider being unloaded, and this provider's data incbdata. It should return1on success or0on failure πglobal_props_cbβ a callback that gets called when the global properties from the parent library context are changed. It should return1on success or0on failure π
provider_deregister_child_cb() unregisters callbacks previously registered via provider_register_child_cb(). If provider_register_child_cb() has been called, then provider_deregister_child_cb() should be called at or before the point that this provider's teardown function is called π§Ήβ¨
πΈ Provider introspection & refcounting
provider_name() returns a string giving the name of the provider identified by handle π·οΈ
provider_get0_provider_ctx() returns the provider context that's associated with the provider identified by prov π«Ά
provider_get0_dispatch() gets the dispatch table registered by the provider identified by prov when it initialised π
provider_up_ref() increments the reference count on the provider prov. If activate is nonzero, then the provider is also loaded if it isn't already loaded. Returns 1 on success or 0 on failure β¬οΈπ
provider_free() decrements the reference count on the provider prov. If deactivate is nonzero, then the provider is also unloaded if it isn't already loaded. Returns 1 on success or 0 on failure β¬οΈ
and that's the whole core-side menu, no skips, no omissions, we ate π
π§ Provider functions π§
Okay so these are the function pointers a provider can hand over to the core. Let's go one by one, no skipping π
provider_teardown()β this one gets called when a provider is shut down and yeeted out of the core's provider store. Its whole job? Free theprovctxthat got passed in. That's it, that's the task. Don't leak it bestie πprovider_gettable_params()β should return a constant array of descriptorOSSL_PARAM(3), covering all the parameters thatprovider_get_params()can actually handle.provider_get_params()β should chomp through theOSSL_PARAM(3)arrayparamsand set the values of all the parameters it understands. The way that it just fills in what it knows π«Άprovider_query_operation()β should return a constantOSSL_ALGORITHM(3)that lines up with the givenoperation_id. It also needs to say whether the core is allowed to stash a reference to that array: set*no_storeto0(core may store a reference) or1(core may not store a reference). Iconic little boolean, honestly.provider_unquery_operation()β this is the provider's heads-up that the result of aprovider_query_operation()is no longer directly needed, and that the function pointers have been copied. Theoperation_idshould match the one you passed toprovider_query_operation(), andalgsshould be its return value. Matching set, periodt β¨provider_get_reason_strings()β should return a constantOSSL_ITEM(3)array that gives reason strings for the reason codes the provider might use when it reports errors viacore_put_error().provider_get_capabilities()β this one calls the callbackcb, handing it a set ofOSSL_PARAM(3)s plus the caller-supplied argumentarg. ThoseOSSL_PARAM(3)s should describe the capability whose name is given in thecapabilityargument, relevant to the provider contextprovctx. If a provider supports multiple capabilities with that same name, it's totally allowed to call the callback multiple times β one call per capability, no cap π§’ Capabilities are lowkey useful for describing the services a provider can offer; for the full tea, see the "CAPABILITIES" section below. Returns1on success,0on error.provider_self_test()β should run known answer tests on a subset of the algorithms it uses, and it may also verify the integrity of the provider module. Returns1on success,0on error. And if this function isn't used at all? It returns1anyway. Self-care π
None of these functions are strictly mandatory, but ngl a provider is pretty useless without at leastprovider_query_operation(). Andprovider_gettable_params()is fairly useless if it's not accompanied byprovider_get_params(). They're a package deal, iykyk.
πΈ Provider parameters πΈ
provider_get_params() can return these provider parameters to the core:
"name"(OSSL_PROV_PARAM_NAME)<UTF8 ptr>β points to a string that should give a unique name for the provider. Your provider's legal government name π"version"(OSSL_PROV_PARAM_VERSION)<UTF8 ptr>β points to a string that's a version number associated with this provider. OpenSSL's in-built providers useOPENSSL_VERSION_STR, but honestly it may be different for any third party provider. Heads up: this string is for informational purposes only."buildinfo"(OSSL_PROV_PARAM_BUILDINFO)<UTF8 ptr>β points to a string that's build information associated with this provider. OpenSSL in-built providers useOPENSSL_FULL_VERSION_STR, but again, could be different for any third party provider."status"(OSSL_PROV_PARAM_STATUS)<unsigned integer>β returns0if the provider has entered an error state, otherwise it returns1. A vibe check in integer form π«Ά
And provider_gettable_params() should return the above parameters. All of them. Yes, all four.
π¦ Core parameters π¦
core_get_params() can retrieve these core parameters, for each provider:
"openssl-version"(OSSL_PROV_PARAM_CORE_VERSION)<UTF8 string ptr>β points to the OpenSSL libraries' full version string, i.e. the string expanded from the macroOPENSSL_VERSION_STR."provider-name"(OSSL_PROV_PARAM_CORE_PROV_NAME)<UTF8 string ptr>β points to the OpenSSL libraries' idea of what the calling provider is named."module-filename"(OSSL_PROV_PARAM_CORE_MODULE_FILENAME)<UTF8 string ptr>β points to a string containing the full filename of the provider's module file.
On top of that, provider-specific configuration parameters from the config file are also available, in dotted name form. Dotted name form = concatenation of section names plus the final config command name, all separated by periods. Very demure, very mindful naming scheme β¨
For example, let's say we have this config example:
config_diagnostics = 1
openssl_conf = openssl_init
[openssl_init]
providers = providers_sect
[providers_sect]
foo = foo_sect
[foo_sect]
activate = 1
data1 = 2
data2 = str
more = foo_more
[foo_more]
data3 = foo,bar
The provider will then have these additional parameters available:
"activate"β pointing at the string"1""data1"β pointing at the string"2""data2"β pointing at the string"str""more.data3"β pointing at the string"foo,bar"
For more information on handling parameters, see OSSL_PARAM(3) as OSSL_PARAM_int(3). Go read it, bestie π
π CAPABILITIES π
Capabilities describe some of the services that a provider can offer. Applications can query the capabilities to discover those services. It's giving "menu of what this provider can do" π
π₯ "TLS-GROUP" Capability π₯
The "TLS-GROUP" capability can be queried by libssl to discover the list of TLS groups a provider can support. Each group it supports can be used for key exchange (KEX) or key encapsulation method (KEM) during a TLS handshake. TLS clients can advertise the list of TLS groups they support in the supported_groups extension, and TLS servers can select a group from the offered list that they also support. So basically a provider can add to the list of groups libssl already supports with extra ones. Slay π
Each TLS group a provider supports should be described via the callback passed in through the provider_get_capabilities function. Every group should supply the following details β all of them are mandatory, except OSSL_CAPABILITY_TLS_GROUP_IS_KEM:
"tls-group-name"(OSSL_CAPABILITY_TLS_GROUP_NAME)<UTF8 string>β the name of the group as given in the IANA TLS Supported Groups registry:https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8"tls-group-name-internal"(OSSL_CAPABILITY_TLS_GROUP_NAME_INTERNAL)<UTF8 string>β the name of the group as known by the provider. This could be the same as"tls-group-name", but it does not have to be. Twins, not clones π―"tls-group-id"(OSSL_CAPABILITY_TLS_GROUP_ID)<unsigned integer>β the TLS group id value as given in the IANA TLS Supported Groups registry.
Fr fr, it is possible to register the same group id from within different providers. Users should note that if no property query is specified, or more than one implementation matches the property query, then it's unspecified which implementation for a particular group id will be used. So likeβ¦ don't be surprised when a random one shows up π
"tls-group-alg"(OSSL_CAPABILITY_TLS_GROUP_ALG)<UTF8 string>β the name of a Key Management algorithm that the provider offers and that should be used with this group. Keys created should be able to support key exchange or key encapsulation method (KEM), as implied by the optionalOSSL_CAPABILITY_TLS_GROUP_IS_KEMflag. The algorithm must support key and parameter generation, as well as the key/parameter generation parameterOSSL_PKEY_PARAM_GROUP_NAME. The group name given via"tls-group-name-internal"above will be passed viaOSSL_PKEY_PARAM_GROUP_NAMEwhen libssl wishes to generate keys/parameters. Very "pass it along" of them π§"tls-group-sec-bits"(OSSL_CAPABILITY_TLS_GROUP_SECURITY_BITS)<unsigned integer>β the number of bits of security offered by keys in this group. That number should be comparable with the ones given in table 2 and 3 of the NIST SP800-57 document."tls-group-is-kem"(OSSL_CAPABILITY_TLS_GROUP_IS_KEM)<unsigned integer>β boolean flag describing if the group should be used in key exchange (KEX) mode (0, the default) or in key encapsulation method (KEM) mode (1).
This parameter is optional: if you don't specify it, KEX mode is assumed as the default mode for the group. Default queen π
In KEX mode, in a typical Diffie-Hellman fashion, both sides execute keygen then derive against the peer public key. To operate in KEX mode, the group implementation must support the provider functions as described in provider-keyexch(7).
In KEM mode, the client executes keygen and sends its public key, the server executes encapsulate using the client's public key and sends back the resulting ciphertext, and finally the client executes decapsulate to retrieve the same shared secret generated by the server's encapsulate. To operate in KEM mode, the group implementation must support the provider functions as described in provider-kem(7).
Both in KEX and KEM mode, the resulting shared secret is then used according to the protocol specification. No cap, that's just how it is π«Ά
"tls-min-tls"(OSSL_CAPABILITY_TLS_GROUP_MIN_TLS)<integer>"tls-max-tls"(OSSL_CAPABILITY_TLS_GROUP_MAX_TLS)<integer>"tls-min-dtls"(OSSL_CAPABILITY_TLS_GROUP_MIN_DTLS)<integer>"tls-max-dtls"(OSSL_CAPABILITY_TLS_GROUP_MAX_DTLS)<integer>
These parameters can be used to describe the minimum and maximum TLS and DTLS versions supported by the group. The values equate to the on-the-wire encoding of the various TLS versions. So for example TLSv1.3 is 0x0304 (772 decimal), and TLSv1.2 is 0x0303 (771 decimal). A 0 indicates that there is no defined minimum or maximum. A -1 indicates that the group should not be used in that protocol. Rude, but valid π
β "TLS-SIGALG" Capability β
The "TLS-SIGALG" capability can be queried by libssl to discover the list of TLS signature algorithms that a provider can support. Each supported signature can be used for client- or server-authentication, in addition to the built-in signature algorithms. TLS1.3 clients can advertise the list of TLS signature algorithms they support in the signature_algorithms extension, and TLS servers can select an algorithm from the offered list that they also support. So once again, a provider can add to the list of signature algorithms libssl already supports with extra ones. Main character energy, honestly β¨
Each TLS signature algorithm a provider supports should be described via the callback passed in through the provider_get_capabilities function. Each algorithm can have the following details supplied:
"iana-name"(OSSL_CAPABILITY_TLS_SIGALG_IANA_NAME)<UTF8 string>β the name of the signature algorithm as given in the IANA TLS Signature Scheme registry as "Description":https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme. This value must be supplied. Non-negotiable."iana-code-point"(OSSL_CAPABILITY_TLS_SIGALG_CODE_POINT)<unsigned integer>β the TLS algorithm ID value as given in the IANA TLS SignatureScheme registry. This value must be supplied. Also non-negotiable π
okay so real talk first, bestie: you can register the same code point from within different providers π. But if no property query is specified, or more than one implementation matches the property query, then it is unspecified which implementation for a particular code point will be used. Not me having to say βit dependsβ in a manpage π.
Now the TLS sigalg capability params, because there are a whole bunch and they all need their moment:
"sigalg-name"(OSSL_CAPABILITY_TLS_SIGALG_NAME)<UTF8 string>β the name for the full (possibly composite hash-and-signature) signature algorithm. The provider may, but is not obligated to, provide a signature implementation with this name; if it doesn't, this is assumed to be a composite of a pure signature algorithm and a hash algorithm, which must be given with the parameters"sig-name"and"hash-name". This value must be supplied. No skips π ."sigalg-oid"(OSSL_CAPABILITY_TLS_SIGALG_OID)<UTF8 string>β the OID of the"sigalg-name"algorithm in canonical numeric text form. If this parameter is given,OBJ_create()will be used to create anOBJand aNIDfor this OID, using the"sigalg-name"parameter for its (short) name. Otherwise, it's assumed to already exist in the object database, possibly done by the provider with thecore_obj_create()upcall. This value is optional. π¦"sig-name"(OSSL_CAPABILITY_TLS_SIGALG_SIG_NAME)<UTF8 string>β the name of the pure signature algorithm that is part of a composite"sigalg-name". If"sigalg-name"is implemented by the provider, this parameter is redundant and must not be given. This value is optional. Lowkey redundant in that one case but still valid in the other β¨."sig-oid"(OSSL_CAPABILITY_TLS_SIGALG_SIG_OID)<UTF8 string>β the OID of the"sig-name"algorithm in canonical numeric text form. If this parameter is given,OBJ_create()will be used to create anOBJand aNIDfor this OID, using the"sig-name"parameter for its (short) name. Otherwise, it is assumed to already exist in the object database. This can be done by the provider using thecore_obj_create()upcall. This value is optional. π"hash-name"(OSSL_CAPABILITY_TLS_SIGALG_HASH_NAME)<UTF8 string>β the name of the hash algorithm that is part of a composite"sigalg-name". If"sigalg-name"is implemented by the provider, this parameter is redundant and must not be given. This value is optional. π"hash-oid"(OSSL_CAPABILITY_TLS_SIGALG_HASH_OID)<UTF8 string>β the OID of the"hash-name"algorithm in canonical numeric text form. If this parameter is given,OBJ_create()will be used to create anOBJand aNIDfor this OID, using the"hash-name"parameter for its (short) name. Otherwise, it's assumed to already exist in the object database, possibly done by the provider with thecore_obj_create()upcall. This value is optional. πΈ"key-type"(OSSL_CAPABILITY_TLS_SIGALG_KEYTYPE)<UTF8 string>β the key type of the public key of applicable certificates. If this parameter isn't present, it's assumed to be the same as"sig-name"if that's present, otherwise"sigalg-name". This value is optional. Cute little default vibe π."key-type-oid"(OSSL_CAPABILITY_TLS_SIGALG_KEYTYPE_OID)<UTF8 string>β the OID of the"key-type"in canonical numeric text form. If this parameter is given,OBJ_create()will be used to create anOBJand aNIDfor this OID, using the"key-type"parameter for its (short) name. Otherwise, it's assumed to already exist in the object database, possibly done by the provider with thecore_obj_create()upcall. This value is optional. π¦"sec-bits"(OSSL_CAPABILITY_TLS_SIGALG_SECURITY_BITS)<unsigned integer>β the number of bits of security offered by keys of this algorithm. The number of bits should be comparable with the ones given in table 2 and 3 of the NIST SP800-57 document. This number is used to determine the security strength of the algorithm if no digest algorithm has been registered that otherwise defines the security strength. If the signature algorithm implements its own digest internally, this value needs to be set to properly reflect the overall security strength. This value must be supplied. No cap, this one's mandatory π₯."tls-min-tls"(OSSL_CAPABILITY_TLS_SIGALG_MIN_TLS)<integer>"tls-max-tls"(OSSL_CAPABILITY_TLS_SIGALG_MAX_TLS)<integer>"tls-min-dtls"(OSSL_CAPABILITY_TLS_SIGALG_MIN_DTLS)<integer>"tls-max-dtls"(OSSL_CAPABILITY_TLS_SIGALG_MAX_DTLS)<integer>
These parameters can be used to describe the minimum and maximum TLS and DTLS versions supported by the signature algorithm. The values equate to the on-the-wire encoding of the various TLS versions. For example TLSv1.3 is 0x0304 (772 decimal), and TLSv1.2 is 0x0303 (771 decimal). A 0 indicates that there is no defined minimum or maximum. A -1 in either the min or max field indicates that the signature algorithm should not be used in that protocol. Presently, provider signature algorithms are used only with TLS 1.3, if that's enclosed in the specified range. Whew, range check passed? π.
π NOTES π
ngl, heads up: in OpenSSL 3.0, core_obj_create() and core_obj_add_sigid() were not thread safe. That's the whole note. Periodt.
π EXAMPLES π
This is an example of a simple provider made available as a dynamically loadable module. It implements the fictitious algorithm "FOO" for the fictitious operation "BAR". It's giving main character provider energy β¨.
#include <malloc.h>
#include <openssl/core.h>
#include <openssl/core_dispatch.h>
/* Errors used in this provider */
#define E_MALLOC 1
static const OSSL_ITEM reasons[] = {
{ E_MALLOC, "memory allocation failure" }.
OSSL_DISPATCH_END
};
/*
* To ensure we get the function signature right, forward declare
* them using function types provided by openssl/core_dispatch.h
*/
OSSL_FUNC_bar_newctx_fn foo_newctx;
OSSL_FUNC_bar_freectx_fn foo_freectx;
OSSL_FUNC_bar_init_fn foo_init;
OSSL_FUNC_bar_update_fn foo_update;
OSSL_FUNC_bar_final_fn foo_final;
OSSL_FUNC_provider_query_operation_fn p_query;
OSSL_FUNC_provider_get_reason_strings_fn p_reasons;
OSSL_FUNC_provider_teardown_fn p_teardown;
OSSL_provider_init_fn OSSL_provider_init;
OSSL_FUNC_core_put_error *c_put_error = NULL;
/* Provider context */
struct prov_ctx_st {
OSSL_CORE_HANDLE *handle;
}
/* operation context for the algorithm FOO */
struct foo_ctx_st {
struct prov_ctx_st *provctx;
int b;
};
static void *foo_newctx(void *provctx)
{
struct foo_ctx_st *fooctx = malloc(sizeof(*fooctx));
if (fooctx != NULL)
fooctx->provctx = provctx;
else
c_put_error(provctx->handle, E_MALLOC, __FILE__, __LINE__);
return fooctx;
}
static void foo_freectx(void *fooctx)
{
free(fooctx);
}
static int foo_init(void *vfooctx)
{
struct foo_ctx_st *fooctx = vfooctx;
fooctx->b = 0x33;
}
static int foo_update(void *vfooctx, unsigned char *in, size_t inl)
{
struct foo_ctx_st *fooctx = vfooctx;
/* did you expect something serious? */
if (inl == 0)
return 1;
for (; inl-- > 0; in++)
*in ^= fooctx->b;
return 1;
}
static int foo_final(void *vfooctx)
{
struct foo_ctx_st *fooctx = vfooctx;
fooctx->b = 0x66;
}
static const OSSL_DISPATCH foo_fns[] = {
{ OSSL_FUNC_BAR_NEWCTX, (void (*)(void))foo_newctx },
{ OSSL_FUNC_BAR_FREECTX, (void (*)(void))foo_freectx },
{ OSSL_FUNC_BAR_INIT, (void (*)(void))foo_init },
{ OSSL_FUNC_BAR_UPDATE, (void (*)(void))foo_update },
{ OSSL_FUNC_BAR_FINAL, (void (*)(void))foo_final },
OSSL_DISPATCH_END
};
static const OSSL_ALGORITHM bars[] = {
{ "FOO", "provider=chumbawamba", foo_fns },
{ NULL, NULL, NULL }
};
static const OSSL_ALGORITHM *p_query(void *provctx, int operation_id,
int *no_store)
{
switch (operation_id) {
case OSSL_OP_BAR:
return bars;
}
return NULL;
}
static const OSSL_ITEM *p_reasons(void *provctx)
{
return reasons;
}
static void p_teardown(void *provctx)
{
free(provctx);
}
static const OSSL_DISPATCH prov_fns[] = {
{ OSSL_FUNC_PROVIDER_TEARDOWN, (void (*)(void))p_teardown },
{ OSSL_FUNC_PROVIDER_QUERY_OPERATION, (void (*)(void))p_query },
{ OSSL_FUNC_PROVIDER_GET_REASON_STRINGS, (void (*)(void))p_reasons },
OSSL_DISPATCH_END
};
int OSSL_provider_init(const OSSL_CORE_HANDLE *handle,
const OSSL_DISPATCH *in,
const OSSL_DISPATCH **out,
void **provctx)
{
struct prov_ctx_st *pctx = NULL;
for (; in->function_id != 0; in++)
switch (in->function_id) {
case OSSL_FUNC_CORE_PUT_ERROR:
c_put_error = OSSL_FUNC_core_put_error(in);
break;
}
*out = prov_fns;
if ((pctx = malloc(sizeof(*pctx))) == NULL) {
/*
* ALEA IACTA EST, if the core retrieves the reason table
* regardless, that string will be displayed, otherwise not.
*/
c_put_error(handle, E_MALLOC, __FILE__, __LINE__);
return 0;
}
pctx->handle = handle;
return 1;
}
This relies on a few things existing in openssl/core_dispatch.h:
#define OSSL_OP_BAR 4711
#define OSSL_FUNC_BAR_NEWCTX 1
typedef void *(OSSL_FUNC_bar_newctx_fn)(void *provctx);
static ossl_inline OSSL_FUNC_bar_newctx(const OSSL_DISPATCH *opf)
{ return (OSSL_FUNC_bar_newctx_fn *)opf->function; }
#define OSSL_FUNC_BAR_FREECTX 2
typedef void (OSSL_FUNC_bar_freectx_fn)(void *ctx);
static ossl_inline OSSL_FUNC_bar_freectx(const OSSL_DISPATCH *opf)
{ return (OSSL_FUNC_bar_freectx_fn *)opf->function; }
#define OSSL_FUNC_BAR_INIT 3
typedef void *(OSSL_FUNC_bar_init_fn)(void *ctx);
static ossl_inline OSSL_FUNC_bar_init(const OSSL_DISPATCH *opf)
{ return (OSSL_FUNC_bar_init_fn *)opf->function; }
#define OSSL_FUNC_BAR_UPDATE 4
typedef void *(OSSL_FUNC_bar_update_fn)(void *ctx,
unsigned char *in, size_t inl);
static ossl_inline OSSL_FUNC_bar_update(const OSSL_DISPATCH *opf)
{ return (OSSL_FUNC_bar_update_fn *)opf->function; }
#define OSSL_FUNC_BAR_FINAL 5
typedef void *(OSSL_FUNC_bar_final_fn)(void *ctx);
static ossl_inline OSSL_FUNC_bar_final(const OSSL_DISPATCH *opf)
{ return (OSSL_FUNC_bar_final_fn *)opf->function; }
β¨ SEE ALSO β¨
provider(7)β go read that one too, bestie π«Ά.
π HISTORY π
okay so storytime bestie π«Ά β the whole concept of providers and literally everything surrounding them? it dropped in OpenSSL 3.0. like, the entire provider era started there. iconic behavior, no cap.
and then later, the definitions for OSSL_CAPABILITY_TLS_SIGALG_MIN_DTLS and OSSL_CAPABILITY_TLS_SIGALG_MAX_DTLS got added in OpenSSL 3.5. those two little constants are the new kids, highkey adorable π
.
Β©οΈ COPYRIGHT Β©οΈ
Copyright 2019-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. fr fr, read the license before you go touching things π.
You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html> π.
ngl the whole "except in compliance with the License" part is the vibe check β don't skip it, bestie π
and that's the whole page, we made it to the end πβ¨ this lovely little document is from PROVIDER-BASE(7ossl), source version 3.5.9, dated 2026-09-29 β go forth and provider, my love ππ¦
π¦ where this page comes from
- alpine 3.23: openssl-doc 3.5.9-r0 Β· Apache-2.0
- alpine 3.24: openssl-doc 3.5.9-r0 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms