PROVIDER-SIGNATURE(7ossl)
✨ NAME ✨
provider-signature — the signature library <-> provider functions 🫶
(Also, hi, this is the 7ossl OpenSSL manual page for it, one of the whole provider-* family, and we're literally about to get into it 💅)
🌸 SYNOPSIS 🌸
#include <openssl/core_dispatch.h>
#include <openssl/core_names.h>
/*
* None of these are actual functions, but are displayed like this for
* the function signatures for functions that are offered as function
* pointers in OSSL_DISPATCH arrays.
*/
/* Context management */
void *OSSL_FUNC_signature_newctx(void *provctx, const char *propq);
void OSSL_FUNC_signature_freectx(void *ctx);
void *OSSL_FUNC_signature_dupctx(void *ctx);
/* Get the key types that a signature algorithm supports */
const char **OSSL_FUNC_signature_query_key_types(void);
/* Signing */
int OSSL_FUNC_signature_sign_init(void *ctx, void *provkey,
const OSSL_PARAM params[]);
int OSSL_FUNC_signature_sign(void *ctx, unsigned char *sig, size_t *siglen,
size_t sigsize, const unsigned char *tbs, size_t tbslen);
int OSSL_FUNC_signature_sign_message_init(void *ctx, void *provkey,
const OSSL_PARAM params[]);
int OSSL_FUNC_signature_sign_message_update(void *ctx, const unsigned char *in,
size_t inlen);
int OSSL_FUNC_signature_sign_message_final(void *ctx, unsigned char *sig,
size_t *siglen, size_t sigsize);
/* Verifying */
int OSSL_FUNC_signature_verify_init(void *ctx, void *provkey,
const OSSL_PARAM params[]);
int OSSL_FUNC_signature_verify(void *ctx, const unsigned char *sig, size_t siglen,
const unsigned char *tbs, size_t tbslen);
int OSSL_FUNC_signature_verify_message_init(void *ctx, void *provkey,
const OSSL_PARAM params[]);
int OSSL_FUNC_signature_verify_message_update(void *ctx, const unsigned char *in,
size_t inlen);
/*
* OSSL_FUNC_signature_verify_message_final requires that the signature to be
* verified is specified via a "signature" OSSL_PARAM, which is given with a
* previous call of OSSL_FUNC_signature_set_ctx_params().
*/
int OSSL_FUNC_signature_verify_message_final(void *ctx);
/* Verify Recover */
int OSSL_FUNC_signature_verify_recover_init(void *ctx, void *provkey,
const OSSL_PARAM params[]);
int OSSL_FUNC_signature_verify_recover(void *ctx, unsigned char *rout,
size_t *routlen, size_t routsize,
const unsigned char *sig, size_t siglen);
/* Digest Sign */
int OSSL_FUNC_signature_digest_sign_init(void *ctx, const char *mdname,
void *provkey,
const OSSL_PARAM params[]);
int OSSL_FUNC_signature_digest_sign_update(void *ctx, const unsigned char *data,
size_t datalen);
int OSSL_FUNC_signature_digest_sign_final(void *ctx, unsigned char *sig,
size_t *siglen, size_t sigsize);
int OSSL_FUNC_signature_digest_sign(void *ctx,
unsigned char *sig, size_t *siglen,
size_t sigsize, const unsigned char *tbs,
size_t tbslen);
/* Digest Verify */
int OSSL_FUNC_signature_digest_verify_init(void *ctx, const char *mdname,
void *provkey,
const OSSL_PARAM params[]);
int OSSL_FUNC_signature_digest_verify_update(void *ctx,
const unsigned char *data,
size_t datalen);
int OSSL_FUNC_signature_digest_verify_final(void *ctx, const unsigned char *sig,
size_t siglen);
int OSSL_FUNC_signature_digest_verify(void *ctx, const unsigned char *sig,
size_t siglen, const unsigned char *tbs,
size_t tbslen);
/* Signature parameters */
int OSSL_FUNC_signature_get_ctx_params(void *ctx, OSSL_PARAM params[]);
const OSSL_PARAM *OSSL_FUNC_signature_gettable_ctx_params(void *ctx,
void *provctx);
int OSSL_FUNC_signature_set_ctx_params(void *ctx, const OSSL_PARAM params[]);
const OSSL_PARAM *OSSL_FUNC_signature_settable_ctx_params(void *ctx,
void *provctx);
/* MD parameters */
int OSSL_FUNC_signature_get_ctx_md_params(void *ctx, OSSL_PARAM params[]);
const OSSL_PARAM * OSSL_FUNC_signature_gettable_ctx_md_params(void *ctx);
int OSSL_FUNC_signature_set_ctx_md_params(void *ctx, const OSSL_PARAM params[]);
const OSSL_PARAM * OSSL_FUNC_signature_settable_ctx_md_params(void *ctx);🦋 DESCRIPTION 🦋
Okay so real talk: this documentation is primarily aimed at provider authors. If that's not you, go read provider(7) first for the bigger picture, k? 💖
The signature operation — that's OSSL_OP_SIGNATURE, bestie — is what lets providers implement signature algorithms and make them available to applications through the API functions EVP_PKEY_sign(3), EVP_PKEY_verify(3), and EVP_PKEY_verify_recover(3) (plus all the other related functions in that friend group).
Now, every "function" mentioned on this page? Not a real function, babes. They're passed as function pointers between libcrypto and the provider inside OSSL_DISPATCH(3) arrays, which get handed over via OSSL_ALGORITHM(3) arrays that come back from the provider's provider_query_operation() function (peep "Provider Functions" in provider-base(7) for that part 👀).
Every single one of these "functions" has a matching function type definition named OSSL_FUNC_{name}_fn, plus a lil helper function that fishes the function pointer out of an OSSL_DISPATCH(3) element, named OSSL_FUNC_{name}. For example, the "function" OSSL_FUNC_signature_newctx() has these two:
typedef void *(OSSL_FUNC_signature_newctx_fn)(void *provctx, const char *propq);
static ossl_inline OSSL_FUNC_signature_newctx_fn
OSSL_FUNC_signature_newctx(const OSSL_DISPATCH *opf);OSSL_DISPATCH(3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h(7), and the mapping is exactly this, no cap:
OSSL_FUNC_signature_newctx OSSL_FUNC_SIGNATURE_NEWCTX
OSSL_FUNC_signature_freectx OSSL_FUNC_SIGNATURE_FREECTX
OSSL_FUNC_signature_dupctx OSSL_FUNC_SIGNATURE_DUPCTX
OSSL_FUNC_signature_query_key_types OSSL_FUNC_SIGNATURE_QUERY_KEY_TYPES
OSSL_FUNC_signature_sign_init OSSL_FUNC_SIGNATURE_SIGN_INIT
OSSL_FUNC_signature_sign OSSL_FUNC_SIGNATURE_SIGN
OSSL_FUNC_signature_sign_message_init OSSL_FUNC_SIGNATURE_SIGN_MESSAGE_INIT
OSSL_FUNC_signature_sign_message_update OSSL_FUNC_SIGNATURE_SIGN_MESSAGE_UPDATE
OSSL_FUNC_signature_sign_message_final OSSL_FUNC_SIGNATURE_SIGN_MESSAGE_FINAL
OSSL_FUNC_signature_verify_init OSSL_FUNC_SIGNATURE_VERIFY_INIT
OSSL_FUNC_signature_verify OSSL_FUNC_SIGNATURE_VERIFY
OSSL_FUNC_signature_verify_message_init OSSL_FUNC_SIGNATURE_VERIFY_MESSAGE_INIT
OSSL_FUNC_signature_verify_message_update OSSL_FUNC_SIGNATURE_VERIFY_MESSAGE_UPDATE
OSSL_FUNC_signature_verify_message_final OSSL_FUNC_SIGNATURE_VERIFY_MESSAGE_FINAL
OSSL_FUNC_signature_verify_recover_init OSSL_FUNC_SIGNATURE_VERIFY_RECOVER_INIT
OSSL_FUNC_signature_verify_recover OSSL_FUNC_SIGNATURE_VERIFY_RECOVER
OSSL_FUNC_signature_digest_sign_init OSSL_FUNC_SIGNATURE_DIGEST_SIGN_INIT
OSSL_FUNC_signature_digest_sign_update OSSL_FUNC_SIGNATURE_DIGEST_SIGN_UPDATE
OSSL_FUNC_signature_digest_sign_final OSSL_FUNC_SIGNATURE_DIGEST_SIGN_FINAL
OSSL_FUNC_signature_digest_sign OSSL_FUNC_SIGNATURE_DIGEST_SIGN
OSSL_FUNC_signature_digest_verify_init OSSL_FUNC_SIGNATURE_DIGEST_VERIFY_INIT
OSSL_FUNC_signature_digest_verify_update OSSL_FUNC_SIGNATURE_DIGEST_VERIFY_UPDATE
OSSL_FUNC_signature_digest_verify_final OSSL_FUNC_SIGNATURE_DIGEST_VERIFY_FINAL
OSSL_FUNC_signature_digest_verify OSSL_FUNC_SIGNATURE_DIGEST_VERIFY
OSSL_FUNC_signature_get_ctx_params OSSL_FUNC_SIGNATURE_GET_CTX_PARAMS
OSSL_FUNC_signature_gettable_ctx_params OSSL_FUNC_SIGNATURE_GETTABLE_CTX_PARAMS
OSSL_FUNC_signature_set_ctx_params OSSL_FUNC_SIGNATURE_SET_CTX_PARAMS
OSSL_FUNC_signature_settable_ctx_params OSSL_FUNC_SIGNATURE_SETTABLE_CTX_PARAMS
OSSL_FUNC_signature_get_ctx_md_params OSSL_FUNC_SIGNATURE_GET_CTX_MD_PARAMS
OSSL_FUNC_signature_gettable_ctx_md_params OSSL_FUNC_SIGNATURE_GETTABLE_CTX_MD_PARAMS
OSSL_FUNC_signature_set_ctx_md_params OSSL_FUNC_SIGNATURE_SET_CTX_MD_PARAMS
OSSL_FUNC_signature_settable_ctx_md_params OSSL_FUNC_SIGNATURE_SETTABLE_CTX_MD_PARAMS🌈 the vibe check: what you actually have to implement
Okay, a signature algorithm implementation may not implement all of these functions. But to be a consistent set of functions — like, a valid, coherent one — you must have at least a set of context functions (OSSL_FUNC_signature_newctx and OSSL_FUNC_signature_freectx) as well as a set of "signature" functions, meaning at least one of these combos:
OSSL_FUNC_signature_sign_initandOSSL_FUNC_signature_signOSSL_FUNC_signature_sign_message_initandOSSL_FUNC_signature_signOSSL_FUNC_signature_sign_message_init,OSSL_FUNC_signature_sign_message_updateandOSSL_FUNC_signature_sign_message_finalOSSL_FUNC_signature_verify_initandOSSL_FUNC_signature_verifyOSSL_FUNC_signature_verify_message_initandOSSL_FUNC_signature_verifyOSSL_FUNC_signature_verify_message_init,OSSL_FUNC_signature_verify_message_updateandOSSL_FUNC_signature_verify_message_finalOSSL_FUNC_signature_verify_recover_initandOSSL_FUNC_signature_verify_recoverOSSL_FUNC_signature_digest_sign_init,OSSL_FUNC_signature_digest_sign_updateandOSSL_FUNC_signature_digest_sign_finalOSSL_FUNC_signature_digest_verify_init,OSSL_FUNC_signature_digest_verify_updateandOSSL_FUNC_signature_digest_verify_finalOSSL_FUNC_signature_digest_sign_initandOSSL_FUNC_signature_digest_signOSSL_FUNC_signature_digest_verify_initandOSSL_FUNC_signature_digest_verify
OSSL_FUNC_signature_set_ctx_params and OSSL_FUNC_signature_settable_ctx_params are optional — but ✨the rules✨ say if one of them is present then the other one must also be present. Same energy applies to OSSL_FUNC_signature_get_ctx_params and OSSL_FUNC_signature_gettable_ctx_params, and also to the "md_params" functions. And OSSL_FUNC_signature_dupctx is optional too. 🎀
One last thing, and it's lowkey important: a signature algorithm must also implement some mechanism for generating, loading or importing keys via the key management (OSSL_OP_KEYMGMT) operation. Go seeprovider-keymgmt(7)for the details on that one 🫶
🫶 Context Management Functions 🫶
OSSL_FUNC_signature_newctx()— bestie, this one's job is to make the context and hand back a pointer to a provider-side structure that holds all the context info while a signature operation is happening. That pointer gets passed right back into a bunch of the other signature operation function calls later (it's giving main character energy, everyone needs it). Theprovctxparameter is the provider context that got generated during provider initialisation (peepprovider(7)for that one). And thepropqparameter is a property query string that the provider may use — optionally! — during any "fetches" it decides to perform (if it performs any at all, no pressure).OSSL_FUNC_signature_freectx()— gets handed a pointer to the provider-side signature context in thectxparameter, and it should free every resource associated with that context. Clean up your room, queen 💅OSSL_FUNC_signature_dupctx()— should duplicate the provider-side signature context in thectxparameter and return the duplicate copy. Clone it, slay it, return it ✨
✍️ Signing Functions ✍️
OSSL_FUNC_signature_sign_init() initialises a context for signing. You pass the provider-side signature context in ctx, plus a pointer to a provider key object in provkey. If params isn't NULL, it should be set on the context in a manner similar to using OSSL_FUNC_signature_set_ctx_params(). And ngl, that key object should've been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt(7)) — that's the whole vibe check for getting a key in there.
OSSL_FUNC_signature_sign() performs the actual signing itself, fr fr. A previously initialised signature context comes in through ctx. The data to be signed is pointed to by the tbs parameter, which is tbslen bytes long. Unless sig is NULL, the signature should be written to the location pointed to by the sig parameter, and it should not exceed sigsize bytes in length — do not overrun, that's so not the move 😭. The length of the signature should be written to *siglen. If sig is NULL, then the maximum length of the signature should be written to *siglen instead (a little sizing hint, how thoughtful 🎀).
💌 Message Signing Functions 💌
These functions are the moment for providers that implement algorithms which accumulate a full message and then sign the result of that accumulation — think RSA-SHA256. Accumulate first, sign after. Obsessed with the pipeline.
OSSL_FUNC_signature_sign_message_init() initialises a context for signing a message, given a provider-side signature context in ctx and a pointer to a provider key object in provkey. If params is not NULL, it should be set on the context in a manner similar to using OSSL_FUNC_signature_set_ctx_params(). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt(7)).
OSSL_FUNC_signature_sign_message_update() gathers the data pointed at by in, which is inlen bytes long. Just gathering. Collecting the vibes. 🌸
OSSL_FUNC_signature_sign_message_final() performs the actual signing on the data that was gathered with OSSL_FUNC_signature_sign_message_update().
OSSL_FUNC_signature_sign() can be used for one-shot signature calls too 🫶. In that case, tbs is expected to be the whole entire message to be signed, tbslen bytes long.
For bothOSSL_FUNC_signature_sign_message_final()andOSSL_FUNC_signature_sign(): ifsigis notNULL, the signature should be written to the location pointed to bysig, and it should not exceedsigsizebytes in length. The length of the signature should be written to*siglen. IfsigisNULL, then the maximum length of the signature should be written to*siglen. Same rules, no exceptions, periodt.
🔍 Verify Functions 🔍
OSSL_FUNC_signature_verify_init() initialises a context for verifying a signature, given a provider-side signature context in ctx and a pointer to a provider key object in provkey. If params is not NULL, it should be set on the context in a manner similar to using OSSL_FUNC_signature_set_ctx_params(). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt(7)).
OSSL_FUNC_signature_verify() performs the actual verification itself, the real main character moment. A previously initialised signature context is passed in ctx. The data that the signature covers is pointed to by the tbs parameter, which is tbslen bytes long. The signature is pointed to by the sig parameter, which is siglen bytes long. Check it, confirm it, iconic ✅
🔎 Message Verify Functions 🔎
These functions are for providers that implement algorithms which accumulate a full message and then verify a signature on the result of that accumulation — again, RSA-SHA256 is the blueprint.
OSSL_FUNC_signature_verify_message_init() initialises a context for verifying a signature on a message, given a provider-side signature context in ctx and a pointer to a provider key object in provkey. If params is not NULL, it should be set on the context in a manner similar to using OSSL_FUNC_signature_set_ctx_params(). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt(7)).
OSSL_FUNC_signature_verify_message_update() gathers the data pointed at by in, which is inlen bytes long.
OSSL_FUNC_signature_verify_message_final() performs the actual verification on the data that was gathered with OSSL_FUNC_signature_verify_message_update(). Important detail, bestie: the signature itself must have been passed through the "signature" (OSSL_SIGNATURE_PARAM_SIGNATURE) Signature parameter before this function is called. Order matters, always has 💅
OSSL_FUNC_signature_verify() can be used for one-shot verification calls. In that case, tbs is expected to be the whole message to be verified on, tbslen bytes long.
🌈 Verify Recover Functions 🌈
OSSL_FUNC_signature_verify_recover_init() initialises a context for recovering the signed data, given a provider-side signature context in ctx and a pointer to a provider key object in provkey. If params is not NULL, it should be set on the context in a manner similar to using OSSL_FUNC_signature_set_ctx_params(). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt(7)).
OSSL_FUNC_signature_verify_recover() performs the actual verify recover itself. A previously initialised signature context is passed in ctx. The signature is pointed to by the sig parameter, which is siglen bytes long. Unless rout is NULL, the recovered data should be written to the location pointed to by rout, which should not exceed routsize bytes in length. The length of the recovered data should be written to *routlen. If rout is NULL, then the maximum size of the output buffer is written to the routlen parameter — a little look-before-you-leap situation 🦋
🧚 Digest Sign Functions 🧚
OSSL_FUNC_signature_digest_sign_init() initialises a context for signing, given a provider-side signature context in ctx and a pointer to a provider key object in provkey. If params is not NULL, it should be set on the context in a manner similar to using OSSL_FUNC_signature_set_ctx_params() and OSSL_FUNC_signature_set_ctx_md_params() (both of them, yes, both). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt(7)). The name of the digest to be used will be in the mdname parameter.
OSSL_FUNC_signature_digest_sign_update() provides data to be signed in the data parameter, which should be of length datalen. A previously initialised signature context is passed in ctx. This function may be called multiple times to cumulatively add data to be signed. Feed it, feed it again, keep feeding it 🍓
OSSL_FUNC_signature_digest_sign_final() finalises a signature operation that was previously started through OSSL_FUNC_signature_digest_sign_init() and OSSL_FUNC_signature_digest_sign_update() calls. Once it's finalised, no more data will be added through OSSL_FUNC_signature_digest_sign_update() — door's closed, bestie 🙈. A previously initialised signature context is passed in ctx. Unless sig is NULL, the signature should be written to the location pointed to by the sig parameter, and it should not exceed sigsize bytes in length. The length of the signature should be written to *siglen. If sig is NULL, then the maximum length of the signature should be written to *siglen.
OSSL_FUNC_signature_digest_sign() implements a "one shot" digest sign operation previously started through OSSL_FUNC_signature_digeset_sign_init() (yes, that's how it's spelled in the source, we keep it exactly as-is 💀). A previously initialised signature context is passed in ctx. The data to be signed is in tbs, which should be tbslen bytes long. Unless sig is NULL, the signature should be written to the location pointed to by the sig parameter, and it should not exceed sigsize bytes in length. The length of the signature should be written to *siglen. If sig is NULL, then the maximum length of the signature should be written to *siglen.
🎀 Digest Verify Functions 🎀
OSSL_FUNC_signature_digeset_verify_init() initialises a context for verifying, given a provider-side verification context in ctx and a pointer to a provider key object in provkey. If params is not NULL, it should be set on the context in a manner similar to using OSSL_FUNC_signature_set_ctx_params() and OSSL_FUNC_signature_set_ctx_md_params(). The key object should have been previously generated, loaded or imported into the provider using the key management (OSSL_OP_KEYMGMT) operation (see provider-keymgmt(7)). The name of the digest to be used will be in the mdname parameter.
OSSL_FUNC_signature_digest_verify_update() provides data to be verified in the data parameter, which should be of length datalen. A previously initialised verification context is passed in ctx. This function may be called multiple times to cumulatively add data to be verified. Accumulate the receipts 📋
OSSL_FUNC_signature_digest_verify_final() finalises a verification operation previously started through OSSL_FUNC_signature_digest_verify_init() and OSSL_FUNC_signature_digest_verify_update() calls. Once finalised, no more data will be added through OSSL_FUNC_signature_digest_verify_update(). A previously initialised verification context is passed in ctx. The signature to be verified is in sig, which is siglen bytes long.
OSSL_FUNC_signature_digest_verify() implements a "one shot" digest verify operation previously started through OSSL_FUNC_signature_digeset_verify_init(). A previously initialised verification context is passed in ctx. The data to be verified is in tbs, which should be tbslen bytes long. The signature to be verified is in sig, which is siglen bytes long.
⭐ Signature parameters ⭐
See OSSL_PARAM(3) for further details on the parameters structure that the OSSL_FUNC_signature_get_ctx_params() and OSSL_FUNC_signature_set_ctx_params() functions use. Go read it, it's giving essential lore 🔥
OSSL_FUNC_signature_get_ctx_params()— okay so this one grabs the signature params that belong to the provider-side signature contextctxand drops them intoparams. And if you passNULLforparams? It should totally return true. That's the vibe check. 💅OSSL_FUNC_signature_set_ctx_params()— this sets the signature params of the given provider side signature contextctxtoparams. Heads up: any parameter settings you do here are additional to whatever was set before (it doesn't wipe them, bestie). PassingNULLforparamsshould return true too.
So the common parameters that built-in signature algorithms actually recognise right now are these cuties 👇
"digest"(OSSL_SIGNATURE_PARAM_DIGEST)<UTF8 string>— gets or sets the name of the digest algorithm used for the input to the signature functions. It's literally required in order to calculate the"algorithm-id". No digest, no algorithm-id, periodt."properties"(OSSL_SIGNATURE_PARAM_PROPERTIES)<UTF8 string>— sets the name of the property query associated with the"digest"algorithm. If this optional value isn't set,NULLis used. That's it, that's the whole thing.
Okay important aside, listen up 🙈 — when you're implementing a signature algorithm that gathers a full message, likeRSA-SHA256, the"digest"and"properties"parameters should not be used. For those implementations it's fine and honestly kind of iconic to just ignore them if they get passed in a call toOSSL_FUNC_signature_set_ctx_params(). BUT — and this is the part that matters — it is not acceptable to have them in theOSSL_PARAMarray returned byOSSL_FUNC_signature_settable_ctx_params(). Don't do that. 🫶
"signature"(OSSL_SIGNATURE_PARAM_SIGNATURE)<octet string>— sets the signature to be verified, specifically for whenOSSL_FUNC_signature_verify_message_final()is being used. That's the moment this one shines. ✨"digest-size"(OSSL_SIGNATURE_PARAM_DIGEST_SIZE)<unsigned integer>— gets or sets the output size of the digest algorithm used for the input to the signature functions. The length of the"digest-size"parameter should not exceed that of asize_t. Respect thesize_t, bestie."algorithm-id"(OSSL_SIGNATURE_PARAM_ALGORITHM_ID)<octet string>— gets the DER encodedAlgorithmIdentifierthat corresponds to the combination of signature algorithm and digest algorithm for the signature operation. Fancy encoding moment. 🎀"nonce-type"(OSSL_SIGNATURE_PARAM_NONCE_TYPE)<unsigned integer>— set this to1to use deterministic digital signature generation with ECDSA or DSA, as defined in RFC 6979 (see Section 3.2"Generation of k"). In this case the"digest"parameter must be explicitly set, otherwise deterministic nonce generation will fail — no digest, no k, we die. 😭 And before you go using deterministic digital signature generation, please actually read RFC 6979 Section 4"Security Considerations". The default value for"nonce-type"is0, which results in a random value being used for the nonce k as defined in FIPS 186-4 Section 6.3"Secret Number Generation".
Also fr fr: the FIPS provider does not support deterministic digital signature generation. That's just facts. 💀
"kat"(OSSL_SIGNATURE_PARAM_KAT)<unsigned integer>— sets a flag that modifies the sign operation so it returns an error if the initial calculated signature is invalid. In the normal mode of operation, new random values are chosen until the signature operation succeeds, and by default it retries until a signature is calculated. Setting the value to0causes the sign operation to retry; otherwise the sign operation is only tried once and returns whether or not it was successful. Known answer tests can be performed if the random generator is overridden to supply known values that either pass or fail. Very clever, very demure. 🧚
The following parameters are used by the OpenSSL FIPS provider:
"fips-indicator"(OSSL_SIGNATURE_PARAM_FIPS_APPROVED_INDICATOR)<integer>— a getter that returns1if the operation is FIPS approved, or0otherwise. You can use this after calling either the sign or verify final functions. It may return0if either the"digest-check","key-check", or"sign-check"are set to0."verify-message"(OSSL_SIGNATURE_PARAM_FIPS_VERIFY_MESSAGE<integer>— a getter that returns1if a signature verification operation acted on a raw message, or0if it verified a predigested message. A value of0indicates likely non-approved usage of the FIPS provider (🚨 red flag). This flag is set when any signature verification initialisation function is called. It is also set to1when any signing operation is performed to signify compliance. See FIPS 140-3 IG 2.4.B for further information."key-check"(OSSL_SIGNATURE_PARAM_FIPS_KEY_CHECK)<integer>— if required, this parameter should be set early via an init function (e.g.OSSL_FUNC_signature_sign_init()orOSSL_FUNC_signature_verify_init()). The default value of1causes an error during the init if the key is not FIPS approved (e.g. the key has a security strength of less than 112 bits). Setting this to0will ignore the error and set the approved"fips-indicator"to0. This option breaks FIPS compliance if it causes the approved"fips-indicator"to return0. ⚠️"digest-check"(OSSL_SIGNATURE_PARAM_FIPS_DIGEST_CHECK)<integer>— if required, this parameter should be set before the signature digest is set. The default value of1causes an error when the digest is set if the digest is not FIPS approved (e.g. SHA1 is used for signing). Setting this to0will ignore the error and set the approved"fips-indicator"to0. This option breaks FIPS compliance if it causes the approved"fips-indicator"to return0. ⚠️"sign-check"(OSSL_SIGNATURE_PARAM_FIPS_SIGN_CHECK)<integer>— if required, this parameter should be set early via an init function. The default value of1causes an error when a signing algorithm is used. (This is triggered by deprecated signing algorithms.) Setting this to0will ignore the error and set the approved"fips-indicator"to0. This option breaks FIPS compliance if it causes the approved"fips-indicator"to return0. ⚠️"sign-x931-pad-check"(OSSL_SIGNATURE_PARAM_FIPS_SIGN_X931_PAD_CHECK)<integer>— if required, this parameter should be set before the padding mode is set. The default value of1causes an error if the padding mode is set to X9.31 padding for a RSA signing operation. Setting this to0will ignore the error and set the approved"fips-indicator"to0. This option breaks FIPS compliance if it causes the approved"fips-indicator"to return0. ⚠️
OSSL_FUNC_signature_gettable_ctx_params() and OSSL_FUNC_signature_settable_ctx_params() get a constant OSSL_PARAM(3) array that describes the gettable and settable parameters — i.e. the params you can actually use with OSSL_FUNC_signature_get_ctx_params() and OSSL_FUNC_signature_set_ctx_params() respectively. A little menu of what's allowed. 🌸
🦋 MD parameters 🦋
See OSSL_PARAM(3) for further details on the parameters structure used by the OSSL_FUNC_signature_get_md_ctx_params() and OSSL_FUNC_signature_set_md_ctx_params() functions.
OSSL_FUNC_signature_get_md_ctx_params() gets digest parameters associated with the given provider side digest signature context ctx and stores them in params. Passing NULL for params should return true.
OSSL_FUNC_signature_set_ms_ctx_params() sets the digest parameters associated with the given provider side digest signature context ctx to params. Any parameter settings are additional to any that were previously set. Passing NULL for params should return true. 💜
Parameters currently recognised by built-in signature algorithms are the same as those for built-in digest algorithms. See "Digest Parameters" in provider-digest(7) for further information — go read that one, it's the sibling page. 🫶
OSSL_FUNC_signature_gettable_md_ctx_params() and OSSL_FUNC_signature_settable_md_ctx_params() get a constant OSSL_PARAM(3) array that describes the gettable and settable digest parameters, i.e. parameters that can be used with OSSL_FUNC_signature_get_md_ctx_params() and OSSL_FUNC_signature_set_md_ctx_params() respectively.
✨ RETURN VALUES ✨
OSSL_FUNC_signature_newctx() and OSSL_FUNC_signature_dupctx() should return the newly created provider side signature context, or NULL on failure. No context, sad vibes. 😭
OSSL_FUNC_signature_gettable_ctx_params(), OSSL_FUNC_signature_settable_ctx_params(), OSSL_FUNC_signature_gettable_md_ctx_params() and OSSL_FUNC_signature_settable_md_ctx_params() return the gettable or settable parameters in a constant OSSL_PARAM(3) array.
All other functions should return 1 for success or 0 on error. Simple as that. 1 = slay, 0 = nope. 💅
👀 SEE ALSO 👀
🌈 HISTORY 🌈
The provider SIGNATURE interface was introduced in OpenSSL 3.0. The Signature Parameters "fips-indicator", "key-check" and "digest-check" were added in OpenSSL 3.4. Look at them, growing up so fast. 🥹
🎀 COPYRIGHT 🎀
Copyright 2019-2025 The OpenSSL Project Authors. All Rights Reserved.
Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.
That's the whole page bestie, you made it 🫶 this one's from OpenSSL 3.5.0, dated 2026-09-25, filed under PROVIDER-SIGNATURE(7ossl) — go forth and sign responsibly ✨💖
📦 where this page comes from
- opensuse-leap 16.0: openssl-3 3.5.0-160000.11.1 · Apache-2.0
- opensuse-leap 16.0: openssl-3 3.5.0-160000.11.1 · Apache-2.0
- opensuse-leap 16.0: openssl-3 3.5.0-160000.11.1 · Apache-2.0
- opensuse-leap 16.0: openssl-3 3.5.0-160000.11.1 · Apache-2.0
- 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms