PROVIDER-DECODER(7ossl)
π
PROVIDER-DECODER(7ossl) β The OSSL_DECODER library <-> provider functions
πΈ NAME πΈ
provider-decoder β The OSSL_DECODER library <-> provider functions. This is the page for the decoder-side provider functions, bestie: the bridge between libcrypto and a providerβs decoder implementation. π
β¨ 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.
*/
/* Decoder parameter accessor and descriptor */
const OSSL_PARAM *OSSL_FUNC_decoder_gettable_params(void *provctx);
int OSSL_FUNC_decoder_get_params(OSSL_PARAM params[]);
/* Functions to construct / destruct / manipulate the decoder context */
void *OSSL_FUNC_decoder_newctx(void *provctx);
void OSSL_FUNC_decoder_freectx(void *ctx);
const OSSL_PARAM *OSSL_FUNC_decoder_settable_ctx_params(void *provctx);
int OSSL_FUNC_decoder_set_ctx_params(void *ctx, const OSSL_PARAM params[]);
/* Functions to check selection support */
int OSSL_FUNC_decoder_does_selection(void *provctx, int selection);
/* Functions to decode object data */
int OSSL_FUNC_decoder_decode(void *ctx, OSSL_CORE_BIO *in,
int selection,
OSSL_CALLBACK *data_cb, void *data_cbarg,
OSSL_PASSPHRASE_CALLBACK *cb, void *cbarg);
/* Functions to export a decoded object */
int OSSL_FUNC_decoder_export_object(void *ctx,
const void *objref, size_t objref_sz,
OSSL_CALLBACK *export_cb,
void *export_cbarg);
π DESCRIPTION π
Okay so when this page says βdecodeβ, it means it in the big umbrella sense, bestie. That includes but is not limited to deserialization, because individual decoders can also do decoding into intermediate data formats. Slay, the word is doing a lot of work here. π
The DECODER operation is a generic method to create a provider-native object reference or intermediate decoded data from an encoded form read from the given OSSL_CORE_BIO. If the caller wants to decode data from memory, it should provide a BIO_s_mem(3) BIO. The decoded data or object reference is passed along with eventual metadata to the metadata_cb as OSSL_PARAM(3) parameters.
The decoder doesnβt need to know more about the OSSL_CORE_BIO pointer than being able to pass it to the appropriate BIO upcalls (see βCore functionsβ in provider-base(7)). Lowkey thatβs the whole assignment. π
The DECODER implementation may be part of a chain, where data is passed from one to the next. For example, there may be an implementation to decode an object from PEM to DER, and another one that decodes DER to a provider-native object. Itβs giving relay race, but make it cryptography. πββοΈβ¨
The last decoding step in the decoding chain is usually supposed to create a provider-native object referenced by an object reference. To import that object into a different provider the OSSL_FUNC_decoder_export_object() can be called as the final step of the decoding process. Iconic final-step behavior, no cap. π
All βfunctionsβ mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH(3) arrays via OSSL_ALGORITHM(3) arrays that are returned by the providerβs provider_query_operation() function (see βProvider Functionsβ in provider-base(7)).
All these βfunctionsβ have a corresponding function type definition named OSSL_FUNC_{name}_fn, and a helper function to retrieve the function pointer from an OSSL_DISPATCH(3) element named OSSL_FUNC_{name}. For example, the βfunctionβ OSSL_FUNC_decoder_decode() has these:
typedef int
(OSSL_FUNC_decoder_decode_fn)(void *ctx, OSSL_CORE_BIO *in,
int selection,
OSSL_CALLBACK *data_cb, void *data_cbarg,
OSSL_PASSPHRASE_CALLBACK *cb, void *cbarg);
static ossl_inline OSSL_FUNC_decoder_decode_fn*
OSSL_FUNC_decoder_decode(const OSSL_DISPATCH *opf);
OSSL_DISPATCH(3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h(7), as follows:
OSSL_FUNC_decoder_get_params OSSL_FUNC_DECODER_GET_PARAMS
OSSL_FUNC_decoder_gettable_params OSSL_FUNC_DECODER_GETTABLE_PARAMS
OSSL_FUNC_decoder_newctx OSSL_FUNC_DECODER_NEWCTX
OSSL_FUNC_decoder_freectx OSSL_FUNC_DECODER_FREECTX
OSSL_FUNC_decoder_set_ctx_params OSSL_FUNC_DECODER_SET_CTX_PARAMS
OSSL_FUNC_decoder_settable_ctx_params OSSL_FUNC_DECODER_SETTABLE_CTX_PARAMS
OSSL_FUNC_decoder_does_selection OSSL_FUNC_DECODER_DOES_SELECTION
OSSL_FUNC_decoder_decode OSSL_FUNC_DECODER_DECODE
OSSL_FUNC_decoder_export_object OSSL_FUNC_DECODER_EXPORT_OBJECT
π Names and properties π
The name of an implementation should match the target type of object it decodes. For example, an implementation that decodes an RSA key should be named "RSA". Likewise, an implementation that decodes DER data from PEM input should be named "DER". Name it after what it actually does, bestie, not after its astrological sign. π
Properties, as defined in the OSSL_ALGORITHM(3) array element of each decoder implementation, can be used to further specify details about an implementation:
inputβ this property is used to specify what format of input the implementation can decode. It is mandatory, okay? Not optional, not βIβll do it later.β π
OpenSSL providers recognize the following input types:
pemβ an implementation with that input type decodes PEM formatted data.derβ an implementation with that input type decodes DER formatted data.msblobβ an implementation with that input type decodes MSBLOB formatted data.pvkβ an implementation with that input type decodes PVK formatted data.
structureβ this property is used to specify the structure that the decoded data is expected to have. This one is optional, so breathe. π«Ά
Structures currently recognised by built-in decoders:
"type-specific"β type specific structure."pkcs8"β structure according to the PKCS#8 specification."SubjectPublicKeyInfo"β encoding of public keys according to the Subject Public Key Info of RFC 5280.
The possible values of both these properties is open ended. A provider may very well specify input types and structures that libcrypto doesnβt know anything about. Itβs giving βnew to me, but valid,β and honestly? Obsessed. β¨
π¦ Subset selections π¦
Sometimes, an object has more than one subset of data that is interesting to treat separately or together. Itβs possible to specify what subsets are to be decoded, with a set of bits selection that are passed in an int.
This set of bits depend entirely on what kind of provider-side object is to be decoded. For example, those bits are assumed to be the same as those used with provider-keymgmt(7) (see βKey Objectsβ in provider-keymgmt(7)) when the object is an asymmetric keypair β e.g., OSSL_KEYMGMT_SELECT_PRIVATE_KEY if the object to be decoded is supposed to contain private key components. Private key components, the main character energy of key material. ππ
OSSL_FUNC_decoder_does_selection() should tell if a particular implementation supports any of the combinations given by selection.
π Context functions π
OSSL_FUNC_decoder_newctx()β returns a context to be used with the rest of the functions. Fresh context, fresh vibes. πOSSL_FUNC_decoder_freectx()β frees the givenctxas created byOSSL_FUNC_decoder_newctx().OSSL_FUNC_decoder_set_ctx_params()β sets context data according to parameters fromparamsthat it recognises. Unrecognised parameters should be ignored. PassingNULLforparamsshould return true. No drama, just ignore the ones you donβt know. πOSSL_FUNC_decoder_settable_ctx_params()β returns a constantOSSL_PARAM(3)array describing the parameters thatOSSL_FUNC_decoder_set_ctx_params()can handle.
See OSSL_PARAM(3) for further details on the parameters structure used by OSSL_FUNC_decoder_set_ctx_params() and OSSL_FUNC_decoder_settable_ctx_params().
π§ Export function π§
When a provider-native object is created by a decoder it would be unsuitable for direct use with a foreign provider. The export function allows for exporting the object into that foreign provider if the foreign provider supports the type of the object and provides an import function. Itβs giving passport control for objects, and honestly? Necessary. πβ¨
OSSL_FUNC_decoder_export_object() should export the object of size objref_sz referenced by objref as an OSSL_PARAM(3) array and pass that into the export_cb as well as the given export_cbarg.
π₯ Decoding functions π₯
OSSL_FUNC_decoder_decode() should decode the data as read from the OSSL_CORE_BIO in to produce decoded data or an object to be passed as reference in an OSSL_PARAM(3) array along with possible other metadata that was decoded from the input. This OSSL_PARAM(3) array is then passed to the data_cb callback. The selection bits, if relevant, should determine what the input data should contain. The decoding functions also take an OSSL_PASSPHRASE_CALLBACK(3) function pointer along with a pointer to application data cbarg, which should be used when a pass phrase prompt is needed. Pass phrase prompt, the group chat notification of cryptography. ππ
Itβs important to understand that the return value from this function is interpreted as follows:
- True (1) β this means βcarry on the decoding processβ, and is meaningful even though this function couldnβt decode the input into anything, because there may be another decoder implementation that can decode it into something.
The data_cb callback should never be called when this function canβt decode the input into anything. Do not call it. Do not pass go. Do not collect $200. π
- False (0) β this means βstop the decoding processβ, and is meaningful when the input could be decoded into some sort of object that this function understands, but further treatment of that object results into errors that wonβt be possible for some other decoder implementation to get a different result.
The conditions to stop the decoding process are at the discretion of the implementation.
π Decoder operation parameters π
There are currently no operation parameters currently recognised by the built-in decoders. Yes, bestie, you read that right: the built-in decoders are chilling with zero operation parameters at the moment. π«Ά
Parameters currently recognised by the built-in pass phrase callback:
"info"(OSSL_PASSPHRASE_PARAM_INFO)<UTF8 string>β a string of information that will become part of the pass phrase prompt. This could be used to give the user information on what kind of object itβs being prompted for.
π RETURN VALUES π
OSSL_FUNC_decoder_newctx()β returns a pointer to a context, orNULLon failure.OSSL_FUNC_decoder_set_ctx_params()β returns1, unless a recognised parameter was invalid or caused an error, for which0is returned.OSSL_FUNC_decoder_settable_ctx_params()β returns a pointer to an array of constantOSSL_PARAM(3)elements.OSSL_FUNC_decoder_does_selection()β returns1if the decoder implementation supports any of theselectionbits, otherwise0.OSSL_FUNC_decoder_decode()β returns1to signal that the decoding process should continue, or0to signal that it should stop.
π SEE ALSO π
β HISTORY β
The DECODER interface was introduced in OpenSSL 3.0.
π COPYRIGHT π
ok so here's the legal bit, bestie β yes we have to do it, and no you can't skip it π
Copyright 2019-2025 The OpenSSL Project Authors. All Rights Reserved.
like, every right. reserved. periodt π
this file is licensed under the Apache License 2.0 (the "License"). and fr fr, you may not use this file except in compliance with the License β that's not a cute suggestion, that's the actual rule π
you can get yourself a copy of the License in the file LICENSE in the source distribution, or at <https://www.openssl.org/source/license.html> β go grab it, it's right there π«Ά
and that's the whole page, bestie!! π this was PROVIDER-DECODER(7ossl) from OpenSSL 3.5.9, dated 2026-09-29 β iconic, no notes β¨ go forth and decode something π
π₯
π¦ 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