mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-12-27 06:21:43 +08:00
Code Issues Packages Projects Releases Wiki Activity
26f75c2d60
openssl/crypto/evp/mac_meth.c

244 lines
6.8 KiB
C
Raw Normal View History

Fix copyrights Add copyright to files that were missing it. Update license from OpenSSL to Apache as needed. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/17606)
2022-01-28 03:18:28 +08:00
/*
Copyright year updates Reviewed-by: Richard Levitte <levitte@openssl.org> Release: yes
2023-09-07 16:59:15 +08:00
* Copyright 2022-2023 The OpenSSL Project Authors. All Rights Reserved.
Fix copyrights Add copyright to files that were missing it. Update license from OpenSSL to Apache as needed. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/17606)
2022-01-28 03:18:28 +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
* https://www.openssl.org/source/license.html
*/
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/evp.h>
#include <openssl/err.h>
#include <openssl/core.h>
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 "internal/provider.h"
Add type_name member to provided methods and use it Fixes #14701 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14898)
2021-04-16 22:22:03 +08:00
#include "internal/core.h"
#include "crypto/evp.h"
Reorganize local header files Apart from public and internal header files, there is a third type called local header files, which are located next to source files in the source directory. Currently, they have different suffixes like '*_lcl.h', '*_local.h', or '*_int.h' This commit changes the different suffixes to '*_local.h' uniformly. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9333)
2019-09-28 06:45:40 +08:00
#include "evp_local.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
static int evp_mac_up_ref(void *vmac)
{
EVP_MAC *mac = vmac;
int ref = 0;
evp: update to structure based atomics Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21260)
2023-06-22 07:48:49 +08:00
CRYPTO_UP_REF(&mac->refcnt, &ref);
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
return 1;
}
static void evp_mac_free(void *vmac)
{
EVP_MAC *mac = vmac;
int ref = 0;
if (mac == NULL)
return;
evp: update to structure based atomics Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21260)
2023-06-22 07:48:49 +08:00
CRYPTO_DOWN_REF(&mac->refcnt, &ref);
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
if (ref > 0)
return;
Add type_name member to provided methods and use it Fixes #14701 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14898)
2021-04-16 22:22:03 +08:00
OPENSSL_free(mac->type_name);
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
ossl_provider_free(mac->prov);
evp: update to structure based atomics Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21260)
2023-06-22 07:48:49 +08:00
CRYPTO_FREE_REF(&mac->refcnt);
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
OPENSSL_free(mac);
}
static void *evp_mac_new(void)
{
EVP_MAC *mac = NULL;
if ((mac = OPENSSL_zalloc(sizeof(*mac))) == NULL
evp: update to structure based atomics Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21260)
2023-06-22 07:48:49 +08:00
|| !CRYPTO_NEW_REF(&mac->refcnt, 1)) {
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
evp_mac_free(mac);
return NULL;
}
return mac;
}
CORE: Add an algorithm_description field to OSSL_ALGORITHM This corresponds to the |info| field in EVP_PKEY_ASN1_METHOD, as well as the generic use of OBJ_nid2ln() as a one line description. We also add the base functionality to make use of this field. Fixes #14514 Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14656)
2021-03-16 21:14:43 +08:00
static void *evp_mac_from_algorithm(int name_id,
const OSSL_ALGORITHM *algodef,
OSSL_PROVIDER *prov)
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
{
CORE: Add an algorithm_description field to OSSL_ALGORITHM This corresponds to the |info| field in EVP_PKEY_ASN1_METHOD, as well as the generic use of OBJ_nid2ln() as a one line description. We also add the base functionality to make use of this field. Fixes #14514 Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14656)
2021-03-16 21:14:43 +08:00
const OSSL_DISPATCH *fns = algodef->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
EVP_MAC *mac = NULL;
int fnmaccnt = 0, fnctxcnt = 0;
In provider implemented methods, save the name number, not the name string Multiple names per implementation is already supported in the namemap, but hasn't been used yet. However, as soon as we have multiple names, we will get an issue with what name should be saved in the method. The solution is to not save the name itself, but rather the number it's associated with. This number is supposed to be unique for each set of names, and we assume that algorithm names are globally unique, i.e. there can be no name overlap between different algorithm types. Incidently, it was also found that the 'get' function used by ossl_construct_method() doesn't need all the parameters it was given; most of what it needs, it can now get through the data structure given by the caller of ossl_construct_method(). As a consequence, ossl_construct_method() itself doesn't need all the parameters it was given either. There are some added internal functions that are expected to disappear as soon as legacy code is removed, such as evp_first_name() and ossl_namemap_num2name(). Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
if ((mac = evp_mac_new()) == NULL) {
Stop raising ERR_R_MALLOC_FAILURE in most places Since OPENSSL_malloc() and friends report ERR_R_MALLOC_FAILURE, and at least handle the file name and line number they are called from, there's no need to report ERR_R_MALLOC_FAILURE where they are called directly, or when SSLfatal() and RLAYERfatal() is used, the reason `ERR_R_MALLOC_FAILURE` is changed to `ERR_R_CRYPTO_LIB`. There were a number of places where `ERR_R_MALLOC_FAILURE` was reported even though it was a function from a different sub-system that was called. Those places are changed to report ERR_R_{lib}_LIB, where {lib} is the name of that sub-system. Some of them are tricky to get right, as we have a lot of functions that belong in the ASN1 sub-system, and all the `sk_` calls or from the CRYPTO sub-system. Some extra adaptation was necessary where there were custom OPENSSL_malloc() wrappers, and some bugs are fixed alongside these changes. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19301)
2022-09-29 19:57:34 +08:00
ERR_raise(ERR_LIB_EVP, ERR_R_EVP_LIB);
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
return NULL;
}
In provider implemented methods, save the name number, not the name string Multiple names per implementation is already supported in the namemap, but hasn't been used yet. However, as soon as we have multiple names, we will get an issue with what name should be saved in the method. The solution is to not save the name itself, but rather the number it's associated with. This number is supposed to be unique for each set of names, and we assume that algorithm names are globally unique, i.e. there can be no name overlap between different algorithm types. Incidently, it was also found that the 'get' function used by ossl_construct_method() doesn't need all the parameters it was given; most of what it needs, it can now get through the data structure given by the caller of ossl_construct_method(). As a consequence, ossl_construct_method() itself doesn't need all the parameters it was given either. There are some added internal functions that are expected to disappear as soon as legacy code is removed, such as evp_first_name() and ossl_namemap_num2name(). Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
mac->name_id = name_id;
Add type_name member to provided methods and use it Fixes #14701 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14898)
2021-04-16 22:22:03 +08:00
if ((mac->type_name = ossl_algorithm_get1_first_name(algodef)) == NULL) {
evp_mac_free(mac);
return NULL;
}
CORE: Add an algorithm_description field to OSSL_ALGORITHM This corresponds to the |info| field in EVP_PKEY_ASN1_METHOD, as well as the generic use of OBJ_nid2ln() as a one line description. We also add the base functionality to make use of this field. Fixes #14514 Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14656)
2021-03-16 21:14:43 +08:00
mac->description = algodef->algorithm_description;
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
for (; fns->function_id != 0; fns++) {
switch (fns->function_id) {
case OSSL_FUNC_MAC_NEWCTX:
if (mac->newctx != NULL)
break;
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
mac->newctx = OSSL_FUNC_mac_newctx(fns);
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
fnctxcnt++;
break;
case OSSL_FUNC_MAC_DUPCTX:
if (mac->dupctx != NULL)
break;
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
mac->dupctx = OSSL_FUNC_mac_dupctx(fns);
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
break;
case OSSL_FUNC_MAC_FREECTX:
if (mac->freectx != NULL)
break;
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
mac->freectx = OSSL_FUNC_mac_freectx(fns);
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
fnctxcnt++;
break;
case OSSL_FUNC_MAC_INIT:
if (mac->init != NULL)
break;
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
mac->init = OSSL_FUNC_mac_init(fns);
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
fnmaccnt++;
break;
case OSSL_FUNC_MAC_UPDATE:
if (mac->update != NULL)
break;
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
mac->update = OSSL_FUNC_mac_update(fns);
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
fnmaccnt++;
break;
case OSSL_FUNC_MAC_FINAL:
if (mac->final != NULL)
break;
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
mac->final = OSSL_FUNC_mac_final(fns);
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
fnmaccnt++;
break;
case OSSL_FUNC_MAC_GETTABLE_PARAMS:
if (mac->gettable_params != NULL)
break;
mac->gettable_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_gettable_params(fns);
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
break;
case OSSL_FUNC_MAC_GETTABLE_CTX_PARAMS:
if (mac->gettable_ctx_params != NULL)
break;
mac->gettable_ctx_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_gettable_ctx_params(fns);
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
break;
case OSSL_FUNC_MAC_SETTABLE_CTX_PARAMS:
if (mac->settable_ctx_params != NULL)
break;
mac->settable_ctx_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_settable_ctx_params(fns);
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
break;
case OSSL_FUNC_MAC_GET_PARAMS:
if (mac->get_params != NULL)
break;
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
mac->get_params = OSSL_FUNC_mac_get_params(fns);
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
break;
Rename ctx_{get,set}_params to {get,set}_ctx_params Recently, we added dispatched functions to get parameter descriptions, and those for operation context parameters ended up being called something_gettable_ctx_params and something_settable_ctx_params. The corresponding dispatched functions to actually perform parameter transfers were previously called something_ctx_get_params and something_ctx_set_params, which doesn't quite match, so we rename them to something_get_ctx_params and something_set_ctx_params. An argument in favor of this name change is English, where you'd rather say something like "set the context parameters". This only change the libcrypto <-> provider interface. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9612)
2019-08-16 15:04:29 +08:00
case OSSL_FUNC_MAC_GET_CTX_PARAMS:
if (mac->get_ctx_params != NULL)
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
break;
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
mac->get_ctx_params = OSSL_FUNC_mac_get_ctx_params(fns);
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
break;
Rename ctx_{get,set}_params to {get,set}_ctx_params Recently, we added dispatched functions to get parameter descriptions, and those for operation context parameters ended up being called something_gettable_ctx_params and something_settable_ctx_params. The corresponding dispatched functions to actually perform parameter transfers were previously called something_ctx_get_params and something_ctx_set_params, which doesn't quite match, so we rename them to something_get_ctx_params and something_set_ctx_params. An argument in favor of this name change is English, where you'd rather say something like "set the context parameters". This only change the libcrypto <-> provider interface. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9612)
2019-08-16 15:04:29 +08:00
case OSSL_FUNC_MAC_SET_CTX_PARAMS:
if (mac->set_ctx_params != NULL)
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
break;
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
mac->set_ctx_params = OSSL_FUNC_mac_set_ctx_params(fns);
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
break;
}
}
if (fnmaccnt != 3
|| fnctxcnt != 2) {
/*
* In order to be a consistent set of functions we must have at least
* a complete set of "mac" functions, and a complete set of context
* management functions, as well as the size function.
*/
evp_mac_free(mac);
ERR_raise(ERR_LIB_EVP, EVP_R_INVALID_PROVIDER_FUNCTIONS);
return NULL;
}
mac->prov = prov;
if (prov != NULL)
ossl_provider_up_ref(prov);
return mac;
}
Rename OPENSSL_CTX prefix to OSSL_LIB_CTX Many of the new types introduced by OpenSSL 3.0 have an OSSL_ prefix, e.g., OSSL_CALLBACK, OSSL_PARAM, OSSL_ALGORITHM, OSSL_SERIALIZER. The OPENSSL_CTX type stands out a little by using a different prefix. For consistency reasons, this type is renamed to OSSL_LIB_CTX. Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12621)
2020-10-15 17:55:50 +08:00
EVP_MAC *EVP_MAC_fetch(OSSL_LIB_CTX *libctx, const char *algorithm,
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
const char *properties)
{
return evp_generic_fetch(libctx, OSSL_OP_MAC, algorithm, properties,
CORE: Add an algorithm_description field to OSSL_ALGORITHM This corresponds to the |info| field in EVP_PKEY_ASN1_METHOD, as well as the generic use of OBJ_nid2ln() as a one line description. We also add the base functionality to make use of this field. Fixes #14514 Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14656)
2021-03-16 21:14:43 +08:00
evp_mac_from_algorithm, evp_mac_up_ref,
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
evp_mac_free);
}
int EVP_MAC_up_ref(EVP_MAC *mac)
{
return evp_mac_up_ref(mac);
}
void EVP_MAC_free(EVP_MAC *mac)
{
evp_mac_free(mac);
}
Rename all getters to use get/get0 in name For functions that exist in 1.1.1 provide a simple aliases via #define. Fixes #15236 Functions with OSSL_DECODER_, OSSL_ENCODER_, OSSL_STORE_LOADER_, EVP_KEYEXCH_, EVP_KEM_, EVP_ASYM_CIPHER_, EVP_SIGNATURE_, EVP_KEYMGMT_, EVP_RAND_, EVP_MAC_, EVP_KDF_, EVP_PKEY_, EVP_MD_, and EVP_CIPHER_ prefixes are renamed. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15405)
2021-05-21 22:58:08 +08:00
const OSSL_PROVIDER *EVP_MAC_get0_provider(const EVP_MAC *mac)
Add EVP_MAC_provider() For information processing. 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-06-05 00:14:38 +08:00
{
return mac->prov;
}
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
const OSSL_PARAM *EVP_MAC_gettable_params(const EVP_MAC *mac)
{
if (mac->gettable_params == NULL)
return NULL;
Rename all getters to use get/get0 in name For functions that exist in 1.1.1 provide a simple aliases via #define. Fixes #15236 Functions with OSSL_DECODER_, OSSL_ENCODER_, OSSL_STORE_LOADER_, EVP_KEYEXCH_, EVP_KEM_, EVP_ASYM_CIPHER_, EVP_SIGNATURE_, EVP_KEYMGMT_, EVP_RAND_, EVP_MAC_, EVP_KDF_, EVP_PKEY_, EVP_MD_, and EVP_CIPHER_ prefixes are renamed. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15405)
2021-05-21 22:58:08 +08:00
return mac->gettable_params(ossl_provider_ctx(EVP_MAC_get0_provider(mac)));
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
}
Consistent naming for context gettable param queries . All instances of EVP_*_CTX_gettable_params functions have been renamed to EVP_*_gettable_ctx_params. Except for the EVP_MD ones which were changed already. These functions do not take EVP_*_CTX arguments so their prior naming was misleading. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10052)
2019-09-27 14:35:45 +08:00
const OSSL_PARAM *EVP_MAC_gettable_ctx_params(const EVP_MAC *mac)
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
{
evp: support modified gettable/settable ctx calls for MACs Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14240)
2021-02-23 09:03:49 +08:00
void *alg;
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
if (mac->gettable_ctx_params == NULL)
return NULL;
Rename all getters to use get/get0 in name For functions that exist in 1.1.1 provide a simple aliases via #define. Fixes #15236 Functions with OSSL_DECODER_, OSSL_ENCODER_, OSSL_STORE_LOADER_, EVP_KEYEXCH_, EVP_KEM_, EVP_ASYM_CIPHER_, EVP_SIGNATURE_, EVP_KEYMGMT_, EVP_RAND_, EVP_MAC_, EVP_KDF_, EVP_PKEY_, EVP_MD_, and EVP_CIPHER_ prefixes are renamed. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15405)
2021-05-21 22:58:08 +08:00
alg = ossl_provider_ctx(EVP_MAC_get0_provider(mac));
evp: support modified gettable/settable ctx calls for MACs Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14240)
2021-02-23 09:03:49 +08:00
return mac->gettable_ctx_params(NULL, alg);
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
}
Consistent naming for context gettable param queries . All instances of EVP_*_CTX_gettable_params functions have been renamed to EVP_*_gettable_ctx_params. Except for the EVP_MD ones which were changed already. These functions do not take EVP_*_CTX arguments so their prior naming was misleading. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10052)
2019-09-27 14:35:45 +08:00
const OSSL_PARAM *EVP_MAC_settable_ctx_params(const EVP_MAC *mac)
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
{
evp: support modified gettable/settable ctx calls for MACs Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14240)
2021-02-23 09:03:49 +08:00
void *alg;
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
if (mac->settable_ctx_params == NULL)
return NULL;
Rename all getters to use get/get0 in name For functions that exist in 1.1.1 provide a simple aliases via #define. Fixes #15236 Functions with OSSL_DECODER_, OSSL_ENCODER_, OSSL_STORE_LOADER_, EVP_KEYEXCH_, EVP_KEM_, EVP_ASYM_CIPHER_, EVP_SIGNATURE_, EVP_KEYMGMT_, EVP_RAND_, EVP_MAC_, EVP_KDF_, EVP_PKEY_, EVP_MD_, and EVP_CIPHER_ prefixes are renamed. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15405)
2021-05-21 22:58:08 +08:00
alg = ossl_provider_ctx(EVP_MAC_get0_provider(mac));
evp: support modified gettable/settable ctx calls for MACs Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14240)
2021-02-23 09:03:49 +08:00
return mac->settable_ctx_params(NULL, alg);
}
const OSSL_PARAM *EVP_MAC_CTX_gettable_params(EVP_MAC_CTX *ctx)
{
void *alg;
if (ctx->meth->gettable_ctx_params == NULL)
return NULL;
Rename all getters to use get/get0 in name For functions that exist in 1.1.1 provide a simple aliases via #define. Fixes #15236 Functions with OSSL_DECODER_, OSSL_ENCODER_, OSSL_STORE_LOADER_, EVP_KEYEXCH_, EVP_KEM_, EVP_ASYM_CIPHER_, EVP_SIGNATURE_, EVP_KEYMGMT_, EVP_RAND_, EVP_MAC_, EVP_KDF_, EVP_PKEY_, EVP_MD_, and EVP_CIPHER_ prefixes are renamed. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15405)
2021-05-21 22:58:08 +08:00
alg = ossl_provider_ctx(EVP_MAC_get0_provider(ctx->meth));
Rename the field 'provctx and data' to 'algctx' inside some objects containing pointers to provider size algorithm contexts. Fixes #14284 The gettable_ctx_params methods were confusingly passing a 'provctx' and a provider context which are completely different objects. Some objects such as EVP_KDF used 'data' while others such as EVP_MD used 'provctx'. For libcrypto this 'ctx' is an opaque ptr returned when a providers algorithm implementation creates an internal context using a new_ctx() method. Hence the new name 'algctx'. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15275)
2021-05-14 11:08:42 +08:00
return ctx->meth->gettable_ctx_params(ctx->algctx, alg);
evp: support modified gettable/settable ctx calls for MACs Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14240)
2021-02-23 09:03:49 +08:00
}
const OSSL_PARAM *EVP_MAC_CTX_settable_params(EVP_MAC_CTX *ctx)
{
void *alg;
if (ctx->meth->settable_ctx_params == NULL)
return NULL;
Rename all getters to use get/get0 in name For functions that exist in 1.1.1 provide a simple aliases via #define. Fixes #15236 Functions with OSSL_DECODER_, OSSL_ENCODER_, OSSL_STORE_LOADER_, EVP_KEYEXCH_, EVP_KEM_, EVP_ASYM_CIPHER_, EVP_SIGNATURE_, EVP_KEYMGMT_, EVP_RAND_, EVP_MAC_, EVP_KDF_, EVP_PKEY_, EVP_MD_, and EVP_CIPHER_ prefixes are renamed. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15405)
2021-05-21 22:58:08 +08:00
alg = ossl_provider_ctx(EVP_MAC_get0_provider(ctx->meth));
Rename the field 'provctx and data' to 'algctx' inside some objects containing pointers to provider size algorithm contexts. Fixes #14284 The gettable_ctx_params methods were confusingly passing a 'provctx' and a provider context which are completely different objects. Some objects such as EVP_KDF used 'data' while others such as EVP_MD used 'provctx'. For libcrypto this 'ctx' is an opaque ptr returned when a providers algorithm implementation creates an internal context using a new_ctx() method. Hence the new name 'algctx'. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15275)
2021-05-14 11:08:42 +08:00
return ctx->meth->settable_ctx_params(ctx->algctx, alg);
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
}
Implement EVP_MAC_do_all_ex() 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-06-05 00:17:49 +08:00
Rename OPENSSL_CTX prefix to OSSL_LIB_CTX Many of the new types introduced by OpenSSL 3.0 have an OSSL_ prefix, e.g., OSSL_CALLBACK, OSSL_PARAM, OSSL_ALGORITHM, OSSL_SERIALIZER. The OPENSSL_CTX type stands out a little by using a different prefix. For consistency reasons, this type is renamed to OSSL_LIB_CTX. Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12621)
2020-10-15 17:55:50 +08:00
void EVP_MAC_do_all_provided(OSSL_LIB_CTX *libctx,
EVP: add missing common functionality This adds the missing functions that should be common for all fetchable EVP sub-APIs: EVP_KEYMGMT_is_a(), EVP_KEYMGMT_do_all_provided(), EVP_KEYEXCH_is_a(), EVP_KEYEXCH_do_all_provided(), EVP_KDF_is_a(), EVP_MD_is_a(), EVP_SIGNATURE_do_all_provided(), EVP_SIGNATURE_is_a(). This also renames EVP_MD_do_all_ex(), EVP_CIPHER_do_all_ex(), EVP_KDF_do_all_ex(), EVP_MAC_do_all_ex() to change '_ex' to '_provided'. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9979)
2019-09-23 16:33:26 +08:00
void (*fn)(EVP_MAC *mac, void *arg),
void *arg)
Implement EVP_MAC_do_all_ex() 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-06-05 00:17:49 +08:00
{
evp_generic_do_all(libctx, OSSL_OP_MAC,
(void (*)(void *, void *))fn, arg,
Adapt all public EVP_XXX_do_all_provided() for the changed evp_generic_do_all() Fixes #15538 Fixes #14837 Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15604)
2021-06-09 13:52:09 +08:00
evp_mac_from_algorithm, evp_mac_up_ref, evp_mac_free);
Implement EVP_MAC_do_all_ex() 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-06-05 00:17:49 +08:00
}
Reference in New Issue Copy Permalink