$NetBSD: OSSL_ALGORITHM.3,v 1.5 2024/09/08 13:08:26 christos Exp $ -*- mode: troff; coding: utf-8 -*- Automatically generated by Pod::Man 5.01 (Pod::Simple 3.43) Standard preamble: ========================================================================..
..
..
\*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.. ds C` ""
. ds C' ""
'br\}
. 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
======================================================================== Title "OSSL_ALGORITHM 3" OSSL_ALGORITHM 3 2024-09-03 3.0.15 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
OSSL_ALGORITHM 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 NULL.
This type of array is typically returned by the provider's operation querying
function, further described in "Provider Functions" in provider-base\|(7).
"OSSL_ALGORITHM 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 RSA 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 OBJECT IDENTIFIER (OID), as given by the
PKCS#1 RFC's ASN.1 module <https://
www.rfc-editor.org/
rfc/
rfc8017#appendix-C>
\(bu 4
\f(CW1.2.840.113549.1.1.1
.Sp
This is the OID 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 "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.
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
OSSL_DISPATCH\|(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 ASN.1 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 OSSL_ALGORITHM's
\fIalgorithm_names includes both the short and the long name.
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
\fIalgorithm_names include known names as well as the OID 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),
OSSL_DISPATCH\|(3)
HISTORY
Header "HISTORY" \fBOSSL_ALGORITHM 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 "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>.