EVP_KDF(3ssl)

📦 version 4.1.0, in nixos 26.05, nixpkgs unstable

💖 EVP_KDF(3ssl) — the KDF glow-up 💖

okay bestie, so this is the EVP_KDF(3ssl) page from OpenSSL (section 3ssl, aka the library-functions shelf). It's the whole high-level Key Derivation Function interface and honestly it's giving main character energy for the entire crypto library. Buckle up. 🎀

🌸 NAME 🌸

The full squad, in order, no cap — EVP_KDF, EVP_KDF_fetch, EVP_KDF_free, EVP_KDF_up_ref, EVP_KDF_CTX, EVP_KDF_CTX_new, EVP_KDF_CTX_free, EVP_KDF_CTX_dup, EVP_KDF_CTX_reset, EVP_KDF_derive, EVP_KDF_CTX_set_SKEY, EVP_KDF_derive_SKEY, EVP_KDF_CTX_get_kdf_size, EVP_KDF_CTX_get0_kdf, EVP_KDF_CTX_get1_kdf, EVP_KDF_get0_provider, EVP_KDF_CTX_kdf, EVP_KDF_is_a, EVP_KDF_get0_name, EVP_KDF_names_do_all, EVP_KDF_get0_description, EVP_KDF_CTX_get_params, EVP_KDF_CTX_set_params, EVP_KDF_do_all_provided, EVP_KDF_get_params, EVP_KDF_gettable_params, EVP_KDF_gettable_ctx_params, EVP_KDF_settable_ctx_params, EVP_KDF_CTX_gettable_params, EVP_KDF_CTX_settable_params — EVP KDF routines. 💅

✨ SYNOPSIS ✨

Like, here's the literal spellbook, copied exactly because we do not paraphrase signatures in this house:

#include <openssl/kdf.h>

typedef struct evp_kdf_st EVP_KDF;
typedef struct evp_kdf_ctx_st EVP_KDF_CTX;

EVP_KDF_CTX *EVP_KDF_CTX_new(EVP_KDF *kdf);
const EVP_KDF *EVP_KDF_CTX_get0_kdf(const EVP_KDF_CTX *ctx);
EVP_KDF *EVP_KDF_CTX_get1_kdf(EVP_KDF_CTX *ctx);
void EVP_KDF_CTX_free(EVP_KDF_CTX *ctx);
EVP_KDF_CTX *EVP_KDF_CTX_dup(const EVP_KDF_CTX *src);
void EVP_KDF_CTX_reset(EVP_KDF_CTX *ctx);
size_t EVP_KDF_CTX_get_kdf_size(EVP_KDF_CTX *ctx);
int EVP_KDF_derive(EVP_KDF_CTX *ctx, unsigned char *key, size_t keylen,
                   const OSSL_PARAM params[]);
int EVP_KDF_CTX_set_SKEY(EVP_KDF_CTX *ctx, EVP_SKEY *key, const char *paramname);
EVP_SKEY *EVP_KDF_derive_SKEY(EVP_KDF_CTX *ctx, EVP_SKEYMGMT *mgmt,
                              const char *key_type, const char *propquery,
                              size_t keylen, const OSSL_PARAM params[]);
int EVP_KDF_up_ref(EVP_KDF *kdf);
void EVP_KDF_free(EVP_KDF *kdf);
EVP_KDF *EVP_KDF_fetch(OSSL_LIB_CTX *libctx, const char *algorithm,
                       const char *properties);
int EVP_KDF_is_a(const EVP_KDF *kdf, const char *name);
const char *EVP_KDF_get0_name(const EVP_KDF *kdf);
const char *EVP_KDF_get0_description(const EVP_KDF *kdf);
const OSSL_PROVIDER *EVP_KDF_get0_provider(const EVP_KDF *kdf);
void EVP_KDF_do_all_provided(OSSL_LIB_CTX *libctx,
                             void (*fn)(EVP_KDF *kdf, void *arg),
                             void *arg);
int EVP_KDF_names_do_all(const EVP_KDF *kdf,
                         void (*fn)(const char *name, void *data),
                         void *data);
int EVP_KDF_get_params(EVP_KDF *kdf, OSSL_PARAM params[]);
int EVP_KDF_CTX_get_params(EVP_KDF_CTX *ctx, OSSL_PARAM params[]);
int EVP_KDF_CTX_set_params(EVP_KDF_CTX *ctx, const OSSL_PARAM params[]);
const OSSL_PARAM *EVP_KDF_gettable_params(const EVP_KDF *kdf);
const OSSL_PARAM *EVP_KDF_gettable_ctx_params(const EVP_KDF *kdf);
const OSSL_PARAM *EVP_KDF_settable_ctx_params(const EVP_KDF *kdf);
const OSSL_PARAM *EVP_KDF_CTX_gettable_params(const EVP_KDF *kdf);
const OSSL_PARAM *EVP_KDF_CTX_settable_params(const EVP_KDF *kdf);
const OSSL_PROVIDER *EVP_KDF_get0_provider(const EVP_KDF *kdf);

(yes, EVP_KDF_get0_provider really does show up twice up there — that's just how the page is, iykyk 🙈)

⚠️ Deprecated alert, since OpenSSL 4.1 — the following function can be hidden entirely by defining OPENSSL_API_COMPAT with a suitable version value, see openssl_user_macros(7):

const EVP_KDF *EVP_KDF_CTX_kdf(const EVP_KDF_CTX *ctx);

💫 DESCRIPTION 💫

The EVP KDF routines are the ✨high-level✨ interface to Key Derivation Function algorithms, and bestie, you should be using these instead of the algorithm-specific functions. No exceptions, periodt.

So the flow is: you spin up an EVP_KDF_CTX for whatever algorithm you need using EVP_KDF_CTX_new(), then you feed the algorithm its inputs either by passing them along as part of the EVP_KDF_derive() or EVP_KDF_derive_SKEY() call, or by calling EVP_KDF_CTX_set_params() or EVP_KDF_CTX_set_SKEY() before you call EVP_KDF_derive() or EVP_KDF_derive_SKEY() to actually derive the key. Two paths, same destination. 🦋

🧚 Types

EVP_KDF — the type that holds the implementation of a KDF.
EVP_KDF_CTX — a context type that holds the algorithm inputs.

🔍 Algorithm implementation fetching

EVP_KDF_fetch() — fetches an implementation of a KDF algorithm, given a library context libctx and a set of properties. For the full lore on how fetching works, see "ALGORITHM FETCHING" in crypto(7).
Curious which algorithms the default provider ships with? See "Key Derivation Function (KDF)" in OSSL_PROVIDER-default(7) for the lists.
The returned value must eventually be freed with EVP_KDF_free(3) — don't just leave it out there, that's rude.
EVP_KDF_up_ref() — increments the reference count of an already fetched KDF.
EVP_KDF_free() — frees a fetched algorithm. NULL is a valid parameter, and for that it's a straight-up no-op. 🫶

🎀 Context manipulation functions

EVP_KDF_CTX_new() — creates a new context for the KDF implementation kdf.
EVP_KDF_CTX_free() — frees up the context ctx. If ctx is NULL, nothing happens. Chill.
EVP_KDF_CTX_get0_kdf() — returns the EVP_KDF associated with the context ctx. And EVP_KDF_CTX_get1_kdf() is the same thing, except ownership is passed to the caller. Also EVP_KDF_CTX_kdf() is an alias for EVP_KDF_CTX_get0_kdf() (but remember that deprecation note above 👀).

🧮 Computing functions

EVP_KDF_CTX_reset() — resets the context back to its default state, exactly as if the context had just been created. Fresh start, clean slate, new era. ✨
EVP_KDF_derive() — processes any parameters in Params, then derives keylen bytes of key material and drops it in the key buffer. 🫳 Heads up though: if the algorithm produces a fixed amount of output, an error will occur unless the keylen parameter is equal to that output size, as returned by EVP_KDF_CTX_get_kdf_size().
EVP_KDF_derive_SKEY() — behaves similarly, except it returns an EVP_SKEY object. If the skeymgmt argument is explicitly passed, it will be used for the generated key. If the skeymgmt argument is NULL, then key_type and propquery get used for fetching the EVP_SKEYMGMT object linked to the key. And if the KDF doesn't support dealing with opaque keys, or the passed EVP_SKEYMGMT is from a different provider than the KDF method, then the operation will try to perform export/import through the raw format. Adaptable queen. 💅
EVP_KDF_CTX_set_SKEY() — lets you set an skey object as the input parameter for the derivation functions. Since different KDFs may accept several parameters as key names, you can specify the particular parameter name you're setting. If null is passed, then the parameter OSSL_KDF_PARAM_KEY is implied. Basically this is the move when the input key is represented by EVP_SKEY rather than raw bytes.
EVP_KDF_get_params() — retrieves details about the implementation kdf. The set of parameters given with params determines exactly what gets retrieved. And note: a parameter that's unknown in the underlying context is simply ignored. 🫥
EVP_KDF_CTX_get_params() — retrieves chosen parameters, given the context ctx and its underlying context. Again, the set of parameters given with params determines exactly what will be retrieved, and a parameter that's unknown in the underlying context is simply ignored.
EVP_KDF_CTX_set_params() — passes chosen parameters down to the underlying context, given a context ctx. The set of parameters given with params determines exactly what gets passed down. Same story: a parameter unknown in the underlying context is simply ignored. And also — what happens when a needed parameter isn't passed down is entirely defined by the implementation. So that part's on them, not on you.
EVP_KDF_gettable_params() — returns an OSSL_PARAM(3) array describing the retrievable and settable parameters. This one returns parameters that can be used with EVP_KDF_get_params().
EVP_KDF_gettable_ctx_params() and EVP_KDF_CTX_gettable_params() — return constant OSSL_PARAM(3) arrays describing the retrievable parameters that can be used with EVP_KDF_CTX_get_params(). The diff: EVP_KDF_gettable_ctx_params() returns the parameters that can be retrieved from the algorithm, whereas EVP_KDF_CTX_gettable_params() returns the parameters that can be retrieved in the context's current state. Iconic and situational.
EVP_KDF_settable_ctx_params() and EVP_KDF_CTX_settable_params() — return constant OSSL_PARAM(3) arrays describing the settable parameters that can be used with EVP_KDF_CTX_set_params(). Same split as above: EVP_KDF_settable_ctx_params() returns the parameters that can be retrieved from the algorithm, whereas EVP_KDF_CTX_settable_params() returns the parameters that can be retrieved in the context's current state.

👑 Information functions

EVP_KDF_CTX_get_kdf_size() — returns the output size if the algorithm produces a fixed amount of output, and SIZE_MAX otherwise. If an error occurs, then 0 is returned. Careful though: for some algorithms an error may result if input parameters necessary to calculate a fixed output size have not yet been supplied. So feed it first, then ask. 🍓
EVP_KDF_is_a() — returns 1 if kdf is an implementation of an algorithm that's identifiable with name, otherwise 0.
EVP_KDF_get0_provider() — returns the provider that holds the implementation of the given kdf.
EVP_KDF_do_all_provided() — traverses all KDF implemented by all activated providers in the given library context libctx, and for each of the implementations, calls the given function fn with the implementation method and the given arg as argument. Tour de force. 🌈
EVP_KDF_get0_name() — returns the name of the given KDF. For fetched KDFs with multiple names, only one of them is returned, so it's recommended to use EVP_KDF_names_do_all() instead.
EVP_KDF_names_do_all() — traverses all names for kdf, and calls fn with each name and data.
EVP_KDF_get0_description() — returns a description of the kdf, meant for display and human consumption. The description is at the discretion of the kdf implementation, so like, whatever they feel like writing.

…and that's literally only half the lore, bestie. 🫶💜

✨ PARAMETERS ✨

Okay bestie, this is the part where you tell the KDF what to actually do. These are the standard parameter names — the string is the name you pass, and the thing in parens is the constant in the headers. Iykyk. 💅

"pass" (OSSL_KDF_PARAM_PASSWORD) <octet string> — some KDF implementations literally require a password, no cap. For the ones that support this parameter, this sets the password. 🍓
"salt" (OSSL_KDF_PARAM_SALT) <octet string> — some KDF implementations can take a non-secret unique cryptographic salt. For the implementations that support it, this parameter sets that salt. The default value, if any, is implementation dependent — so like, don't assume, check your provider. 🙈
"iter" (OSSL_KDF_PARAM_ITER) <unsigned integer> — some KDF implementations require an iteration count. For the ones that support it, this sets the iteration count. The default value, if any, is implementation dependent.
"properties" (OSSL_KDF_PARAM_PROPERTIES) <UTF8 string>
"mac" (OSSL_KDF_PARAM_MAC) <UTF8 string>
"digest" (OSSL_KDF_PARAM_DIGEST) <UTF8 string>
"cipher" (OSSL_KDF_PARAM_CIPHER) <UTF8 string>

For KDF implementations that use an underlying computation MAC, digest or cipher, these parameters set what the algorithm should be. The value is always the name of the intended algorithm, or the properties. ⭐

Heads up: not all algorithms may support all possible underlying implementations. So yeah, vibe check your combo before you commit. 💀

"key" (OSSL_KDF_PARAM_KEY) <octet string> — some KDF implementations require a key. For those that support it, this octet string parameter sets the key. 🔑
"info" (OSSL_KDF_PARAM_INFO) <octet string> — some KDF implementations, such as EVP_KDF-HKDF(7), take an 'info' parameter for binding the derived key material to application- and context-specific information. This parameter sets the info, fixed info, other info or shared info argument. And the slay part: you can specify this parameter multiple times, and each instance will be concatenated to form the final value. 🫶
"maclen" (OSSL_KDF_PARAM_MAC_SIZE) <unsigned integer> — used by implementations that use a MAC with a variable output size (KMAC). For the implementations that support it, this parameter sets the MAC output size. The default value, if any, is implementation dependent. The length must never exceed what can be given with a size_t — that's a hard line, bestie, don't test it. 😭
"maxmem_bytes" (OSSL_KDF_PARAM_SCRYPT_MAXMEM) <unsigned integer> — memory-hard password-based KDF algorithms, such as scrypt, use an amount of memory that depends on the load factors provided as input. For the implementations that support it, this uint64_t parameter sets an upper limit on the amount of memory that may be consumed while performing a key derivation. If this memory usage limit is exceeded because the load factors are chosen too high, the key derivation will fail. 🧚

The default value is implementation dependent. The memory size must never exceed what can be given with a size_t.

💖 RETURN VALUES 💖

Not me listing every single one because you deserve the full picture, bestie. 👑

EVP_KDF_fetch() — returns a pointer to a newly fetched EVP_KDF, or NULL if allocation failed.
EVP_KDF_get0_provider() — returns a pointer to the provider for the KDF, or NULL on error.
EVP_KDF_up_ref() — returns 1 on success, 0 on error.
EVP_KDF_CTX_new() — returns either the newly allocated EVP_KDF_CTX structure or NULL if an error occurred.
EVP_KDF_CTX_free() and EVP_KDF_CTX_reset() — do not return a value. They just do, no notes. 💅
EVP_KDF_CTX_get_kdf_size() — returns the output size. SIZE_MAX is returned to indicate that the algorithm produces a variable amount of output; 0 to indicate failure. Two special cases, so read carefully, fr fr.
EVP_KDF_get0_name() — returns the name of the KDF, or NULL on error.
EVP_KDF_names_do_all() — returns 1 if the callback was called for all names. A return value of 0 means that the callback was not called for any names.
EVP_KDF_derive_SKEY() — returns the EVP_SKEY object on success or NULL on failure.
The remaining functions — return 1 for success and 0 for failure. Classic. 🎀

🌸 NOTES 🌸

The KDF life-cycle is described in life_cycle-kdf(7). In the future, the transitions described there will be enforced. When that happens, it will not be considered a breaking change to the API — so like, be aware, this is giving "future you will thank present you" energy. ✨

🦋 SEE ALSO 🦋

"Key Derivation Function (KDF)" in OSSL_PROVIDER-default(7)
life_cycle-kdf(7)

🌈 HISTORY 🌈

This functionality was added in OpenSSL 3.0. 🎀
EVP_KDF_derive_SKEY() and EVP_KDF_CTX_set_SKEY() functions were introduced in OpenSSL 3.6.
EVP_KDF_CTX_get0_kdf() and EVP_KDF_CTX_get1_kdf() functions were introduced in OpenSSL 4.1.
EVP_KDF_CTX_kdf() function was deprecated in favour of EVP_KDF_CTX_get0_kdf() in OpenSSL 4.1. She's retired, wish her well. 💜

👑 COPYRIGHT 👑

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

And that's the whole page, bestie — you ate that. 🫶 This one came from OpenSSL 4.1.0, dated 2026-10-23, page EVP_KDF(3ssl). Go derive some keys, icon. 💅✨

📦 where this page comes from

nixos 26.05: openssl 4.1.0
nixpkgs unstable: openssl 4.1.0
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on 2026-11-04: a language model's rewrite of the original, under its terms