diff options
Diffstat (limited to 'doc/man3')
| -rw-r--r-- | doc/man3/EVP_PKEY_new.pod | 14 | ||||
| -rw-r--r-- | doc/man3/OPENSSL_secure_malloc.pod | 9 | ||||
| -rw-r--r-- | doc/man3/PEM_read_CMS.pod | 8 |
3 files changed, 24 insertions, 7 deletions
diff --git a/doc/man3/EVP_PKEY_new.pod b/doc/man3/EVP_PKEY_new.pod index 72d129deff24..0a56600c2b60 100644 --- a/doc/man3/EVP_PKEY_new.pod +++ b/doc/man3/EVP_PKEY_new.pod @@ -219,7 +219,19 @@ general private key without reference to any particular algorithm. The structure returned by EVP_PKEY_new() is empty. To add a private or public key to this empty structure use the appropriate functions described in L<EVP_PKEY_set1_RSA(3)>, L<EVP_PKEY_set1_DSA(3)>, L<EVP_PKEY_set1_DH(3)> or -L<EVP_PKEY_set1_EC_KEY(3)>. +L<EVP_PKEY_set1_EC_KEY(3)> for legacy key types implemented in internal +OpenSSL providers. + +For fully provider-managed key types (see L<provider-keymgmt(7)>), +possibly implemented in external providers, use functions such as +L<EVP_PKEY_set1_encoded_public_key(3)> or L<EVP_PKEY_fromdata(3)> +to populate key data. + +Generally caution is advised for using an B<EVP_PKEY> structure across +different library contexts: In order for an B<EVP_PKEY> to be shared by +multiple library contexts the providers associated with the library contexts +must have key managers that support the key type and implement the +OSSL_FUNC_keymgmt_import() and OSSL_FUNC_keymgmt_export() functions. =head1 RETURN VALUES diff --git a/doc/man3/OPENSSL_secure_malloc.pod b/doc/man3/OPENSSL_secure_malloc.pod index 1bddd7737069..dbc7073aac18 100644 --- a/doc/man3/OPENSSL_secure_malloc.pod +++ b/doc/man3/OPENSSL_secure_malloc.pod @@ -45,7 +45,12 @@ the program's dynamic memory area, where keys and other sensitive information might be stored, OpenSSL supports the concept of a "secure heap." The level and type of security guarantees depend on the operating system. It is a good idea to review the code and see if it addresses your -threat model and concerns. +threat model and concerns. It should be noted that the secure heap +uses a single read/write lock, and therefore any operations +that involve allocation or freeing of secure heap memory are serialised, +blocking other threads. With that in mind, highly concurrent applications +should enable the secure heap with caution and be aware of the performance +implications for multi-threaded code. If a secure heap is used, then private key B<BIGNUM> values are stored there. This protects long-term storage of private keys, but will not necessarily @@ -135,7 +140,7 @@ a B<size_t> in OpenSSL 3.0. =head1 COPYRIGHT -Copyright 2015-2024 The OpenSSL Project Authors. All Rights Reserved. +Copyright 2015-2025 The OpenSSL Project Authors. All Rights Reserved. Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy diff --git a/doc/man3/PEM_read_CMS.pod b/doc/man3/PEM_read_CMS.pod index dbccf26cd893..880e31481029 100644 --- a/doc/man3/PEM_read_CMS.pod +++ b/doc/man3/PEM_read_CMS.pod @@ -84,9 +84,9 @@ see L<openssl_user_macros(7)>: =head1 DESCRIPTION -All of the functions described on this page are deprecated. -Applications should use OSSL_ENCODER_to_bio() and OSSL_DECODER_from_bio() -instead. +To replace the deprecated functions listed above, applications should use the +B<EVP_PKEY> type and OSSL_DECODER_from_bio() and OSSL_ENCODER_to_bio() to +read and write PEM data containing key parameters or private and public keys. In the description below, B<I<TYPE>> is used as a placeholder for any of the OpenSSL datatypes, such as B<X509>. @@ -142,7 +142,7 @@ were deprecated in OpenSSL 3.0. =head1 COPYRIGHT -Copyright 1998-2023 The OpenSSL Project Authors. All Rights Reserved. +Copyright 1998-2025 The OpenSSL Project Authors. All Rights Reserved. Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy |