mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-11-27 05:21:51 +08:00
Code Issues Packages Projects Releases Wiki Activity
e0d952fccf
openssl/crypto/evp/mac_meth.c

215 lines
5.8 KiB
C
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
#include <openssl/evp.h>
#include <openssl/err.h>
#include <openssl/core.h>
#include <openssl/core_numbers.h>
Reorganize private crypto header files Currently, there are two different directories which contain internal header files of libcrypto which are meant to be shared internally: While header files in 'include/internal' are intended to be shared between libcrypto and libssl, the files in 'crypto/include/internal' are intended to be shared inside libcrypto only. To make things complicated, the include search path is set up in such a way that the directive #include "internal/file.h" could refer to a file in either of these two directoroes. This makes it necessary in some cases to add a '_int.h' suffix to some files to resolve this ambiguity: #include "internal/file.h" # located in 'include/internal' #include "internal/file_int.h" # located in 'crypto/include/internal' This commit moves the private crypto headers from 'crypto/include/internal' to 'include/crypto' As a result, the include directives become unambiguous #include "internal/file.h" # located in 'include/internal' #include "crypto/file.h" # located in 'include/crypto' hence the superfluous '_int.h' suffixes can be stripped. The files 'store_int.h' and 'store.h' need to be treated specially; they are joined into a single file. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9333)
2019-09-28 06:45:33 +08:00
#include "crypto/evp.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"
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;
CRYPTO_UP_REF(&mac->refcnt, &ref, mac->lock);
return 1;
}
static void evp_mac_free(void *vmac)
{
EVP_MAC *mac = vmac;
int ref = 0;
if (mac == NULL)
return;
CRYPTO_DOWN_REF(&mac->refcnt, &ref, mac->lock);
if (ref > 0)
return;
ossl_provider_free(mac->prov);
CRYPTO_THREAD_lock_free(mac->lock);
OPENSSL_free(mac);
}
static void *evp_mac_new(void)
{
EVP_MAC *mac = NULL;
if ((mac = OPENSSL_zalloc(sizeof(*mac))) == NULL
|| (mac->lock = CRYPTO_THREAD_lock_new()) == NULL) {
evp_mac_free(mac);
return NULL;
}
mac->refcnt = 1;
return mac;
}
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
static void *evp_mac_from_dispatch(int name_id,
const OSSL_DISPATCH *fns,
OSSL_PROVIDER *prov,
void *unused)
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) {
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
EVPerr(0, ERR_R_MALLOC_FAILURE);
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;
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;
mac->newctx = OSSL_get_OP_mac_newctx(fns);
fnctxcnt++;
break;
case OSSL_FUNC_MAC_DUPCTX:
if (mac->dupctx != NULL)
break;
mac->dupctx = OSSL_get_OP_mac_dupctx(fns);
break;
case OSSL_FUNC_MAC_FREECTX:
if (mac->freectx != NULL)
break;
mac->freectx = OSSL_get_OP_mac_freectx(fns);
fnctxcnt++;
break;
case OSSL_FUNC_MAC_INIT:
if (mac->init != NULL)
break;
mac->init = OSSL_get_OP_mac_init(fns);
fnmaccnt++;
break;
case OSSL_FUNC_MAC_UPDATE:
if (mac->update != NULL)
break;
mac->update = OSSL_get_OP_mac_update(fns);
fnmaccnt++;
break;
case OSSL_FUNC_MAC_FINAL:
if (mac->final != NULL)
break;
mac->final = OSSL_get_OP_mac_final(fns);
fnmaccnt++;
break;
case OSSL_FUNC_MAC_GETTABLE_PARAMS:
if (mac->gettable_params != NULL)
break;
mac->gettable_params =
OSSL_get_OP_mac_gettable_params(fns);
break;
case OSSL_FUNC_MAC_GETTABLE_CTX_PARAMS:
if (mac->gettable_ctx_params != NULL)
break;
mac->gettable_ctx_params =
OSSL_get_OP_mac_gettable_ctx_params(fns);
break;
case OSSL_FUNC_MAC_SETTABLE_CTX_PARAMS:
if (mac->settable_ctx_params != NULL)
break;
mac->settable_ctx_params =
OSSL_get_OP_mac_settable_ctx_params(fns);
break;
case OSSL_FUNC_MAC_GET_PARAMS:
if (mac->get_params != NULL)
break;
mac->get_params = OSSL_get_OP_mac_get_params(fns);
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;
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
mac->get_ctx_params = OSSL_get_OP_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;
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
mac->set_ctx_params = OSSL_get_OP_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;
}
EVP_MAC *EVP_MAC_fetch(OPENSSL_CTX *libctx, const char *algorithm,
const char *properties)
{
return evp_generic_fetch(libctx, OSSL_OP_MAC, algorithm, properties,
Refactor how KEYMGMT methods get associated with other methods KEYMGMT methods were attached to other methods after those were fully created and registered, thereby creating a potential data race, if two threads tried to create the exact same method at the same time. Instead of this, we change the method creating function to take an extra data parameter, passed all the way from the public fetching function. In the case of EVP_KEYEXCH, we pass all the necessary data that evp_keyexch_from_dispatch() needs to be able to fetch the appropriate KEYMGMT method on the fly. Fixes #9592 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9678)
2019-08-23 20:03:28 +08:00
evp_mac_from_dispatch, NULL, 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);
}
Modify providers that keep track of underlying algorithms With some provider implementations, there are underlying ciphers, digests and macs. For some of them, the name was retrieved from the method, but since the methods do not store those any more, we add different mechanics. For code that needs to pass on the name of a cipher or diges via parameters, we simply locally store the name that was used when fetching said cipher or digest. This will ensure that any underlying code that needs to fetch that same cipher or digest does so with the exact same name instead of any random name from the set of names associated with the algorithm. For code that needs to check what kind of algorithm was passed, we provide EVP_{type}_is_a(), that returns true if the given method has the given name as one of its names. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:35:08 +08:00
int EVP_MAC_is_a(const EVP_MAC *mac, const char *name)
{
return evp_is_a(mac->prov, mac->name_id, 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
const char *EVP_MAC_name(const EVP_MAC *mac)
{
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
return evp_first_name(mac->prov, mac->name_id);
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
}
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
const OSSL_PROVIDER *EVP_MAC_provider(const EVP_MAC *mac)
{
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;
return mac->gettable_params();
}
const OSSL_PARAM *EVP_MAC_CTX_gettable_params(const EVP_MAC *mac)
{
if (mac->gettable_ctx_params == NULL)
return NULL;
return mac->gettable_ctx_params();
}
const OSSL_PARAM *EVP_MAC_CTX_settable_params(const EVP_MAC *mac)
{
if (mac->settable_ctx_params == NULL)
return NULL;
return mac->settable_ctx_params();
}
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
void EVP_MAC_do_all_ex(OPENSSL_CTX *libctx,
void (*fn)(EVP_MAC *mac, void *arg),
void *arg)
{
evp_generic_do_all(libctx, OSSL_OP_MAC,
(void (*)(void *, void *))fn, arg,
Refactor how KEYMGMT methods get associated with other methods KEYMGMT methods were attached to other methods after those were fully created and registered, thereby creating a potential data race, if two threads tried to create the exact same method at the same time. Instead of this, we change the method creating function to take an extra data parameter, passed all the way from the public fetching function. In the case of EVP_KEYEXCH, we pass all the necessary data that evp_keyexch_from_dispatch() needs to be able to fetch the appropriate KEYMGMT method on the fly. Fixes #9592 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9678)
2019-08-23 20:03:28 +08:00
evp_mac_from_dispatch, NULL, 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