root
/
openssl
mirror of https://github.com/openssl/openssl.git
1
0
Fork 0
Code Issues Actions 7 Packages Projects Releases Wiki Activity
openssl/doc/man7/provider-mac.pod

237 lines
8.6 KiB
Plaintext
Raw Normal View History

Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
=pod
=head1 NAME
provider-mac - The mac library E<lt>-E<gt> provider functions
=head1 SYNOPSIS
POD: stop abusing comment OpenSSL uses some POD directives masquerading as 'comment' ('=for comment' etc). This is abusive and confusing. Instead, we use our own keyword. =for openssl whatever =begin openssl whatever =end openssl (we have never used the multiline form, but might start one day) Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/10048)
2019-09-29 23:10:59 +08:00
=for openssl multiple includes
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
Rename <openssl/core_numbers.h> -> <openssl/core_dispatch.h> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:21:19 +08:00
#include <openssl/core_dispatch.h>
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
#include <openssl/core_names.h>
/*
* None of these are actual functions, but are displayed like this for
* the function signatures for functions that are offered as function
* pointers in OSSL_DISPATCH arrays.
*/
/* Context management */
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
void *OSSL_FUNC_mac_newctx(void *provctx);
void OSSL_FUNC_mac_freectx(void *mctx);
void *OSSL_FUNC_mac_dupctx(void *src);
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
/* Encryption/decryption */
doc: update provider-mac documentation to account for the additional init() arguments Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14310)
2021-02-25 12:30:57 +08:00
int OSSL_FUNC_mac_init(void *mctx, unsigned char *key, size_t keylen,
const OSSL_PARAM params[]);
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
int OSSL_FUNC_mac_update(void *mctx, const unsigned char *in, size_t inl);
int OSSL_FUNC_mac_final(void *mctx, unsigned char *out, size_t *outl, size_t outsize);
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
/* MAC parameter descriptors */
doc: changes to match the updated context gettable/settable calls for MACs Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14240)
2021-02-23 09:03:31 +08:00
const OSSL_PARAM *OSSL_FUNC_mac_gettable_params(void *provctx);
const OSSL_PARAM *OSSL_FUNC_mac_gettable_ctx_params(void *mctx, void *provctx);
const OSSL_PARAM *OSSL_FUNC_mac_settable_ctx_params(void *mctx, void *provctx);
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
/* MAC parameters */
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
int OSSL_FUNC_mac_get_params(OSSL_PARAM params[]);
int OSSL_FUNC_mac_get_ctx_params(void *mctx, OSSL_PARAM params[]);
int OSSL_FUNC_mac_set_ctx_params(void *mctx, const OSSL_PARAM params[]);
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
=head1 DESCRIPTION
This documentation is primarily aimed at provider authors. See L<provider(7)>
for further information.
The MAC operation enables providers to implement mac algorithms and make
them available to applications via the API functions L<EVP_MAC_init(3)>,
Fix broken links, mainly typo's Also tweak find-doc-nits while fixing a bug (don't need .in files) Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10239)
2019-10-06 02:03:57 +08:00
L<EVP_MAC_update(3)> and L<EVP_MAC_final(3)>.
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
All "functions" mentioned here are passed as function pointers between
Replace some boldened types with a corresponding man page link The types OSSL_DISPATCH, OSSL_ITEM, OSSL_ALGORITHM, OSSL_PARAM, OSSL_CALLBACK, and OSSL_PASSPHRASE_CALLBACK are described in their own manual page, so we change every mention of them to links to those pages. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19842)
2022-12-05 23:59:06 +08:00
F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays via
L<OSSL_ALGORITHM(3)> arrays that are returned by the provider's
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
provider_query_operation() function
(see L<provider-base(7)/Provider Functions>).
All these "functions" have a corresponding function type definition
Small fixes and cleanups of provider API documentation Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14756)
2021-03-31 19:22:25 +08:00
named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the
Replace some boldened types with a corresponding man page link The types OSSL_DISPATCH, OSSL_ITEM, OSSL_ALGORITHM, OSSL_PARAM, OSSL_CALLBACK, and OSSL_PASSPHRASE_CALLBACK are described in their own manual page, so we change every mention of them to links to those pages. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19842)
2022-12-05 23:59:06 +08:00
function pointer from an L<OSSL_DISPATCH(3)> element named
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
B<OSSL_FUNC_{name}>.
For example, the "function" OSSL_FUNC_mac_newctx() has these:
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
Correct doubled OSSL_OSSL when documenting OSSL_FUNC_.._fn Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/17554)
2022-04-06 22:20:47 +08:00
typedef void *(OSSL_FUNC_mac_newctx_fn)(void *provctx);
static ossl_inline OSSL_FUNC_mac_newctx_fn
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_newctx(const OSSL_DISPATCH *opf);
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
Replace some boldened types with a corresponding man page link The types OSSL_DISPATCH, OSSL_ITEM, OSSL_ALGORITHM, OSSL_PARAM, OSSL_CALLBACK, and OSSL_PASSPHRASE_CALLBACK are described in their own manual page, so we change every mention of them to links to those pages. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19842)
2022-12-05 23:59:06 +08:00
L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as
Rename <openssl/core_numbers.h> -> <openssl/core_dispatch.h> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:21:19 +08:00
macros in L<openssl-core_dispatch.h(7)>, as follows:
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_newctx OSSL_FUNC_MAC_NEWCTX
OSSL_FUNC_mac_freectx OSSL_FUNC_MAC_FREECTX
OSSL_FUNC_mac_dupctx OSSL_FUNC_MAC_DUPCTX
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_init OSSL_FUNC_MAC_INIT
OSSL_FUNC_mac_update OSSL_FUNC_MAC_UPDATE
OSSL_FUNC_mac_final OSSL_FUNC_MAC_FINAL
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_get_params OSSL_FUNC_MAC_GET_PARAMS
OSSL_FUNC_mac_get_ctx_params OSSL_FUNC_MAC_GET_CTX_PARAMS
OSSL_FUNC_mac_set_ctx_params OSSL_FUNC_MAC_SET_CTX_PARAMS
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_gettable_params OSSL_FUNC_MAC_GETTABLE_PARAMS
OSSL_FUNC_mac_gettable_ctx_params OSSL_FUNC_MAC_GETTABLE_CTX_PARAMS
OSSL_FUNC_mac_settable_ctx_params OSSL_FUNC_MAC_SETTABLE_CTX_PARAMS
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
A mac algorithm implementation may not implement all of these functions.
In order to be a consistent set of functions, at least the following functions
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
must be implemented: OSSL_FUNC_mac_newctx(), OSSL_FUNC_mac_freectx(), OSSL_FUNC_mac_init(),
OSSL_FUNC_mac_update(), OSSL_FUNC_mac_final().
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
All other functions are optional.
=head2 Context Management Functions
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_newctx() should create and return a pointer to a provider side
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
structure for holding context information during a mac operation.
A pointer to this context will be passed back in a number of the other mac
operation function calls.
Fix some typos Reported-by: misspell-fixer <https://github.com/vlajos/misspell-fixer> CLA: trivial Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10544)
2019-12-01 07:18:47 +08:00
The parameter I<provctx> is the provider context generated during provider
Fix some broken doc links Replace L<> link to header-file with a C<> reference. Change some broken L<provider(3)> links to L<provider(7)>. For consistency, rename four cipher pages to have a specific mode. Fix up all references to any "generic" names to point to specific names. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/10100)
2019-08-22 13:21:25 +08:00
initialisation (see L<provider(7)>).
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_freectx() is passed a pointer to the provider side mac context in
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
the I<mctx> parameter.
If it receives NULL as I<mctx> value, it should not do anything other than
return.
This function should free any resources associated with that context.
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_dupctx() should duplicate the provider side mac context in the
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
I<mctx> parameter and return the duplicate copy.
=head2 Encryption/Decryption Functions
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_init() initialises a mac operation given a newly created provider
doc: update provider-mac documentation to account for the additional init() arguments Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14310)
2021-02-25 12:30:57 +08:00
side mac context in the I<mctx> parameter. The I<params> are set before setting
the MAC I<key> of I<keylen> bytes.
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_update() is called to supply data for MAC computation of a previously
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
initialised mac operation.
The I<mctx> parameter contains a pointer to a previously initialised provider
side context.
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_update() may be called multiple times for a single mac operation.
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_final() completes the MAC computation started through previous
OSSL_FUNC_mac_init() and OSSL_FUNC_mac_update() calls.
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
The I<mctx> parameter contains a pointer to the provider side context.
The resulting MAC should be written to I<out> and the amount of data written
to I<*outl>, which should not exceed I<outsize> bytes.
The same expectations apply to I<outsize> as documented for
L<EVP_MAC_final(3)>.
=head2 Mac Parameters
See L<OSSL_PARAM(3)> for further details on the parameters structure used by
these functions.
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_get_params() gets details of parameter values associated with the
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
provider algorithm and stores them in I<params>.
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_set_ctx_params() sets mac parameters associated with the given
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
provider side mac context I<mctx> to I<params>.
Any parameter settings are additional to any that were previously set.
doc: note that get_params and set_params calls should return true if the param array is null Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14383)
2021-03-03 09:32:39 +08:00
Passing NULL for I<params> should return true.
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_get_ctx_params() gets details of currently set parameter values
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
associated with the given provider side mac context I<mctx> and stores them
in I<params>.
doc: note that get_params and set_params calls should return true if the param array is null Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14383)
2021-03-03 09:32:39 +08:00
Passing NULL for I<params> should return true.
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
doc: changes to match the updated context gettable/settable calls for MACs Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14240)
2021-02-23 09:03:31 +08:00
OSSL_FUNC_mac_gettable_params(), OSSL_FUNC_mac_gettable_ctx_params(),
Replace some boldened types with a corresponding man page link The types OSSL_DISPATCH, OSSL_ITEM, OSSL_ALGORITHM, OSSL_PARAM, OSSL_CALLBACK, and OSSL_PASSPHRASE_CALLBACK are described in their own manual page, so we change every mention of them to links to those pages. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19842)
2022-12-05 23:59:06 +08:00
and OSSL_FUNC_mac_settable_ctx_params() all return constant L<OSSL_PARAM(3)>
doc: changes to match the updated context gettable/settable calls for MACs Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14240)
2021-02-23 09:03:31 +08:00
arrays as descriptors of the parameters that OSSL_FUNC_mac_get_params(),
OSSL_FUNC_mac_get_ctx_params(), and OSSL_FUNC_mac_set_ctx_params()
can handle, respectively. OSSL_FUNC_mac_gettable_ctx_params() and
OSSL_FUNC_mac_settable_ctx_params() will return the parameters associated
with the provider side context I<mctx> in its current state if it is
not NULL. Otherwise, they return the parameters associated with the
provider side algorithm I<provctx>.
DOCS: Fix provider-mac.pod and the docs of our implementations The idea being that doc/man7/provider-mac.pod is for provider authors, while provider users find the documentation for each implementation in doc/man7/EVP_MAC-*.pod, the documentation of parameters wasn't quite aligned. This change re-arranges the parameter documentation to be more aligned with this idea. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14380)
2021-03-02 01:46:20 +08:00
All MAC implementations are expected to handle the following parameters:
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
DOCS: Fix provider-mac.pod and the docs of our implementations The idea being that doc/man7/provider-mac.pod is for provider authors, while provider users find the documentation for each implementation in doc/man7/EVP_MAC-*.pod, the documentation of parameters wasn't quite aligned. This change re-arranges the parameter documentation to be more aligned with this idea. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14380)
2021-03-02 01:46:20 +08:00
=over 4
=item with OSSL_FUNC_set_ctx_params():
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
=over 4
Reformat param description lines Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10024)
2019-09-10 16:05:57 +08:00
=item "key" (B<OSSL_MAC_PARAM_KEY>) <octet string>
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
doc: update provider-mac documentation to account for the additional init() arguments Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14310)
2021-02-25 12:30:57 +08:00
Sets the key in the associated MAC ctx. This is identical to passing a I<key>
argument to the OSSL_FUNC_mac_init() function.
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
DOCS: Fix provider-mac.pod and the docs of our implementations The idea being that doc/man7/provider-mac.pod is for provider authors, while provider users find the documentation for each implementation in doc/man7/EVP_MAC-*.pod, the documentation of parameters wasn't quite aligned. This change re-arranges the parameter documentation to be more aligned with this idea. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14380)
2021-03-02 01:46:20 +08:00
=back
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
DOCS: Fix provider-mac.pod and the docs of our implementations The idea being that doc/man7/provider-mac.pod is for provider authors, while provider users find the documentation for each implementation in doc/man7/EVP_MAC-*.pod, the documentation of parameters wasn't quite aligned. This change re-arranges the parameter documentation to be more aligned with this idea. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14380)
2021-03-02 01:46:20 +08:00
=item with OSSL_FUNC_get_params():
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
DOCS: Fix provider-mac.pod and the docs of our implementations The idea being that doc/man7/provider-mac.pod is for provider authors, while provider users find the documentation for each implementation in doc/man7/EVP_MAC-*.pod, the documentation of parameters wasn't quite aligned. This change re-arranges the parameter documentation to be more aligned with this idea. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14380)
2021-03-02 01:46:20 +08:00
=over 4
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
Reformat param description lines Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10024)
2019-09-10 16:05:57 +08:00
=item "size" (B<OSSL_MAC_PARAM_SIZE>) <integer>
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
DOCS: Fix provider-mac.pod and the docs of our implementations The idea being that doc/man7/provider-mac.pod is for provider authors, while provider users find the documentation for each implementation in doc/man7/EVP_MAC-*.pod, the documentation of parameters wasn't quite aligned. This change re-arranges the parameter documentation to be more aligned with this idea. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14380)
2021-03-02 01:46:20 +08:00
Can be used to get the default MAC size (which might be the only allowable
MAC size for the implementation).
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
DOCS: Fix provider-mac.pod and the docs of our implementations The idea being that doc/man7/provider-mac.pod is for provider authors, while provider users find the documentation for each implementation in doc/man7/EVP_MAC-*.pod, the documentation of parameters wasn't quite aligned. This change re-arranges the parameter documentation to be more aligned with this idea. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14380)
2021-03-02 01:46:20 +08:00
Note that some implementations allow setting the size that the resulting MAC
should have as well, see the documentation of the implementation.
=back
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
doc: document the MAC block size getter Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15427)
2021-05-24 12:15:41 +08:00
=over 4
=item "size" (B<OSSL_MAC_PARAM_BLOCK_SIZE>) <integer>
Can be used to get the MAC block size (if supported by the algorithm).
=back
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
=back
doc: note that MAC lifecycle transitions will be enforced at some point Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14522)
2021-03-24 11:38:57 +08:00
=head1 NOTES
The MAC life-cycle is described in L<life_cycle-rand(7)>. Providers should
ensure that the various transitions listed there are supported. At some point
the EVP layer will begin enforcing the listed transitions.
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
=head1 RETURN VALUES
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_newctx() and OSSL_FUNC_mac_dupctx() should return the newly created
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
provider side mac context, or NULL on failure.
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_init(), OSSL_FUNC_mac_update(), OSSL_FUNC_mac_final(), OSSL_FUNC_mac_get_params(),
OSSL_FUNC_mac_get_ctx_params() and OSSL_FUNC_mac_set_ctx_params() should return 1 for
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
success or 0 on error.
Make the naming scheme for dispatched functions more consistent The new naming scheme consistently usese the `OSSL_FUNC_` prefix for all functions which are dispatched between the core and providers. This change includes in particular all up- and downcalls, i.e., the dispatched functions passed from core to provider and vice versa. - OSSL_core_ -> OSSL_FUNC_core_ - OSSL_provider_ -> OSSL_FUNC_core_ For operations and their function dispatch tables, the following convention is used: Type | Name (evp_generic_fetch(3)) | ---------------------|-----------------------------------| operation | OSSL_OP_FOO | function id | OSSL_FUNC_FOO_FUNCTION_NAME | function "name" | OSSL_FUNC_foo_function_name | function typedef | OSSL_FUNC_foo_function_name_fn | function ptr getter | OSSL_FUNC_foo_function_name | Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12222)
2020-06-21 07:19:16 +08:00
OSSL_FUNC_mac_gettable_params(), OSSL_FUNC_mac_gettable_ctx_params() and
Replace some boldened types with a corresponding man page link The types OSSL_DISPATCH, OSSL_ITEM, OSSL_ALGORITHM, OSSL_PARAM, OSSL_CALLBACK, and OSSL_PASSPHRASE_CALLBACK are described in their own manual page, so we change every mention of them to links to those pages. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19842)
2022-12-05 23:59:06 +08:00
OSSL_FUNC_mac_settable_ctx_params() should return a constant L<OSSL_PARAM(3)>
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
array, or NULL if none is offered.
=head1 SEE ALSO
DOCS: Fix provider-mac.pod and the docs of our implementations The idea being that doc/man7/provider-mac.pod is for provider authors, while provider users find the documentation for each implementation in doc/man7/EVP_MAC-*.pod, the documentation of parameters wasn't quite aligned. This change re-arranges the parameter documentation to be more aligned with this idea. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/14380)
2021-03-02 01:46:20 +08:00
L<provider(7)>,
L<EVP_MAC-BLAKE2(7)>, L<EVP_MAC-CMAC(7)>, L<EVP_MAC-GMAC(7)>,
L<EVP_MAC-HMAC(7)>, L<EVP_MAC-KMAC(7)>, L<EVP_MAC-Poly1305(7)>,
doc: note that MAC lifecycle transitions will be enforced at some point Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14522)
2021-03-24 11:38:57 +08:00
L<EVP_MAC-Siphash(7)>,
L<life_cycle-mac(7)>, L<EVP_MAC(3)>
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
=head1 HISTORY
The provider MAC interface was introduced in OpenSSL 3.0.
=head1 COPYRIGHT
Update copyright year Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14235)
2021-02-18 22:57:13 +08:00
Copyright 2019-2021 The OpenSSL Project Authors. All Rights Reserved.
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
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
in the file LICENSE in the source distribution or at
L<https://www.openssl.org/source/license.html>.
=cut