OSSL_ALGORITHM(3ossl)

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

πŸ’… OSSL_ALGORITHM β€” like, the OpenSSL core type that defines a fetchable algorithm ✨

okay so this one lives in the 3ossl manual, bestie β€” welcome to the deep lore 🧚


🌸 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 πŸ’–

So OSSL_ALGORITHM is this public struct that describes an algorithm a provider(7) provides. Literally its whole job. Arrays of this type get handed back by providers on demand from the OpenSSL libraries, and they're basically the provider saying "here's what algorithms I've got implementations for, and here are their properties." 🫢

⚠️ Arrays of this type must be terminated with a tuple where algorithm_names is NULL. Don't forget the sentinel, bestie, or it's giving undefined chaos πŸ’€

This type of array is typically returned by the provider's operation querying function β€” and that's described further 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 what the appropriate fetching functionality (think EVP_CIPHER_fetch(3), EVP_MD_fetch(3), etc.) uses to find the algorithm you want. πŸ”

Multiple names / identities mean one specific algorithm implementation can be fetched multiple ways. Like, for example, the RSA algorithm has these known identities:

  • "RSA"
  • "rsaEncryption"
  • 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. πŸ‘‘

And go read the notes "On the subject of algorithm names" down below for a more in depth discussion of algorithm_names and how it may interact with applications and libraries, OpenSSL's included. πŸ‘€

  • property_definition β€” this string defines a set of properties associated with a particular algorithm implementation, and it's used by the appropriate fetching functionality (again: EVP_CIPHER_fetch(3), EVP_MD_fetch(3), etc.) for a finer grained lookup of an algorithm implementation. Super useful when multiple implementations of the same algorithm are hanging around. 🌈

See property(7) for a further description of what goes in this string, mwah πŸ’‹

  • implementation β€” 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. That's it, that's the field. πŸ’…

πŸ¦‹ NOTES πŸ¦‹

⭐ On the subject of algorithm names ⭐

Okay so providers may find they 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 even the OpenSSL libraries themselves, no cap β€” 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. Not one. Both. πŸ’€

Most of the time though, 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. That text rep may be a long or short name for OIDs that are registered, or the OID itself in canonical decimal text form if 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 should cover all scenarios, bestie β€” all of them. 🫢 periodt.


πŸ’œ 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 β€” iconic behavior honestly πŸŽ€


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 thing, no cap ✨ this version is from OpenSSL 3.5.0, dated 2026-09-25 β€” go forth and fetch your algorithms, main character πŸ¦‹πŸ’–

πŸ“¦ where this page comes from