OSSL_ALGORITHM(3ossl)
π 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 wherealgorithm_namesisNULL. 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 (thinkEVP_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"- 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
- This is the name of the algorithm's OBJECT IDENTIFIER (OID), as given by the PKCS#1 RFC's ASN.1 module
1.2.840.113549.1.1.1- This is the OID itself for
"rsaEncryption", in canonical decimal text form.
- This is the OID itself for
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 anOSSL_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 correspondingOSSL_ALGORITHM'salgorithm_namesincludes 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 πΈ
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
- opensuse-leap 16.0: openssl-3-doc 3.5.0-160000.11.1 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms