PROVIDER-BASE(7SSL)

πŸ¦‹ PROVIDER-BASE, bestie edition πŸ¦‹

okay so this is PROVIDER-BASE(7SSL) from the OpenSSL manual β€” the page about the basic OpenSSL library <-> provider functions. It's the whole backstage pass to how libcrypto and providers talk to each other, and yes, it's giving very "the plumbing is the plot" πŸ’…. Grab a strawberry drink πŸ“, we're going in.


🌸 NAME 🌸

provider-base β€” The basic OpenSSL library <-> provider functions.


✨ 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);

Like, that's a lot of function pointers and every single one of them matters, no skips 🌈.


πŸ’– DESCRIPTION πŸ’–

Okay so picture this: every "function" listed up there isn't a real function function. They're function pointers that get passed back and forth between libcrypto and the provider inside OSSL_DISPATCH(3) arrays, dropped off at the call of the provider initialization function. If you want the full lore on that init function, go read "Provider" in provider(7). Everyone calls these lil guys "upcalls" πŸ’….

Every one of these "functions" has a matching function type definition, and its name is literally OSSL_FUNC_{name}_fn. There's also a helper function that fishes the pointer out of an OSSL_DISPATCH(3) element, named OSSL_FUNC_{name}. So for example, the "function" core_gettable_params() rolls with these two:

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 have a function_id field that's like the name tag at a party β€” it says which function this is. Those function_id numbers come to you as macros in openssl-core_dispatch.h(7), and here's the whole guest list, no one left out bestie πŸŽ€:

For in (that's the OSSL_DISPATCH(3) array that libcrypto hands to the provider):

  • core_gettable_params β€” OSSL_FUNC_CORE_GETTABLE_PARAMS
  • core_get_params β€” OSSL_FUNC_CORE_GET_PARAMS
  • core_thread_start β€” OSSL_FUNC_CORE_THREAD_START
  • core_get_libctx β€” OSSL_FUNC_CORE_GET_LIBCTX
  • core_new_error β€” OSSL_FUNC_CORE_NEW_ERROR
  • core_set_error_debug β€” OSSL_FUNC_CORE_SET_ERROR_DEBUG
  • core_vset_error β€” OSSL_FUNC_CORE_VSET_ERROR
  • core_set_error_mark β€” OSSL_FUNC_CORE_SET_ERROR_MARK
  • core_clear_last_error_mark β€” OSSL_FUNC_CORE_CLEAR_LAST_ERROR_MARK
  • core_pop_error_to_mark β€” OSSL_FUNC_CORE_POP_ERROR_TO_MARK
  • core_count_to_mark β€” OSSL_FUNC_CORE_COUNT_TO_MARK
  • core_obj_add_sigid β€” OSSL_FUNC_CORE_OBJ_ADD_SIGID
  • core_obj_create β€” OSSL_FUNC_CORE_OBJ_CREATE
  • CRYPTO_malloc β€” OSSL_FUNC_CRYPTO_MALLOC
  • CRYPTO_zalloc β€” OSSL_FUNC_CRYPTO_ZALLOC
  • CRYPTO_free β€” OSSL_FUNC_CRYPTO_FREE
  • CRYPTO_clear_free β€” OSSL_FUNC_CRYPTO_CLEAR_FREE
  • CRYPTO_realloc β€” OSSL_FUNC_CRYPTO_REALLOC
  • CRYPTO_clear_realloc β€” OSSL_FUNC_CRYPTO_CLEAR_REALLOC
  • CRYPTO_secure_malloc β€” OSSL_FUNC_CRYPTO_SECURE_MALLOC
  • CRYPTO_secure_zalloc β€” OSSL_FUNC_CRYPTO_SECURE_ZALLOC
  • CRYPTO_secure_free β€” OSSL_FUNC_CRYPTO_SECURE_FREE
  • CRYPTO_secure_clear_free β€” OSSL_FUNC_CRYPTO_SECURE_CLEAR_FREE
  • CRYPTO_secure_allocated β€” OSSL_FUNC_CRYPTO_SECURE_ALLOCATED
  • BIO_new_file β€” OSSL_FUNC_BIO_NEW_FILE
  • BIO_new_mem_buf β€” OSSL_FUNC_BIO_NEW_MEMBUF
  • BIO_read_ex β€” OSSL_FUNC_BIO_READ_EX
  • BIO_write_ex β€” OSSL_FUNC_BIO_WRITE_EX
  • BIO_up_ref β€” OSSL_FUNC_BIO_UP_REF
  • BIO_free β€” OSSL_FUNC_BIO_FREE
  • BIO_vprintf β€” OSSL_FUNC_BIO_VPRINTF
  • BIO_vsnprintf β€” OSSL_FUNC_BIO_VSNPRINTF
  • BIO_puts β€” OSSL_FUNC_BIO_PUTS
  • BIO_gets β€” OSSL_FUNC_BIO_GETS
  • BIO_ctrl β€” OSSL_FUNC_BIO_CTRL
  • OPENSSL_cleanse β€” OSSL_FUNC_OPENSSL_CLEANSE
  • OSSL_SELF_TEST_set_callback β€” OSSL_FUNC_SELF_TEST_CB
  • ossl_rand_get_entropy β€” OSSL_FUNC_GET_ENTROPY
  • ossl_rand_get_user_entropy β€” OSSL_FUNC_GET_USER_ENTROPY
  • ossl_rand_cleanup_entropy β€” OSSL_FUNC_CLEANUP_ENTROPY
  • ossl_rand_cleanup_user_entropy β€” OSSL_FUNC_CLEANUP_USER_ENTROPY
  • ossl_rand_get_nonce β€” OSSL_FUNC_GET_NONCE
  • ossl_rand_get_user_nonce β€” OSSL_FUNC_GET_USER_NONCE
  • ossl_rand_cleanup_nonce β€” OSSL_FUNC_CLEANUP_NONCE
  • ossl_rand_cleanup_user_nonce β€” OSSL_FUNC_CLEANUP_USER_NONCE
  • provider_register_child_cb β€” OSSL_FUNC_PROVIDER_REGISTER_CHILD_CB
  • provider_deregister_child_cb β€” OSSL_FUNC_PROVIDER_DEREGISTER_CHILD_CB
  • provider_name β€” OSSL_FUNC_PROVIDER_NAME
  • provider_get0_provider_ctx β€” OSSL_FUNC_PROVIDER_GET0_PROVIDER_CTX
  • provider_get0_dispatch β€” OSSL_FUNC_PROVIDER_GET0_DISPATCH
  • provider_up_ref β€” OSSL_FUNC_PROVIDER_UP_REF
  • provider_free β€” OSSL_FUNC_PROVIDER_FREE
tiny note from me, not a technical claim, just me reading the page with my whole chest πŸ™ˆ: the synopsis up top says BIO_new_membuf while this list says BIO_new_mem_buf. I typed both exactly how the manual has them. Do not perceive me, I'm just the messenger πŸ’€

For out (that's the OSSL_DISPATCH(3) array that goes 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

…and that's the rest of the roster, bestie, every last one of them πŸ’…


✨ Core functions ✨

  • core_gettable_params() β€” hands you back a constant array of descriptor OSSL_PARAM(3), covering the params that core_get_params() is able to deal with. It's giving menu energy πŸ“
  • core_get_params() β€” pulls parameters from the core for the given handle. Peep the "Core parameters" bit further down for the lowdown on which parameters are known rn πŸ‘€
  • core_thread_start() β€” this one tells the core that the 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 will later get called with the supplied argument arg, from the thread that's stopping, and it gets handed the provider context as an argument. Super handy for thread-specific cleanup β€” like freeing thread local variables, iykyk 🧹
  • core_get_libctx() β€” retrieves the core context in which the library object for the current provider is stored, reachable through the handle. This function is useful only for built-in providers, like the default provider.
🚨 NEVER cast this to OSSL_LIB_CTX in a provider that is not built-in. Periodt. Because the OSSL_LIB_CTX of the library loading the provider might be a completely different structure than the OSSL_LIB_CTX of the library the provider is linked to. Instead, use OSSL_LIB_CTX_new_child(3) to obtain a proper library context that's linked to the application library context. Do not freestyle this one πŸ™ˆ
  • core_new_error(), core_set_error_debug() and core_vset_error() β€” these three are the building blocks for reporting an error back to the core, with reference to the handle. The girlies of error reporting πŸ’…
    • core_new_error()
      • allocates a new thread specific error record.
      • This corresponds to the OpenSSL function ERR_new(3).
    • core_set_error_debug()
      • sets debugging information in the current thread specific error record. That debugging info includes the name of the file file, the line line and the function name func where the error occurred.
      • This corresponds to the OpenSSL function ERR_set_debug(3).
    • core_vset_error()
      • sets the reason for the error, plus any additional data. The reason is a number defined by the provider and used to index the reason strings table that's returned by provider_get_reason_strings(). The additional data comes in as a format string fmt and a set of arguments args, which get treated in the same manner as with BIO_vsnprintf(). You may also pass file and line to indicate exactly where the error occurred or was reported.
      • This corresponds to the OpenSSL function ERR_vset_error(3).
  • core_set_error_mark() β€” sets a mark on the current topmost error record</> if there is one. Corresponds to the OpenSSL function ERR_set_mark(3) πŸ“Œ
  • core_clear_last_error_mark() β€” removes the last mark added, if there is one. Corresponds to the OpenSSL function ERR_clear_last_mark(3) 🧼
  • core_pop_error_to_mark() β€” pops the top of the error stack until a mark is found. The mark then gets removed. And if there's no mark, the whole stack comes off. Corresponds to the OpenSSL function ERR_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 just get the number of entries in the error stack back. Corresponds to the OpenSSL function ERR_count_to_mark(3) πŸ”’
  • core_obj_create() β€” registers a brand new OID plus its associated short name sn and long name ln for the given handle. It's similar to the OpenSSL function OBJ_create(3), except that it returns 1 on success or 0 on failure. And here's the lil twist: it treats as success the case where the OID already exists β€” even if the short name sn or long name ln you passed as arguments differ from those associated with the existing OID, in which case the new names are not associated. No drama, just vibes ✨
  • core_obj_add_sigid() β€” registers a new composite signature algorithm (sign_name) made up 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 as well as for the underlying signature and digest algorithms 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 β€” so any name (OID, short name or long name) can be used to identify the object. It treats as success the case where the composite signature algorithm already exists, even if it's registered against a different underlying signature or digest algorithm. For digest_name, NULL or an empty string is permissible, for signature algorithms that don't need a digest to operate correctly. The function returns 1 on success or 0 on failure. Multi-tasking queen πŸ‘‘
  • 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() and OPENSSL_hexstr2buf() β€” all of these correspond exactly to the public functions with the same name. As a matter of fact, the pointers in the OSSL_DISPATCH(3) array are typically direct pointers to those public functions. But ngl, heads up: the BIO functions take an OSSL_CORE_BIO type rather than the standard BIO type. 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. Do not try it bestie, it's giving chaos 😭
  • OSSL_SELF_TEST_set_callback() β€” used to set an optional callback that can be passed into a provider. This may be ignored by a provider. No pressure, it's optional πŸ’…
  • 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() β€” 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() β€” 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() β€” 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 and 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 returned to the caller. On error, zero is returned 🌸
  • get_user_nonce() β€” 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() β€” 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() β€” 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 🧚
  • 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. It returns 1 on success or 0 otherwise.
⚠️ Careful bestie: 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. Short and sweet only, no side quests πŸ”₯
  • 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 that this callback is registered. The callback is passed the handle being used for the new provider being loaded, and this provider's data in cbdata. It should return 1 on success or 0 on 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 in cbdata. It should return 1 on success or 0 on failure.
  • global_props_cb β€” a callback that gets called when the global properties from the parent library context are changed. It should return 1 on success or 0 on 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. Clean up after yourself, queen πŸŽ€
  • provider_name() β€” returns a string giving the name of the provider identified by handle 🏷️
  • provider_get0_provider_ctx() β€” returns the provider context that is 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. It 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 is not already loaded. It returns 1 on success or 0 on failure ⬇️

✨ provider_teardown()

so bestie, provider_teardown() gets called when your provider is getting shut down and yeeted out of the core's provider store. it has to free the provctx that was passed in. no ghost contexts left behind, periodt πŸ’…

✨ provider_gettable_params()

this one should return a constant array of descriptor OSSL_PARAM(3), listing out the parameters that provider_get_params() can actually handle. it's basically the menu of what you're serving.

✨ provider_get_params()

should process that OSSL_PARAM(3) array called params, and set the values of the parameters it understands. if it's not on the menu from provider_gettable_params(), it's not its problem bestie πŸ™ˆ

✨ provider_query_operation()

should return a constant OSSL_ALGORITHM(3) that matches the given operation_id. it also needs to say whether the core is allowed to stash a reference to this array β€” by setting *no_store to 0 (core may store a reference πŸ’–) or 1 (core may not store a reference 🚫).

✨ provider_unquery_operation()

this is the "okay you can let go now" function πŸ’” β€” it tells the provider that the result of a provider_query_operation() is no longer directly needed, and that the function pointers have been copied. the operation_id should match the one you passed to provider_query_operation(), and algs should be its return value.

✨ provider_get_reason_strings()

should return a constant OSSL_ITEM(3) array giving you reason strings for the reason codes the provider might use when it's reporting errors via core_put_error(). receipts for your receipts ✨

✨ provider_get_capabilities()

this function should call the callback cb, passing it a set of OSSL_PARAM(3)s plus the caller-supplied argument arg. those OSSL_PARAM(3)s should give details about the capability with the name given in the capability argument, relevant to the provider context provctx. if a provider supports multiple capabilities with the same name, it may call the callback multiple times β€” one call for each capability, no gatekeeping 🫢. capabilities are lowkey useful for describing the services a provider can offer. for the full lore, check out the "CAPABILITIES" section below πŸ‘‡. it should return 1 on success or 0 on error.

✨ provider_self_test()

this one should run known answer tests on a subset of the algorithms it uses, and it may also verify the integrity of the provider module (vibe check πŸ”). it should return 1 on success or 0 on error. it'll return 1 if this function isn't used at all.


okay so none of these functions are mandatory, but ngl a provider is genuinely useless without at least provider_query_operation(), and provider_gettable_params() is pretty useless if it isn't accompanied by provider_get_params(). they're a package deal, iykyk πŸ’€

πŸŽ€ Provider parameters

provider_get_params() can hand the core the following provider parameters:

  • "name" (OSSL_PROV_PARAM_NAME) <UTF8 ptr> β€” points to a string that should give a unique name for the provider.
  • "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 use OPENSSL_VERSION_STR, but third-party providers can do their own thing. heads up: this string is for informational purposes only.
  • "buildinfo" (OSSL_PROV_PARAM_BUILDINFO) <UTF8 ptr> β€” points to a string that's build info associated with this provider. OpenSSL's in-built providers use OPENSSL_FULL_VERSION_STR, but again, any third party provider may differ.
  • "status" (OSSL_PROV_PARAM_STATUS) <signed integer> β€” returns 0 if the provider has entered an error state, otherwise it returns 1. (so 0 = not slaying, 1 = thriving 🌈)

provider_gettable_params() should return the parameters listed above, bestie. all of them.

πŸ¦‹ Core parameters

core_get_params() can retrieve the following 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 macro OPENSSL_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. (yes, they have their own opinion of you 😭)
  • "module-filename" (OSSL_PROV_PARAM_CORE_MODULE_FILENAME) <UTF8 string ptr> β€” points to a string containing the full filename of the providers module file.

plus, provider-specific configuration parameters from the config file are also available, in dotted name form. dotted name form = a concatenation of section names plus the final config command name, all separated by periods ✨

for example, say we have this config:

 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

then the provider will have these extra 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 info on handling parameters, see OSSL_PARAM(3) as OSSL_PARAM_int(3). πŸ’œ

πŸ‘‘ CAPABILITIES

capabilities describe some of the services a provider can offer, and applications can query them to discover those services. it's giving talent showcase πŸ’…

⭐ "TLS-GROUP" Capability

the "TLS-GROUP" capability can be queried by libssl to discover the list of TLS groups a provider can support. each supported group 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. this way, a provider can add to the list of groups libssl already supports with extra ones. iconic behavior fr fr πŸ”₯

each TLS group a provider supports should be described via the callback passed in through the provider_get_capabilities function. each group should have the following details supplied β€” all 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 the "tls-group-name", but it doesn't have to be.
  • "tls-group-id" (OSSL_CAPABILITY_TLS_GROUP_ID) <unsigned integer> β€” the TLS group id value as given in the IANA TLS Supported Groups registry.

it's 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 is unspecified which implementation for a particular group id will be used. (chaos, honestly πŸ’€)

  • "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 optional OSSL_CAPABILITY_TLS_GROUP_IS_KEM flag. the algorithm must support key and parameter generation, as well as the key/parameter generation parameter, OSSL_PKEY_PARAM_GROUP_NAME. the group name given via "tls-group-name-internal" above will be passed via OSSL_PKEY_PARAM_GROUP_NAME when libssl wishes to generate keys/parameters.
  • "tls-group-sec-bits" (OSSL_CAPABILITY_TLS_GROUP_SECURITY_BITS) <unsigned integer> β€” the number of bits of security offered by keys in this group. this 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> β€” a 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 it isn't specified, KEX mode is assumed as the default mode for the group.

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.

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

⭐ "TLS-SIGALG" Capability

the "TLS-SIGALG" capability can be queried by libssl to discover the list of TLS signature algorithms a provider can support. each supported signature can be used for client- or server-authentication, on top of 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 yeah, a provider can add to the list of signature algorithms libssl already supports with extra ones πŸŽ€

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.
  • "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.
  • same code point, different providers? okay so yeah it's possible to register the same code point from within totally different providers. But bestie, listen: if you don't specify a property query, or more than one implementation matches your property query β€” then it's unspecified which implementation gets used for that particular code point. Like, nobody's promising you anything. πŸ™ˆ
  • "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, then this is assumed to be a composite of a pure signature algorithm plus a hash algorithm, and those have to be handed over via the "sig-name" and "hash-name" parameters. This value must be supplied.
  • "sigalg-oid" (OSSL_CAPABILITY_TLS_SIGALG_OID) <UTF8 string> β€” the OID of the "sigalg-name" algorithm, in canonical numeric text form. If you give this parameter, then OBJ_create() gets used to create an OBJ and a NID for this OID, using the "sigalg-name" parameter for its (short) name. If you don't give it, it's assumed to already exist in the object database β€” possibly done by the provider with the core_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's part of a composite "sigalg-name". Heads up: if "sigalg-name" is implemented by the provider, this parameter is redundant and must not be given. This value is optional.
  • "sig-oid" (OSSL_CAPABILITY_TLS_SIGALG_SIG_OID) <UTF8 string> β€” the OID of the "sig-name" algorithm in canonical numeric text form. Give it, and OBJ_create() will be used to create an OBJ and a NID for this OID, using the "sig-name" parameter for its (short) name. Otherwise it's assumed to already exist in the object database. That one can be done by the provider using the core_obj_create() upcall. This value is optional.
  • "hash-name" (OSSL_CAPABILITY_TLS_SIGALG_HASH_NAME) <UTF8 string> β€” the name of the hash algorithm that's part of a composite "sigalg-name". Same energy as above: 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 given, OBJ_create() will be used to create an OBJ and a NID for 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 the core_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, and otherwise "sigalg-name". This value is optional.
  • "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 an OBJ and a NID for 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 the core_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. That number should be comparable with the ones given in table 2 and 3 of the NIST SP800-57 document. It's used to determine the security strength of the algorithm when no digest algorithm has been registered that otherwise defines the security strength. And if the signature algorithm implements its own digest internally, you need to set this value so it properly reflects the overall security strength. This value must be supplied.
  • "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 let you 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 means there's no defined minimum or maximum. A -1 in either the min or max field means the signature algorithm should not be used in that protocol. And presently, provider signature algorithms are used only with TLS 1.3 β€” if that's enclosed in the specified range. πŸ¦‹


🌸 NOTES 🌸

The core_obj_create() and core_obj_add_sigid() functions were not thread safe in OpenSSL 3.0. πŸ’€


✨ EXAMPLES ✨

Okay bestie, here's an example of a simple provider made available as a dynamically loadable module. It implements the fictitious algorithm "FOO" for the fictitious operation "BAR". iconic honestly

#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;
}

And 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 🫢

πŸ“œ HISTORY ✨

Okay so storytime bestie 🫢 the whole concept of providers β€” like, every single thing surrounding them, the entire vibe β€” was introduced in OpenSSL 3.0. Iconic era, honestly. πŸ‘‘

And then, a little later, the definitions for OSSL_CAPABILITY_TLS_SIGALG_MIN_DTLS and OSSL_CAPABILITY_TLS_SIGALG_MAX_DTLS got added in OpenSSL 3.5. Glow up moment fr fr. πŸ’…


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. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

Okay so lowkey important: use it in compliance with the License, that's the whole point 🫢

And that's a wrap on PROVIDER-BASE(7SSL) bestie!! πŸŽ€ This page came to you from OpenSSL 4.0.3, dated 2026-09-29 β€” it's giving ✨ documentation royalty ✨, no cap. Go forth and provider, my love. πŸ¦‹πŸ’œ

πŸ“¦ where this page comes from