Lines Matching +full:many +full:- +full:to +full:- +full:one

5 ossl-guide-libraries-introduction
6 - OpenSSL Guide: An introduction to the OpenSSL libraries
22 The C<libssl> library provides functions to perform secure communication between
26 The C<libssl> library depends on and uses many of the capabilities supplied by
40 algorithm AES). In order to use an algorithm you must have at least one
44 Providers may either be "built-in" or in the form of a separate loadable module
45 file (typically one ending in ".so" or ".dll" dependent on the platform). A
46 built-in provider is one that is either already present in C<libcrypto> or one
51 then the OpenSSL built-in "default" provider will be automatically loaded.
62 Many OpenSSL API functions make use of a library context. A library context can
66 application to each use a different library context and have different providers
72 Library contexts are represented by the B<OSSL_LIB_CTX> type. Many OpenSSL API
74 B<NULL> for this parameter to just use the default library context.
78 initialise OpenSSL for use. Unlike in earlier versions of OpenSSL (prior to
79 1.1.0) no explicit initialisation steps need to be taken.
82 automatically destroyed. No explicit de-initialisation steps need to be taken.
85 See also L<ossl-guide-libcrypto-introduction(7)/ALGORITHM FETCHING>.
89 In some cases the available providers may mean that more than one implementation
91 supplies alternative implementations of many of the same algorithms that are
95 When OpenSSL fetches an algorithm to use it is possible to specify a "property
96 query string" to guide the selection process. For example a property query
97 string of "provider=default" could be used to force the selection to only
100 Property query strings can be specified explicitly as an argument to a function.
101 It is also possible to specify a default property query string for the whole
108 See L<ossl-guide-libcrypto-introduction(7)/ALGORITHM FETCHING> for more
112 =head1 MULTI-THREADED APPLICATIONS
115 on most platforms) then most OpenSSL I<functions> are thread-safe in the sense
116 that it is safe to call the same function from multiple threads at the same
117 time. However most OpenSSL I<data structures> are not thread-safe. For example
119 would not be thread safe to call BIO_write() from one thread while calling
121 since both of them may attempt to make changes to the same B<BIO> object.
123 There are exceptions to these rules. A small number of functions are not thread
126 or fully thread safe. For example it is always safe to use an B<OSSL_LIB_CTX> in
129 See L<openssl-threads(7)> for a more detailed discussion on OpenSSL threading
135 function has been successful or not. It is considered best practice to always
136 check the return value from OpenSSL functions (where one is available).
142 success. Some of these functions will return 0 to indicate failure. Others may
146 small number of functions that do not conform to the above conventions (e.g.
147 they may return 0 to indicate success).
149 Due to the above variations in behaviour it is important to check the
150 documentation for each function for information about how to interpret the
153 It is sometimes necessary to get further information about the cause of a
154 failure (e.g. for debugging or logging purposes). Many (but not all) functions
155 will add further information about a failure to the OpenSSL error stack. By
160 OpenSSL supplies a set of error handling functions to query the error stack. See
164 for how to clear old errors from the error stack.
170 The algorithms available in each of these providers may vary due to build time
171 configuration options. The L<openssl-list(1)> command can be used to list the
174 The names of the algorithms shown from L<openssl-list(1)> can be used as an
175 algorithm identifier to the appropriate fetching function. Also see the provider
184 The default provider is built-in as part of the F<libcrypto> library and
193 provider would also need to be explicitly loaded if it is required.
195 See L<OSSL_PROVIDER-default(7)>.
207 used to select such algorithms.
209 See L<OSSL_PROVIDER-base(7)>.
216 validated according to FIPS standards. Should it be needed (if other
221 may also contain non-approved algorithm implementations and these can be
224 Typically the L</Base provider> will also need to be loaded because the FIPS
227 See L<OSSL_PROVIDER-FIPS(7)> and L<fips_module(7)>.
239 See L<OSSL_PROVIDER-legacy(7)>.
245 be automatically loaded if no other provider has been explicitly loaded. To
248 You can use this if you create your own library context and want to ensure that
254 See L<OSSL_PROVIDER-null(7)>.
263 The configuration file can be used to automatically load providers and set up
270 Many OpenSSL functions that "get" or "set" a value follow a naming convention
272 can also apply to some functions that "add" a value to an existing set, i.e.
280 In the B<0> version the ownership of the object is passed to (for an add or set)
283 to the I<crl> object. Therefore, after calling this function I<rev> should not
286 In the B<1> version the ownership of the object is not passed to or retained by
291 Many OpenSSL functions conform to a naming convention of the form
300 examples of how to use the various API functions. To look at them download the
304 B<demos> sub-directory.
306 The Makefiles in the subdirectories give instructions on how to build and run
311 See L<ossl-guide-libcrypto-introduction(7)> for a more detailed introduction to
312 using C<libcrypto> and L<ossl-guide-libssl-introduction(7)> for more information
317 L<openssl(1)>, L<ssl(7)>, L<evp(7)>, L<OSSL_LIB_CTX(3)>, L<openssl-threads(7)>,
318 L<property(7)>, L<OSSL_PROVIDER-default(7)>, L<OSSL_PROVIDER-base(7)>,
319 L<OSSL_PROVIDER-FIPS(7)>, L<OSSL_PROVIDER-legacy(7)>, L<OSSL_PROVIDER-null(7)>,
320 L<openssl-glossary(7)>, L<provider(7)>
324 Copyright 2000-2023 The OpenSSL Project Authors. All Rights Reserved.