OSSL_ALGORITHM(3ossl)

💅 OSSL_ALGORITHM — the 3ossl glow-up

okay so bestie, this is the OSSL_ALGORITHM(3ossl) page and honestly it's kind of iconic: it's the little struct that tells the whole OpenSSL world what algorithms a provider actually ships. Let's get into it ✨

---

🌸 NAME 🌸

OSSL_ALGORITHM — the OpenSSL core type that defines a fetchable algorithm. That's the whole vibe. 🫶

---

🦋 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;
};

like, that's it. four fields. main character energy, minimal effort. 💅

---

💖 DESCRIPTION 💖

So OSSL_ALGORITHM is a public structure that describes an algorithm which a provider(7) provides. Arrays of this type get handed back by providers on demand when the OpenSSL libraries come asking — like "hey what do you actually implement, and with what properties?" — and the provider's all "say less, here's the list." 📋

🚨 no cap, this part matters: arrays of this type must be terminated with a tuple where algorithm_names is NULL. If you forget the terminator, the array just keeps going and that's a whole mess. 😭

This type of array is typically returned by the provider's operation querying function — that's further described in "Provider Functions" in provider-base(7). iykyk.

---

🌈 OSSL_ALGORITHM fields 🌈

• algorithm_names — this string is a colon separated set of names / identities, and it's the thing the appropriate fetching functionality (like EVP_CIPHER_fetch(3), EVP_MD_fetch(3), etc.) uses to find the algorithm you actually want. ✨

Multiple names / identities let one specific algorithm implementation be fetched multiple ways. Lowkey genius. For example, 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 use the first of the algorithm names as the main or canonical name, on a per algorithm implementation basis. 👑

See the notes "On the subject of algorithm names" below for a more in-depth discussion on algorithm_names and how that may interact with applications and libraries — including OpenSSL's own. fr fr.

• property_definition — this string defines a set of properties associated with a particular algorithm implementation, and it's used by the appropriate fetching functionality (like EVP_CIPHER_fetch(3), EVP_MD_fetch(3), etc.) for a finer grained lookup of an algorithm implementation. Super useful when you've got multiple implementations of the same algorithm hanging around and you gotta be picky. 🎀

See property(7) for a further description of the contents of this string.

• implementation — a pointer to an OSSL_DISPATCH(3) array, containing pointers to the functions of a particular algorithm implementation. like the actual muscle behind the vibe check 💪
• algorithm_description — a string with a short human-readable description of the algorithm. cute for humans, that's the whole point 🧚

---

💀 NOTES 💀

⭐ On the subject of algorithm names ⭐

Providers may find the need to register ASN.1 OIDs for algorithms using OBJ_create(3) — that's 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. both. no skipping. 🫶

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 not (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 should cover all scenarios. periodt. 💅

---

🔥 SEE ALSO 🔥

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

go read them, they're giving lore 📚

---

🌸 HISTORY 🌸

OSSL_ALGORITHM was added in OpenSSL 3.0 — a classic, an era, we love a legend 🎀

---

💜 COPYRIGHT 💜

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.

---

okay that's the whole page bestie, you ate it up 💅✨ version 3.5.6, dated 2026-04-07 — that's the OSSL_ALGORITHM(3ossl) of the day, go forth and fetch algorithms responsibly 🦋🌈🍓