| 1 | =pod
|
|---|
| 2 |
|
|---|
| 3 | =head1 NAME
|
|---|
| 4 |
|
|---|
| 5 | OSSL_ALGORITHM - OpenSSL Core type to define a fetchable algorithm
|
|---|
| 6 |
|
|---|
| 7 | =head1 SYNOPSIS
|
|---|
| 8 |
|
|---|
| 9 | #include <openssl/core.h>
|
|---|
| 10 |
|
|---|
| 11 | typedef struct ossl_algorithm_st OSSL_ALGORITHM;
|
|---|
| 12 | struct ossl_algorithm_st {
|
|---|
| 13 | const char *algorithm_names; /* key */
|
|---|
| 14 | const char *property_definition; /* key */
|
|---|
| 15 | const OSSL_DISPATCH *implementation;
|
|---|
| 16 | const char *algorithm_description;
|
|---|
| 17 | };
|
|---|
| 18 |
|
|---|
| 19 | =head1 DESCRIPTION
|
|---|
| 20 |
|
|---|
| 21 | The B<OSSL_ALGORITHM> type is a I<public structure> that describes an
|
|---|
| 22 | algorithm that a L<provider(7)> provides. Arrays of this type are returned
|
|---|
| 23 | by providers on demand from the OpenSSL libraries to describe what
|
|---|
| 24 | algorithms the providers provide implementations of, and with what
|
|---|
| 25 | properties.
|
|---|
| 26 |
|
|---|
| 27 | Arrays of this type must be terminated with a tuple where I<algorithm_names>
|
|---|
| 28 | is NULL.
|
|---|
| 29 |
|
|---|
| 30 | This type of array is typically returned by the provider's operation querying
|
|---|
| 31 | function, further described in L<provider-base(7)/Provider Functions>.
|
|---|
| 32 |
|
|---|
| 33 | =head2 B<OSSL_ALGORITHM> fields
|
|---|
| 34 |
|
|---|
| 35 | =over 4
|
|---|
| 36 |
|
|---|
| 37 | =item I<algorithm_names>
|
|---|
| 38 |
|
|---|
| 39 | This string is a colon separated set of names / identities, and is used by
|
|---|
| 40 | the appropriate fetching functionality (such as L<EVP_CIPHER_fetch(3)>,
|
|---|
| 41 | L<EVP_MD_fetch(3)>, etc) to find the desired algorithm.
|
|---|
| 42 |
|
|---|
| 43 | Multiple names / identities allow a specific algorithm implementation to be
|
|---|
| 44 | fetched multiple ways. For example, the RSA algorithm has the following
|
|---|
| 45 | known identities:
|
|---|
| 46 |
|
|---|
| 47 | =over 4
|
|---|
| 48 |
|
|---|
| 49 | =item *
|
|---|
| 50 |
|
|---|
| 51 | C<RSA>
|
|---|
| 52 |
|
|---|
| 53 | =item *
|
|---|
| 54 |
|
|---|
| 55 | C<rsaEncryption>
|
|---|
| 56 |
|
|---|
| 57 | This is the name of the algorithm's OBJECT IDENTIFIER (OID), as given by the
|
|---|
| 58 | L<PKCS#1 RFC's ASN.1 module|https://www.rfc-editor.org/rfc/rfc8017#appendix-C>
|
|---|
| 59 |
|
|---|
| 60 | =item *
|
|---|
| 61 |
|
|---|
| 62 | C<1.2.840.113549.1.1.1>
|
|---|
| 63 |
|
|---|
| 64 | This is the OID itself for C<rsaEncryption>, in canonical decimal text form.
|
|---|
| 65 |
|
|---|
| 66 | =back
|
|---|
| 67 |
|
|---|
| 68 | The resulting I<algorithm_names> string would look like this:
|
|---|
| 69 |
|
|---|
| 70 | "RSA:rsaEncryption:1.2.840.113549.1.1.1"
|
|---|
| 71 |
|
|---|
| 72 | The OpenSSL libraries use the first of the algorithm names as the main
|
|---|
| 73 | or canonical name, on a per algorithm implementation basis.
|
|---|
| 74 |
|
|---|
| 75 | See the notes L</On the subject of algorithm names> below for a more in
|
|---|
| 76 | depth discussion on I<algorithm_names> and how that may interact with
|
|---|
| 77 | applications and libraries, including OpenSSL's.
|
|---|
| 78 |
|
|---|
| 79 | =item I<property_definition>
|
|---|
| 80 |
|
|---|
| 81 | This string defines a set of properties associated with a particular
|
|---|
| 82 | algorithm implementation, and is used by the appropriate fetching
|
|---|
| 83 | functionality (such as L<EVP_CIPHER_fetch(3)>, L<EVP_MD_fetch(3)>, etc) for
|
|---|
| 84 | a finer grained lookup of an algorithm implementation, which is useful in
|
|---|
| 85 | case multiple implementations of the same algorithm are available.
|
|---|
| 86 |
|
|---|
| 87 | See L<property(7)> for a further description of the contents of this
|
|---|
| 88 | string.
|
|---|
| 89 |
|
|---|
| 90 | =item I<implementation>
|
|---|
| 91 |
|
|---|
| 92 | Pointer to an L<OSSL_DISPATCH(3)> array, containing pointers to the
|
|---|
| 93 | functions of a particular algorithm implementation.
|
|---|
| 94 |
|
|---|
| 95 | =item I<algorithm_description>
|
|---|
| 96 |
|
|---|
| 97 | A string with a short human-readable description of the algorithm.
|
|---|
| 98 |
|
|---|
| 99 | =back
|
|---|
| 100 |
|
|---|
| 101 | =head1 NOTES
|
|---|
| 102 |
|
|---|
| 103 | =head2 On the subject of algorithm names
|
|---|
| 104 |
|
|---|
| 105 | Providers may find the need to register ASN.1 OIDs for algorithms using
|
|---|
| 106 | L<OBJ_create(3)> (via the B<core_obj_create> upcall described in
|
|---|
| 107 | L<provider-base(7)>, because some application or library -- possibly still
|
|---|
| 108 | the OpenSSL libraries, even -- use NIDs to look up algorithms.
|
|---|
| 109 |
|
|---|
| 110 | In that scenario, you must make sure that the corresponding B<OSSL_ALGORITHM>'s
|
|---|
| 111 | I<algorithm_names> includes both the short and the long name.
|
|---|
| 112 |
|
|---|
| 113 | Most of the time, registering ASN.1 OIDs like this shouldn't be necessary,
|
|---|
| 114 | and applications and libraries are encouraged to use L<OBJ_obj2txt(3)> to
|
|---|
| 115 | get a text representation of the OID, which may be a long or short name for
|
|---|
| 116 | OIDs that are registered, or the OID itself in canonical decimal text form
|
|---|
| 117 | if not (or if L<OBJ_obj2txt(3)> is called with I<no_name> = 1).
|
|---|
| 118 |
|
|---|
| 119 | It's recommended to make sure that the corresponding B<OSSL_ALGORITHM>'s
|
|---|
| 120 | I<algorithm_names> include known names as well as the OID itself in
|
|---|
| 121 | canonical decimal text form. That should cover all scenarios.
|
|---|
| 122 |
|
|---|
| 123 | =begin comment RETURN VALUES doesn't make sense for a manual that only
|
|---|
| 124 | describes a type, but document checkers still want that section, and
|
|---|
| 125 | to have more than just the section title.
|
|---|
| 126 |
|
|---|
| 127 | =head1 RETURN VALUES
|
|---|
| 128 |
|
|---|
| 129 | txt
|
|---|
| 130 |
|
|---|
| 131 | =end comment
|
|---|
| 132 |
|
|---|
| 133 | =head1 SEE ALSO
|
|---|
| 134 |
|
|---|
| 135 | L<crypto(7)>, L<provider-base(7)>, L<openssl-core.h(7)>,
|
|---|
| 136 | L<openssl-core_dispatch.h(7)>, L<OSSL_DISPATCH(3)>
|
|---|
| 137 |
|
|---|
| 138 | =head1 HISTORY
|
|---|
| 139 |
|
|---|
| 140 | B<OSSL_ALGORITHM> was added in OpenSSL 3.0
|
|---|
| 141 |
|
|---|
| 142 | =head1 COPYRIGHT
|
|---|
| 143 |
|
|---|
| 144 | Copyright 2022 The OpenSSL Project Authors. All Rights Reserved.
|
|---|
| 145 |
|
|---|
| 146 | Licensed under the Apache License 2.0 (the "License"). You may not use
|
|---|
| 147 | this file except in compliance with the License. You can obtain a copy
|
|---|
| 148 | in the file LICENSE in the source distribution or at
|
|---|
| 149 | L<https://www.openssl.org/source/license.html>.
|
|---|
| 150 |
|
|---|
| 151 | =cut
|
|---|
