xref: /freebsd/secure/lib/libcrypto/man/man3/OSSL_ALGORITHM.3 (revision 9f23cbd6cae82fd77edfad7173432fa8dccd0a95)
Automatically generated by Pod::Man 4.14 (Pod::Simple 3.40)

Standard preamble:
========================================================================
..
..
.. Set up some character translations and predefined strings. \*(-- will
give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
double quote, and \*(R" will give a right double quote. \*(C+ will
give a nicer C++. Capital omega is used to do unbreakable dashes and
therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
nothing in troff, for use with C<>.
.tr \(*W- . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' . ds C` . ds C' 'br\}
Escape single quotes in literal strings from groff's Unicode transform.

If the F register is >0, we'll generate index entries on stderr for
titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
entries marked with X<> in POD. Of course, you'll have to process the
output yourself in some meaningful fashion.

Avoid warning from groff about undefined register 'F'.
.. .nr rF 0 . if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} . \} .\} .rr rF
Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff . ds #H 0 . ds #V .8m . ds #F .3m . ds #[ \f1 . ds #] .\} . ds #H ((1u-(\\\\n(.fu%2u))*.13m) . ds #V .6m . ds #F 0 . ds #[ \& . ds #] \& .\} . \" simple accents for nroff and troff . ds ' \& . ds ` \& . ds ^ \& . ds , \& . ds ~ ~ . ds / .\} . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' .\} . \" troff and (daisy-wheel) nroff accents . \" corrections for vroff . \" for low resolution devices (crt and lpr) \{\ . ds : e . ds 8 ss . ds o a . ds d- d\h'-1'\(ga . ds D- D\h'-1'\(hy . ds th \o'bp' . ds Th \o'LP' . ds ae ae . ds Ae AE .\} ========================================================================

Title "OSSL_ALGORITHM 3"
OSSL_ALGORITHM 3 "2023-05-30" "3.0.9" "OpenSSL"
For nroff, turn off justification. Always turn off hyphenation; it makes
way too many mistakes in technical documents.
"NAME"
OSSL_ALGORITHM - OpenSSL Core type to define a fetchable algorithm
"SYNOPSIS"
Header "SYNOPSIS" .Vb 1 #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; }; .Ve
"DESCRIPTION"
Header "DESCRIPTION" The \s-1OSSL_ALGORITHM\s0 type is a public structure that describes an algorithm that a provider\|(7) provides. Arrays of this type are returned by providers on demand from the OpenSSL libraries to describe what algorithms the providers provide implementations of, and with what properties.

Arrays of this type must be terminated with a tuple where algorithm_names is \s-1NULL.\s0

This type of array is typically returned by the provider's operation querying function, further described in \*(L"Provider Functions\*(R" in provider-base\|(7).

"\s-1OSSL_ALGORITHM\s0 fields"
Subsection "OSSL_ALGORITHM fields"
"algorithm_names" 4
Item "algorithm_names" This string is a colon separated set of names / identities, and is used by the appropriate fetching functionality (such as EVP_CIPHER_fetch\|(3), \fBEVP_MD_fetch\|(3), etc) to find the desired algorithm. .Sp Multiple names / identities allow a specific algorithm implementation to be fetched multiple ways. For example, the \s-1RSA\s0 algorithm has the following known identities:

"\(bu" 4
\f(CW\*(C`RSA\*(C'
"\(bu" 4
\f(CW\*(C`rsaEncryption\*(C' .Sp This is the name of the algorithm's \s-1OBJECT IDENTIFIER\s0 (\s-1OID\s0), as given by the PKCS#1 \s-1RFC\s0's \s-1ASN.1\s0 module <https://www.rfc-editor.org/rfc/rfc8017#appendix-C>
"\(bu" 4
\f(CW1.2.840.113549.1.1.1 .Sp This is the \s-1OID\s0 itself for \*(C`rsaEncryption\*(C', in canonical decimal text form.

.Sp The resulting algorithm_names string would look like this: .Sp .Vb 1 "RSA:rsaEncryption:1.2.840.113549.1.1.1" .Ve .Sp The OpenSSL libraries use the first of the algorithm names as the main or canonical name, on a per algorithm implementation basis. .Sp See the notes \*(L"On the subject of algorithm names\*(R" below for a more in depth discussion on algorithm_names and how that may interact with applications and libraries, including OpenSSL's.

"property_definition" 4
Item "property_definition" This string defines a set of properties associated with a particular algorithm implementation, and is used by the appropriate fetching functionality (such as EVP_CIPHER_fetch\|(3), EVP_MD_fetch\|(3), etc) for a finer grained lookup of an algorithm implementation, which is useful in case multiple implementations of the same algorithm are available. .Sp See property\|(7) for a further description of the contents of this string.
"implementation" 4
Item "implementation" Pointer to an \s-1OSSL_DISPATCH\s0\|(3) array, containing pointers to the functions of a particular algorithm implementation.
"algorithm_description" 4
Item "algorithm_description" A string with a short human-readable description of the algorithm.
"NOTES"
Header "NOTES"
"On the subject of algorithm names"
Subsection "On the subject of algorithm names" Providers may find the need to register \s-1ASN.1\s0 OIDs for algorithms using \fBOBJ_create\|(3) (via the core_obj_create upcall described in \fBprovider-base\|(7), because some application or library \*(-- possibly still the OpenSSL libraries, even \*(-- use NIDs to look up algorithms.

In that scenario, you must make sure that the corresponding \s-1OSSL_ALGORITHM\s0's \fIalgorithm_names includes both the short and the long name.

Most of the time, registering \s-1ASN.1\s0 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 \s-1OID,\s0 which may be a long or short name for OIDs that are registered, or the \s-1OID\s0 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 \s-1OSSL_ALGORITHM\s0's \fIalgorithm_names include known names as well as the \s-1OID\s0 itself in canonical decimal text form. That should cover all scenarios.

"SEE ALSO"
Header "SEE ALSO" \fBcrypto\|(7), provider-base\|(7), openssl-core.h\|(7), \fBopenssl-core_dispatch.h\|(7), \s-1OSSL_DISPATCH\s0\|(3)
"HISTORY"
Header "HISTORY" \fB\s-1OSSL_ALGORITHM\s0 was added in OpenSSL 3.0
"COPYRIGHT"
Header "COPYRIGHT" Copyright 2022 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the \*(L"License\*(R"). You may not use this file except in compliance with the License. You can obtain a copy in the file \s-1LICENSE\s0 in the source distribution or at <https://www.openssl.org/source/license.html>.