OSSL_ALGORITHM.pod 4.5 KB

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