OSSL_ALGORITHM(3SSL)

πŸ’– OSSL_ALGORITHM πŸ’–

okay bestie, gather round, because we're talking about OSSL_ALGORITHM, from the 3SSL manual suite β€” it's the OpenSSL core type that defines a fetchable algorithm. yes, it's giving very much "behind the scenes but make it iconic" πŸ’…

✨ SYNOPSIS ✨

#include <openssl/core.h>

typedef struct ossl_algorithm_st OSSL_ALGORITHM;
struct ossl_algorithm_st {
    const char *algorithm_names;     /* key */
    const char *property_definition; /* key */
    const OSSL_DISPATCH *implementation;
    const char *algorithm_description;
};

🌸 DESCRIPTION 🌸

OSSL_ALGORITHM is a public structure and its whole job is describing an algorithm that a provider(7) provides. Like, that's the assignment. Arrays of this type get handed back by providers, on demand, when the OpenSSL libraries come asking β€” basically the provider is like "here's what algorithms I implement and here's their properties, hope that helps 🫢".

🚨 IMPORTANT, no cap: arrays of this type must be terminated with a tuple where algorithm_names is NULL. Do not forget the NULL terminator. She is load-bearing.

This kind of array is typically returned by the provider's operation querying function β€” that's described further under "Provider Functions" in provider-base(7).


πŸŽ€ OSSL_ALGORITHM fields πŸŽ€

  • algorithm_names β€” this string is a colon separated set of names / identities, and the appropriate fetching functionality (like EVP_CIPHER_fetch(3), EVP_MD_fetch(3), etc) uses it to find the algorithm you're looking for. πŸ”

Having multiple names / identities means one specific algorithm implementation can be fetched multiple ways. Case in point: the RSA algorithm has these known identities:

  • "RSA"
  • "rsaEncryption" β€” this is the name of the algorithm's OBJECT IDENTIFIER (OID), as given by the PKCS#1 RFC's ASN.1 module <https://www.rfc-editor.org/rfc/rfc8017#appendix-C>
  • 1.2.840.113549.1.1.1 β€” this is the OID itself for "rsaEncryption", in canonical decimal text form.

So the resulting algorithm_names string would look like this:

"RSA:rsaEncryption:1.2.840.113549.1.1.1"

The OpenSSL libraries take the first of the algorithm names as the main or canonical name, on a per algorithm implementation basis. πŸ‘‘

Peep the notes down in "On the subject of algorithm names" for a deeper discussion on algorithm_names and how it may interact with applications and libraries, OpenSSL's included.

  • property_definition β€” this string defines a set of properties tied to a particular algorithm implementation, and the appropriate fetching functionality (like EVP_CIPHER_fetch(3), EVP_MD_fetch(3), etc) uses it for a finer grained lookup of an algorithm implementation. Super useful when multiple implementations of the same algorithm are sitting around. See property(7) for a fuller description of what goes in this string.
  • implementation β€” a pointer to an OSSL_DISPATCH(3) array, containing pointers to the functions of a particular algorithm implementation. 🧚
  • algorithm_description β€” a string with a short human-readable description of the algorithm.

πŸ“ NOTES πŸ“

πŸ¦‹ On the subject of algorithm names πŸ¦‹

Providers may find the need to register ASN.1 OIDs for algorithms using OBJ_create(3) (via the core_obj_create upcall described in provider-base(7)), because some application or library β€” possibly still the OpenSSL libraries, even β€” uses NIDs to look up algorithms.

In that scenario, you must make sure that the corresponding OSSL_ALGORITHM's algorithm_names includes both the short and the long name. fr fr, both.

Most of the time, registering ASN.1 OIDs like this shouldn't be necessary, and applications and libraries are encouraged to use OBJ_obj2txt(3) to get a text representation of the OID β€” which may be a long or short name for OIDs that are registered, or the OID itself in canonical decimal text form if it's not registered (or if OBJ_obj2txt(3) is called with no_name = 1).

It's recommended to make sure that the corresponding OSSL_ALGORITHM's algorithm_names includes known names as well as the OID itself in canonical decimal text form. That way you've covered all scenarios. 🌈

πŸ‘€ SEE ALSO πŸ‘€

crypto(7), provider-base(7), openssl-core.h(7), openssl-core_dispatch.h(7), OSSL_DISPATCH(3)

⏳ HISTORY ⏳

OSSL_ALGORITHM was added in OpenSSL 3.0 πŸ’«

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


and that's the whole page, bestie, we ate and left no crumbs πŸ“ this was OpenSSL 4.0.3, dated 2026-09-29 β€” catch you in the next manpage, muah πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from