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