PROVIDER-CIPHER(7ossl)

πŸ“¦ version 3.5.0, in opensuse-leap 16.0

πŸ’… provider-cipher β€” the cipher library <-> provider functions (OpenSSL 7ossl, bestie!)

okay so this is page one of the OpenSSL 7ossl manual, and it's literally the glue page β€” the whole provider-cipher situation, i.e. The cipher library <-> provider functions. if you're writing a provider (or just nosy about how ciphers get dispatched πŸ‘€), this is your vibe. no cap. πŸŽ€


✨ NAME ✨

provider-cipher β€” literally just: The cipher library <-> provider functions. that's the whole name section, she's short and iconic πŸ’…


🌸 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.
 */
🫢 real talk before you panic: none of these are actual functions. they're displayed like this so you can see the function signatures for the functions that get offered as function pointers inside OSSL_DISPATCH arrays. so when you see them, think "shape of the callback," not "go call this." ✨

🧚 context management

/* Context management */
void *OSSL_FUNC_cipher_newctx(void *provctx);
void OSSL_FUNC_cipher_freectx(void *cctx);
void *OSSL_FUNC_cipher_dupctx(void *cctx);

like, new / free / duplicate your context. the holy trinity of not leaking, bestie πŸ’€

πŸ”₯ encryption / decryption

/* Encryption/decryption */
int OSSL_FUNC_cipher_encrypt_init(void *cctx, const unsigned char *key,
                                  size_t keylen, const unsigned char *iv,
                                  size_t ivlen, const OSSL_PARAM params[]);
int OSSL_FUNC_cipher_decrypt_init(void *cctx, const unsigned char *key,
                                  size_t keylen, const unsigned char *iv,
                                  size_t ivlen, const OSSL_PARAM params[]);
int OSSL_FUNC_cipher_encrypt_skey_init(void *cctx, void *skeydata,
                                       const unsigned char *iv, size_t ivlen,
                                       const OSSL_PARAM params[]);
int OSSL_FUNC_cipher_encrypt_skey_init(void *cctx, void *skeydata,
                                       const unsigned char *iv, size_t ivlen,
                                       const OSSL_PARAM params[]);
int OSSL_FUNC_cipher_update(void *cctx, unsigned char *out, size_t *outl,
                            size_t outsize, const unsigned char *in, size_t inl);
int OSSL_FUNC_cipher_final(void *cctx, unsigned char *out, size_t *outl,
                           size_t outsize);
int OSSL_FUNC_cipher_cipher(void *cctx, unsigned char *out, size_t *outl,
                            size_t outsize, const unsigned char *in, size_t inl);

and yes β€” OSSL_FUNC_cipher_encrypt_skey_init is in there twice, exactly like the original. not me fixing it, not me merging it, not me saying a word πŸ™ˆ we reproduce, we don't editorialize, periodt.

πŸ¦‹ encryption / decryption using cipher pipeline

/* Encryption/decryption using cipher pipeline */
int OSSL_FUNC_cipher_pipeline_encrypt_init(void *cctx, const unsigned char *key,
                                           size_t keylen, size_t numpipes,
                                           const unsigned char **iv, size_t ivlen,
                                           const OSSL_PARAM params[]))
int OSSL_FUNC_cipher_pipeline_decrypt_init(void *cctx, const unsigned char *key,
                                           size_t keylen, size_t numpipes,
                                           const unsigned char **iv, size_t ivlen,
                                           const OSSL_PARAM params[]))
int OSSL_FUNC_cipher_pipeline_update(void *cctx, size_t numpipes,
                                     unsigned char **out, size_t *outl,
                                     const size_t *outsize,
                                     const unsigned char **in, const size_t *inl))
int OSSL_FUNC_cipher_pipeline_final(void *cctx, size_t numpipes,
                                    unsigned char **out, size_t *outl,
                                    const size_t *outsize))

pipeline era πŸ’ β€” note the extra ) chillin' at the end of those lines. we keep them exactly as they came, character for character. iykyk 🌈

πŸ’œ cipher parameter descriptors

/* Cipher parameter descriptors */
const OSSL_PARAM *OSSL_FUNC_cipher_gettable_params(void *provctx);

πŸ’– cipher operation parameter descriptors

/* Cipher operation parameter descriptors */
const OSSL_PARAM *OSSL_FUNC_cipher_gettable_ctx_params(void *cctx,
                                                       void *provctx);
const OSSL_PARAM *OSSL_FUNC_cipher_settable_ctx_params(void *cctx,
                                                       void *provctx);

⭐ cipher parameters

/* Cipher parameters */
int OSSL_FUNC_cipher_get_params(OSSL_PARAM params[]);

πŸ“ cipher operation parameters

/* Cipher operation parameters */
int OSSL_FUNC_cipher_get_ctx_params(void *cctx, OSSL_PARAM params[]);
int OSSL_FUNC_cipher_set_ctx_params(void *cctx, const OSSL_PARAM params[]);

that's the synopsis, and it ate πŸ”₯ β€” more coming in the next part, don't go anywhere bestie 🫢

✨ DESCRIPTION ✨

Okay bestie, listen β€” this page is primarily aimed at provider authors. If that's not you, go peek at provider(7) first, it's got the further information you need. 🫢

The CIPHER operation is what lets providers implement cipher algorithms and hand them over to applications through the API functions EVP_EncryptInit_ex(3), EVP_EncryptUpdate(3) and EVP_EncryptFinal(3) β€” plus the decrypt equivalents and all the other related functions, obviously. πŸ’…

Every "function" we talk about here gets passed as a function pointer between libcrypto and the provider inside OSSL_DISPATCH(3) arrays, which travel via OSSL_ALGORITHM(3) arrays, which get returned by the provider's provider_query_operation() function. (More on that in "Provider Functions" in provider-base(7).) It's giving very chain-of-custody, honestly.

And each one of these "functions" has a matching function type definition named OSSL_FUNC_{name}_fn, plus a lil helper function to pull the function pointer out of an OSSL_DISPATCH(3) element named OSSL_FUNC_{name}. So for example, the "function" OSSL_FUNC_cipher_newctx() comes with these besties:

typedef void *(OSSL_FUNC_cipher_newctx_fn)(void *provctx);
static ossl_inline OSSL_FUNC_cipher_newctx_fn
    OSSL_FUNC_cipher_newctx(const OSSL_DISPATCH *opf);

OSSL_DISPATCH(3) arrays are indexed by numbers that are provided as macros in openssl-core_dispatch.h(7), like so:

OSSL_FUNC_cipher_newctx                    OSSL_FUNC_CIPHER_NEWCTX
OSSL_FUNC_cipher_freectx                   OSSL_FUNC_CIPHER_FREECTX
OSSL_FUNC_cipher_dupctx                    OSSL_FUNC_CIPHER_DUPCTX

OSSL_FUNC_cipher_encrypt_init              OSSL_FUNC_CIPHER_ENCRYPT_INIT
OSSL_FUNC_cipher_decrypt_init              OSSL_FUNC_CIPHER_DECRYPT_INIT
OSSL_FUNC_cipher_encrypt_skey_init         OSSL_FUNC_CIPHER_ENCRYPT_SKEY_INIT
OSSL_FUNC_cipher_decrypt_skey_init         OSSL_FUNC_CIPHER_DECRYPT_SKEY_INIT
OSSL_FUNC_cipher_update                    OSSL_FUNC_CIPHER_UPDATE
OSSL_FUNC_cipher_final                     OSSL_FUNC_CIPHER_FINAL
OSSL_FUNC_cipher_cipher                    OSSL_FUNC_CIPHER_CIPHER

OSSL_FUNC_cipher_pipeline_encrypt_init     OSSL_FUNC_CIPHER_PIPELINE_ENCRYPT_INIT
OSSL_FUNC_cipher_pipeline_decrypt_init     OSSL_FUNC_CIPHER_PIPELINE_DECRYPT_INIT
OSSL_FUNC_cipher_pipeline_update           OSSL_FUNC_CIPHER_PIPELINE_UPDATE
OSSL_FUNC_cipher_pipeline_final            OSSL_FUNC_CIPHER_PIPELINE_FINAL

OSSL_FUNC_cipher_get_params                OSSL_FUNC_CIPHER_GET_PARAMS
OSSL_FUNC_cipher_get_ctx_params            OSSL_FUNC_CIPHER_GET_CTX_PARAMS
OSSL_FUNC_cipher_set_ctx_params            OSSL_FUNC_CIPHER_SET_CTX_PARAMS

OSSL_FUNC_cipher_gettable_params           OSSL_FUNC_CIPHER_GETTABLE_PARAMS
OSSL_FUNC_cipher_gettable_ctx_params       OSSL_FUNC_CIPHER_GETTABLE_CTX_PARAMS
OSSL_FUNC_cipher_settable_ctx_params       OSSL_FUNC_CIPHER_SETTABLE_CTX_PARAMS

Now β€” plot twist β€” a cipher algorithm implementation doesn't have to implement all of these. To count as a consistent set, you need at least a complete set of "encrypt" functions, or a complete set of "decrypt" functions, or a single "cipher" function. Same energy for pipelines: a complete set of pipeline "encrypt" functions and/or a complete set of pipeline "decrypt" functions. But in all cases, both OSSL_FUNC_cipher_newctx and OSSL_FUNC_cipher_freectx have to be there. Everything else? Optional, babe. 🌸


🧸 Context Management Functions

OSSL_FUNC_cipher_newctx() should create and return a pointer to a provider side structure that holds context information during a cipher operation. That pointer gets passed back in a bunch of the other cipher operation function calls. The provctx parameter is the provider context that was generated during provider initialisation (see provider(7)). ✨

OSSL_FUNC_cipher_freectx() gets handed a pointer to the provider side cipher context in the cctx parameter, and it should free any resources associated with that context. Clean up your room, bestie. 🧹

OSSL_FUNC_cipher_dupctx() should duplicate the provider side cipher context in the cctx parameter and return the duplicate copy. Twin energy. πŸ‘―


πŸ” Encryption/Decryption Functions

OSSL_FUNC_cipher_encrypt_init() initialises a cipher operation for encryption, given a newly created provider side cipher context in the cctx parameter. The key to use is given in key, which is keylen bytes long. The IV to use is given in iv, which is ivlen bytes long. And params, if it's not NULL, should be set on the context in a manner similar to using OSSL_FUNC_cipher_set_ctx_params(). πŸ”₯

OSSL_FUNC_cipher_decrypt_init() is the same as OSSL_FUNC_cipher_encrypt_init() except β€” wait for it β€” it initialises the context for a decryption operation. 😱

OSSL_FUNC_cipher_encrypt_skey_init() and OSSL_FUNC_cipher_decrypt_skey_init() are variants of OSSL_FUNC_cipher_encrypt_init() and OSSL_FUNC_cipher_decrypt_init() for working with opaque objects that contain provider-specific key handles instead of raw bytes. Very mysterious, very chic. πŸ•ΆοΈ

OSSL_FUNC_cipher_update() gets called to supply data to be encrypted/decrypted as part of a cipher operation that was previously initialised. The cctx parameter holds a pointer to a previously initialised provider side context. OSSL_FUNC_cipher_update() should encrypt/decrypt inl bytes of data at the location pointed to by in. The encrypted data should be stored in out, and the amount of data written goes to *outl, which should not exceed outsize bytes. This one may be called multiple times for a single cipher operation. πŸ‘‘

And here's the part where the implementation has to actually try: it's the responsibility of the cipher implementation to handle input lengths that aren't multiples of the block length. In those cases, a cipher implementation will typically cache partial blocks of input data until a complete block is obtained. The pointers out and in may point to the same location β€” in which case the encryption must be done in-place. If out and in point to different locations, the requirements of EVP_EncryptUpdate(3) and EVP_DecryptUpdate(3) guarantee that the two buffers are disjoint. Similarly, the requirements of EVP_EncryptUpdate(3) and EVP_DecryptUpdate(3) ensure that the buffer pointed to by out contains sufficient room for the operation being performed. So like, don't stress about it β€” the contract has your back. 🫢

OSSL_FUNC_cipher_final() completes an encryption or decryption that was started through previous OSSL_FUNC_cipher_encrypt_init() or OSSL_FUNC_cipher_decrypt_init(), and OSSL_FUNC_cipher_update() calls. The cctx parameter holds a pointer to the provider side context. Any final encryption/decryption output should be written to out, and the amount of data written goes to *outl, which should not exceed outsize bytes. The same expectations apply to outsize as documented for EVP_EncryptFinal(3) and EVP_DecryptFinal(3). 🎬

OSSL_FUNC_cipher_cipher() performs encryption/decryption using the provider side cipher context in the cctx parameter, which should have been previously initialised via a call to OSSL_FUNC_cipher_encrypt_init() or OSSL_FUNC_cipher_decrypt_init(). This should call the raw underlying cipher function with no padding whatsoever. It gets invoked in the provider as a result of the application calling EVP_Cipher(3). And heads up: the application is responsible for making sure the input is a multiple of the block length β€” not you. The data to be encrypted/decrypted will be in in, and it'll be inl bytes in length. The output from the encryption/decryption should be stored in out, and the amount of data stored should be put in *outl, which should be no more than outsize bytes. πŸ’€

OSSL_FUNC_cipher_pipeline_encrypt_init(), OSSL_FUNC_cipher_pipeline_decrypt_init(), OSSL_FUNC_cipher_pipeline_update(), and OSSL_FUNC_cipher_pipeline_final() are similar to the non-pipeline variants, but they're used when the application is using cipher pipelining. The numpipes parameter is the number of pipes in the pipeline. The iv parameter is an array of buffers with IVs, each ivlen bytes long. The in and out are arrays of buffer pointers. The inl and outl, outsize are arrays of size_t representing corresponding buffer length as similar to the non-pipeline variants. All arrays are of length numpipes. See EVP_CipherPipelineEncryptInit(3) for more information. 🚰


πŸŽ€ Cipher Parameters

See OSSL_PARAM(3) for further details on the parameters structure these functions use. πŸ“‹

OSSL_FUNC_cipher_get_params() gets details of the algorithm implementation and stores them in params.

OSSL_FUNC_cipher_set_ctx_params() sets cipher operation parameters for the provider side cipher context cctx to params. Any parameter settings are additional to any that were previously set. Passing NULL for params should return true.

OSSL_FUNC_cipher_get_ctx_params() gets cipher operation details details from the given provider side cipher context cctx and stores them in params. (Yes, "details details" β€” that's literally what it says, I'm not fixing it, it's iconic.) Passing NULL for params should return true.

OSSL_FUNC_cipher_gettable_params(), OSSL_FUNC_cipher_gettable_ctx_params(), and OSSL_FUNC_cipher_settable_ctx_params() all return constant OSSL_PARAM(3) arrays as descriptors of the parameters that OSSL_FUNC_cipher_get_params(), OSSL_FUNC_cipher_get_ctx_params(), and OSSL_FUNC_cipher_set_ctx_params() can handle, respectively. OSSL_FUNC_cipher_gettable_ctx_params() and OSSL_FUNC_cipher_settable_ctx_params() will return the parameters associated with the provider side context cctx in its current state if it's not NULL. Otherwise, they return the parameters associated with the provider side algorithm provctx. ✨

Parameters currently recognised by built-in ciphers are listed in "PARAMETERS" in EVP_EncryptInit(3). Not all parameters are relevant to, or are understood by all ciphers β€” so don't assume, check first. πŸ¦‹


πŸ’– RETURN VALUES πŸ’–

OSSL_FUNC_cipher_newctx() and OSSL_FUNC_cipher_dupctx() should return the newly created provider side cipher context, or NULL on failure. 😭

OSSL_FUNC_cipher_encrypt_init(), OSSL_FUNC_cipher_decrypt_init(), OSSL_FUNC_cipher_update(), OSSL_FUNC_cipher_final(), OSSL_FUNC_cipher_cipher(), OSSL_FUNC_cipher_encrypt_skey_init(), OSSL_FUNC_cipher_decrypt_skey_init(), OSSL_FUNC_cipher_pipeline_encrypt_init(), OSSL_FUNC_cipher_pipeline_decrypt_init(), OSSL_FUNC_cipher_pipeline_update(), OSSL_FUNC_cipher_pipeline_final(), OSSL_FUNC_cipher_get_params(), OSSL_FUNC_cipher_get_ctx_params() and OSSL_FUNC_cipher_set_ctx_params() should return 1 for success or 0 on error. Simple as that. βœ…

OSSL_FUNC_cipher_gettable_params(), OSSL_FUNC_cipher_gettable_ctx_params() and OSSL_FUNC_cipher_settable_ctx_params() should return a constant OSSL_PARAM(3) array, or NULL if none is offered. 🌈


🌟 SEE ALSO 🌟

provider(7), OSSL_PROVIDER-FIPS(7), OSSL_PROVIDER-default(7), OSSL_PROVIDER-legacy(7), EVP_CIPHER-AES(7), EVP_CIPHER-ARIA(7), EVP_CIPHER-BLOWFISH(7), EVP_CIPHER-CAMELLIA(7), EVP_CIPHER-CAST(7), EVP_CIPHER-CHACHA(7), EVP_CIPHER-DES(7), EVP_CIPHER-IDEA(7), EVP_CIPHER-RC2(7), EVP_CIPHER-RC4(7), EVP_CIPHER-RC5(7), EVP_CIPHER-SEED(7), EVP_CIPHER-SM4(7), EVP_CIPHER-NULL(7), life_cycle-cipher(7), EVP_EncryptInit(3)

🌈 HISTORY 🌈

Okay so bestie, story time πŸ“– β€” the provider CIPHER interface? Literally a 3.0 baby. It was introduced in OpenSSL 3.0, no cap πŸ’….

And then the glow-up era hit: OSSL_FUNC_cipher_encrypt_skey_init() and OSSL_FUNC_cipher_decrypt_skey_init() were introduced in OpenSSL 3.5. Those two are the new kids and honestly? They ate 🫢.


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. Like, respectfully, the License is the vibe check here πŸ™ˆ β€” you can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

Fr fr, read the License before you do anything. "Not in compliance" is not the aesthetic we're going for πŸ’€βœ¨

And that's the whole page, bestie β€” you're officially a cipher provider connoisseur now πŸ‘‘πŸ§šπŸ’œ This one's from the OpenSSL 3.5.0 source, dated 2026-09-25 β€” so go forth and slay your PROVIDER-CIPHER(7ossl) knowledge, periodt πŸ’…πŸŒΈ

πŸ“¦ where this page comes from