2
0

provider.pod 8.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264
  1. =pod
  2. =head1 NAME
  3. provider - OpenSSL operation implementation providers
  4. =head1 SYNOPSIS
  5. =for openssl generic
  6. #include <openssl/provider.h>
  7. =head1 DESCRIPTION
  8. =head2 General
  9. This page contains information useful to provider authors.
  10. A I<provider>, in OpenSSL terms, is a unit of code that provides one
  11. or more implementations for various operations for diverse algorithms
  12. that one might want to perform.
  13. An I<operation> is something one wants to do, such as encryption and
  14. decryption, key derivation, MAC calculation, signing and verification,
  15. etc.
  16. An I<algorithm> is a named method to perform an operation.
  17. Very often, the algorithms revolve around cryptographic operations,
  18. but may also revolve around other types of operation, such as managing
  19. certain types of objects.
  20. See L<crypto(7)> for further details.
  21. =head2 Provider
  22. A I<provider> offers an initialization function, as a set of base
  23. functions in the form of an B<OSSL_DISPATCH> array, and by extension,
  24. a set of B<OSSL_ALGORITHM>s (see L<openssl-core.h(7)>).
  25. It may be a dynamically loadable module, or may be built-in, in
  26. OpenSSL libraries or in the application.
  27. If it's a dynamically loadable module, the initialization function
  28. must be named C<OSSL_provider_init> and must be exported.
  29. If it's built-in, the initialization function may have any name.
  30. The initialization function must have the following signature:
  31. int NAME(const OSSL_CORE_HANDLE *handle,
  32. const OSSL_DISPATCH *in, const OSSL_DISPATCH **out,
  33. void **provctx);
  34. I<handle> is the OpenSSL library object for the provider, and works
  35. as a handle for everything the OpenSSL libraries need to know about
  36. the provider.
  37. For the provider itself, it is passed to some of the functions given in the
  38. dispatch array I<in>.
  39. I<in> is a dispatch array of base functions offered by the OpenSSL
  40. libraries, and the available functions are further described in
  41. L<provider-base(7)>.
  42. I<*out> must be assigned a dispatch array of base functions that the
  43. provider offers to the OpenSSL libraries.
  44. The functions that may be offered are further described in
  45. L<provider-base(7)>, and they are the central means of communication
  46. between the OpenSSL libraries and the provider.
  47. I<*provctx> should be assigned a provider specific context to allow
  48. the provider multiple simultaneous uses.
  49. This pointer will be passed to various operation functions offered by
  50. the provider.
  51. Note that the provider will not be made available for applications to use until
  52. the initialization function has completed and returned successfully.
  53. One of the functions the provider offers to the OpenSSL libraries is
  54. the central mechanism for the OpenSSL libraries to get access to
  55. operation implementations for diverse algorithms.
  56. Its referred to with the number B<OSSL_FUNC_PROVIDER_QUERY_OPERATION>
  57. and has the following signature:
  58. const OSSL_ALGORITHM *provider_query_operation(void *provctx,
  59. int operation_id,
  60. const int *no_store);
  61. I<provctx> is the provider specific context that was passed back by
  62. the initialization function.
  63. I<operation_id> is an operation identity (see L</Operations> below).
  64. I<no_store> is a flag back to the OpenSSL libraries which, when
  65. nonzero, signifies that the OpenSSL libraries will not store a
  66. reference to the returned data in their internal store of
  67. implementations.
  68. The returned B<OSSL_ALGORITHM> is the foundation of any OpenSSL
  69. library API that uses providers for their implementation, most
  70. commonly in the I<fetching> type of functions
  71. (see L<crypto(7)/ALGORITHM FETCHING>).
  72. =head2 Operations
  73. Operations are referred to with numbers, via macros with names
  74. starting with C<OSSL_OP_>.
  75. With each operation comes a set of defined function types that a
  76. provider may or may not offer, depending on its needs.
  77. Currently available operations are:
  78. =over 4
  79. =item Digests
  80. In the OpenSSL libraries, the corresponding method object is
  81. B<EVP_MD>.
  82. The number for this operation is B<OSSL_OP_DIGEST>.
  83. The functions the provider can offer are described in
  84. L<provider-digest(7)>.
  85. =item Symmetric ciphers
  86. In the OpenSSL libraries, the corresponding method object is
  87. B<EVP_CIPHER>.
  88. The number for this operation is B<OSSL_OP_CIPHER>.
  89. The functions the provider can offer are described in
  90. L<provider-cipher(7)>.
  91. =item Message Authentication Code (MAC)
  92. In the OpenSSL libraries, the corresponding method object is
  93. B<EVP_MAC>.
  94. The number for this operation is B<OSSL_OP_MAC>.
  95. The functions the provider can offer are described in
  96. L<provider-mac(7)>.
  97. =item Key Derivation Function (KDF)
  98. In the OpenSSL libraries, the corresponding method object is
  99. B<EVP_KDF>.
  100. The number for this operation is B<OSSL_OP_KDF>.
  101. The functions the provider can offer are described in
  102. L<provider-kdf(7)>.
  103. =item Key Exchange
  104. In the OpenSSL libraries, the corresponding method object is
  105. B<EVP_KEYEXCH>.
  106. The number for this operation is B<OSSL_OP_KEYEXCH>.
  107. The functions the provider can offer are described in
  108. L<provider-keyexch(7)>.
  109. =item Asymmetric Ciphers
  110. In the OpenSSL libraries, the corresponding method object is
  111. B<EVP_ASYM_CIPHER>.
  112. The number for this operation is B<OSSL_OP_ASYM_CIPHER>.
  113. The functions the provider can offer are described in
  114. L<provider-asym_cipher(7)>.
  115. =item Asymmetric Key Encapsulation
  116. In the OpenSSL libraries, the corresponding method object is B<EVP_KEM>.
  117. The number for this operation is B<OSSL_OP_KEM>.
  118. The functions the provider can offer are described in L<provider-kem(7)>.
  119. =item Encoding
  120. In the OpenSSL libraries, the corresponding method object is
  121. B<OSSL_ENCODER>.
  122. The number for this operation is B<OSSL_OP_ENCODER>.
  123. The functions the provider can offer are described in
  124. L<provider-encoder(7)>.
  125. =item Decoding
  126. In the OpenSSL libraries, the corresponding method object is
  127. B<OSSL_DECODER>.
  128. The number for this operation is B<OSSL_OP_DECODER>.
  129. The functions the provider can offer are described in
  130. L<provider-decoder(7)>.
  131. =item Random Number Generation
  132. The number for this operation is B<OSSL_OP_RAND>.
  133. The functions the provider can offer for random number generation are described
  134. in L<provider-rand(7)>.
  135. =item Key Management
  136. The number for this operation is B<OSSL_OP_KEYMGMT>.
  137. The functions the provider can offer for key management are described in
  138. L<provider-keymgmt(7)>.
  139. =item Signing and Signature Verification
  140. The number for this operation is B<OSSL_OP_SIGNATURE>.
  141. The functions the provider can offer for digital signatures are described in
  142. L<provider-signature(7)>.
  143. =item Store Management
  144. The number for this operation is B<OSSL_OP_STORE>.
  145. The functions the provider can offer for store management are described in
  146. L<provider-storemgmt(7)>.
  147. =back
  148. =head3 Algorithm naming
  149. Algorithm names are case insensitive. Any particular algorithm can have multiple
  150. aliases associated with it. The canonical OpenSSL naming scheme follows this
  151. format:
  152. ALGNAME[VERSION?][-SUBNAME[VERSION?]?][-SIZE?][-MODE?]
  153. VERSION is only present if there are multiple versions of an algorithm (e.g.
  154. MD2, MD4, MD5). It may be omitted if there is only one version.
  155. SUBNAME may be present where multiple algorithms are combined together,
  156. e.g. MD5-SHA1.
  157. SIZE is only present if multiple versions of an algorithm exist with different
  158. sizes (e.g. AES-128-CBC, AES-256-CBC)
  159. MODE is only present where applicable.
  160. Other aliases may exist for example where standards bodies or common practice
  161. use alternative names or names that OpenSSL has used historically.
  162. =head1 OPENSSL PROVIDERS
  163. OpenSSL provides a number of its own providers. These are the default, base,
  164. fips, legacy and null providers. See L<crypto(7)> for an overview of these
  165. providers.
  166. =head1 SEE ALSO
  167. L<EVP_DigestInit_ex(3)>, L<EVP_EncryptInit_ex(3)>,
  168. L<OSSL_LIB_CTX(3)>,
  169. L<EVP_set_default_properties(3)>,
  170. L<EVP_MD_fetch(3)>,
  171. L<EVP_CIPHER_fetch(3)>,
  172. L<EVP_KEYMGMT_fetch(3)>,
  173. L<openssl-core.h(7)>,
  174. L<provider-base(7)>,
  175. L<provider-digest(7)>,
  176. L<provider-cipher(7)>,
  177. L<provider-keyexch(7)>
  178. =head1 HISTORY
  179. The concept of providers and everything surrounding them was
  180. introduced in OpenSSL 3.0.
  181. =head1 COPYRIGHT
  182. Copyright 2019-2022 The OpenSSL Project Authors. All Rights Reserved.
  183. Licensed under the Apache License 2.0 (the "License"). You may not use
  184. this file except in compliance with the License. You can obtain a copy
  185. in the file LICENSE in the source distribution or at
  186. L<https://www.openssl.org/source/license.html>.
  187. =cut