2019-02-09 00:01:56 +08:00
|
|
|
=pod
|
|
|
|
|
|
|
|
=head1 NAME
|
|
|
|
|
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
|
|
|
evp_generic_fetch, evp_generic_fetch_by_number
|
|
|
|
- generic algorithm fetchers and method creators for EVP
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
|
|
|
|
/* Only for EVP source */
|
2019-09-28 06:45:40 +08:00
|
|
|
#include "evp_local.h"
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
void *evp_generic_fetch(OPENSSL_CTX *libctx, int operation_id,
|
2019-05-05 14:42:21 +08:00
|
|
|
const char *name, const char *properties,
|
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
|
|
|
void *(*new_method)(int name_id,
|
2019-08-23 20:03:28 +08:00
|
|
|
const OSSL_DISPATCH *fns,
|
|
|
|
OSSL_PROVIDER *prov,
|
|
|
|
void *method_data),
|
|
|
|
void *method_data,
|
2019-07-02 20:57:36 +08:00
|
|
|
int (*up_ref_method)(void *),
|
2019-05-08 20:00:31 +08:00
|
|
|
void (*free_method)(void *));
|
2019-02-09 00:01:56 +08:00
|
|
|
|
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
|
|
|
void *evp_generic_fetch_by_number(OPENSSL_CTX *ctx, int operation_id,
|
|
|
|
int name_id, const char *properties,
|
|
|
|
void *(*new_method)(int name_id,
|
|
|
|
const OSSL_DISPATCH *fns,
|
|
|
|
OSSL_PROVIDER *prov,
|
|
|
|
void *method_data),
|
|
|
|
void *method_data,
|
|
|
|
int (*up_ref_method)(void *),
|
|
|
|
void (*free_method)(void *));
|
|
|
|
|
2019-02-09 00:01:56 +08:00
|
|
|
=head1 DESCRIPTION
|
|
|
|
|
|
|
|
evp_generic_fetch() calls ossl_method_construct() with the given
|
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
|
|
|
I<libctx>, I<operation_id>, I<name>, and I<properties> and uses
|
2019-02-09 00:01:56 +08:00
|
|
|
it to create an EVP method with the help of the functions
|
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
|
|
|
I<new_method>, I<up_ref_method>, and I<free_method>.
|
|
|
|
|
|
|
|
evp_generic_fetch_by_number() does the same thing as evp_generic_fetch(),
|
|
|
|
but takes a I<name_id> instead of a number.
|
2019-09-28 01:17:09 +08:00
|
|
|
I<name_id> must always be nonzero; as a matter of fact, it being zero
|
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
|
|
|
is considered a programming error.
|
|
|
|
This is meant to be used when one method needs to fetch an associated
|
|
|
|
other method, and is typically called from inside the given function
|
|
|
|
I<new_method>.
|
2019-02-09 00:01:56 +08:00
|
|
|
|
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
|
|
|
The three functions I<new_method>, I<up_ref_method>, and
|
|
|
|
I<free_method> are supposed to:
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item new_method()
|
|
|
|
|
|
|
|
creates an internal method from function pointers found in the
|
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
|
|
|
dispatch table I<fns>, with name identity I<name_id>.
|
|
|
|
The provider I<prov> and I<method_data> are also passed to be used as
|
|
|
|
new_method() sees fit.
|
2019-02-09 00:01:56 +08:00
|
|
|
|
2019-07-02 20:57:36 +08:00
|
|
|
=item up_ref_method()
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
increments the reference counter for the given method, if there is
|
|
|
|
one.
|
|
|
|
|
|
|
|
=item free_method()
|
|
|
|
|
|
|
|
frees the given method.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=head1 RETURN VALUES
|
|
|
|
|
2019-09-27 19:26:22 +08:00
|
|
|
evp_generic_fetch() returns a method on success, or NULL on error.
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
=head1 EXAMPLES
|
|
|
|
|
|
|
|
This is a short example of the fictitious EVP API and operation called
|
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
|
|
|
B<EVP_FOO>.
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
To begin with, let's assume something like this in
|
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
|
|
|
F<include/openssl/core_numbers.h>:
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
#define OSSL_OP_FOO 100
|
|
|
|
|
|
|
|
#define OSSL_OP_FOO_NEWCTX_FUNC 2001
|
|
|
|
#define OSSL_OP_FOO_INIT 2002
|
|
|
|
#define OSSL_OP_FOO_OPERATE 2003
|
|
|
|
#define OSSL_OP_FOO_CLEANCTX_FUNC 2004
|
|
|
|
#define OSSL_OP_FOO_FREECTX_FUNC 2005
|
|
|
|
OSSL_CORE_MAKE_FUNC(void *,OP_foo_newctx,(void))
|
|
|
|
OSSL_CORE_MAKE_FUNC(int,OP_foo_init,(void *vctx))
|
|
|
|
OSSL_CORE_MAKE_FUNC(int,OP_foo_operate,(void *vctx,
|
|
|
|
unsigned char *out, size_t *out_l,
|
|
|
|
unsigned char *in, size_t in_l))
|
|
|
|
OSSL_CORE_MAKE_FUNC(void,OP_foo_cleanctx,(void *vctx))
|
|
|
|
OSSL_CORE_MAKE_FUNC(void,OP_foo_freectx,(void *vctx))
|
|
|
|
|
|
|
|
And here's the implementation of the FOO method fetcher:
|
|
|
|
|
|
|
|
/* typedef struct evp_foo_st EVP_FOO */
|
|
|
|
struct evp_foo_st {
|
|
|
|
OSSL_PROVIDER *prov;
|
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
|
|
|
int name_id;
|
2019-02-09 00:01:56 +08:00
|
|
|
CRYPTO_REF_COUNT refcnt;
|
|
|
|
OSSL_OP_foo_newctx_fn *newctx;
|
|
|
|
OSSL_OP_foo_init_fn *init;
|
|
|
|
OSSL_OP_foo_operate_fn *operate;
|
|
|
|
OSSL_OP_foo_cleanctx_fn *cleanctx;
|
|
|
|
OSSL_OP_foo_freectx_fn *freectx;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In this example, we have a public method creator and destructor.
|
|
|
|
* It's not absolutely necessary, but is in the spirit of OpenSSL.
|
|
|
|
*/
|
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
|
|
|
EVP_FOO *EVP_FOO_meth_from_dispatch(int name_id,
|
|
|
|
const OSSL_DISPATCH *fns,
|
|
|
|
OSSL_PROVIDER *prov,
|
|
|
|
void *data)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
|
|
|
EVP_FOO *foo = NULL;
|
|
|
|
|
|
|
|
if ((foo = OPENSSL_zalloc(sizeof(*foo))) == NULL)
|
|
|
|
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
|
|
|
foo->name_id = name_id;
|
|
|
|
|
2019-02-09 00:01:56 +08:00
|
|
|
for (; fns->function_id != 0; fns++) {
|
|
|
|
switch (fns->function_id) {
|
|
|
|
case OSSL_OP_FOO_NEWCTX_FUNC:
|
|
|
|
foo->newctx = OSSL_get_OP_foo_newctx(fns);
|
|
|
|
break;
|
|
|
|
case OSSL_OP_FOO_INIT:
|
|
|
|
foo->init = OSSL_get_OP_foo_init(fns);
|
|
|
|
break;
|
|
|
|
case OSSL_OP_FOO_OPERATE:
|
|
|
|
foo->operate = OSSL_get_OP_foo_operate(fns);
|
|
|
|
break;
|
|
|
|
case OSSL_OP_FOO_CLEANCTX_FUNC:
|
|
|
|
foo->cleanctx = OSSL_get_OP_foo_cleanctx(fns);
|
|
|
|
break;
|
|
|
|
case OSSL_OP_FOO_FREECTX_FUNC:
|
|
|
|
foo->freectx = OSSL_get_OP_foo_freectx(fns);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
foo->prov = prov;
|
|
|
|
if (prov)
|
2019-07-02 20:57:36 +08:00
|
|
|
ossl_provider_up_ref(prov);
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
return foo;
|
|
|
|
}
|
|
|
|
|
|
|
|
EVP_FOO_meth_free(EVP_FOO *foo)
|
|
|
|
{
|
|
|
|
if (foo != NULL) {
|
|
|
|
OSSL_PROVIDER *prov = foo->prov;
|
|
|
|
|
|
|
|
OPENSSL_free(foo);
|
|
|
|
ossl_provider_free(prov);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-05-08 20:00:31 +08:00
|
|
|
static void *foo_from_dispatch(const OSSL_DISPATCH *fns,
|
2019-02-09 00:01:56 +08:00
|
|
|
OSSL_PROVIDER *prov)
|
|
|
|
{
|
2019-05-08 20:00:31 +08:00
|
|
|
return EVP_FOO_meth_from_dispatch(fns, prov);
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
2019-07-02 20:57:36 +08:00
|
|
|
static int foo_up_ref(void *vfoo)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
|
|
|
EVP_FOO *foo = vfoo;
|
|
|
|
int ref = 0;
|
|
|
|
|
|
|
|
CRYPTO_UP_REF(&foo->refcnt, &ref, foo_lock);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void foo_free(void *vfoo)
|
|
|
|
{
|
|
|
|
EVP_FOO_meth_free(vfoo);
|
|
|
|
}
|
|
|
|
|
|
|
|
EVP_FOO *EVP_FOO_fetch(OPENSSL_CTX *ctx,
|
2019-05-05 14:42:21 +08:00
|
|
|
const char *name,
|
2019-02-09 00:01:56 +08:00
|
|
|
const char *properties)
|
|
|
|
{
|
2019-05-08 20:00:31 +08:00
|
|
|
EVP_FOO *foo =
|
|
|
|
evp_generic_fetch(ctx, OSSL_OP_FOO, name, properties,
|
2019-07-02 20:57:36 +08:00
|
|
|
foo_from_dispatch, foo_up_ref, foo_free);
|
2019-05-08 20:00:31 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If this method exists in legacy form, with a constant NID for the
|
|
|
|
* given |name|, this is the spot to find that NID and set it in
|
|
|
|
* the newly constructed EVP_FOO instance.
|
|
|
|
*/
|
|
|
|
|
|
|
|
return foo;
|
|
|
|
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
And finally, the library functions:
|
|
|
|
|
|
|
|
/* typedef struct evp_foo_st EVP_FOO_CTX */
|
|
|
|
struct evp_foo_ctx_st {
|
|
|
|
const EVP_FOO *foo;
|
|
|
|
void *provctx; /* corresponding provider context */
|
|
|
|
};
|
|
|
|
|
|
|
|
int EVP_FOO_CTX_reset(EVP_FOO_CTX *c)
|
|
|
|
{
|
|
|
|
if (c == NULL)
|
|
|
|
return 1;
|
|
|
|
if (c->foo != NULL && c->foo->cleanctx != NULL)
|
|
|
|
c->foo->cleanctx(c->provctx);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
EVP_FOO_CTX *EVP_FOO_CTX_new(void)
|
|
|
|
{
|
|
|
|
return OPENSSL_zalloc(sizeof(EVP_FOO_CTX));
|
|
|
|
}
|
|
|
|
|
|
|
|
void EVP_FOO_CTX_free(EVP_FOO_CTX *c)
|
|
|
|
{
|
|
|
|
EVP_FOO_CTX_reset(c);
|
|
|
|
c->foo->freectx(c->provctx);
|
|
|
|
OPENSSL_free(c);
|
|
|
|
}
|
|
|
|
|
|
|
|
int EVP_FooInit(EVP_FOO_CTX *c, const EVP_FOO *foo)
|
|
|
|
{
|
|
|
|
int ok = 1;
|
|
|
|
|
|
|
|
c->foo = foo;
|
|
|
|
if (c->provctx == NULL)
|
|
|
|
c->provctx = c->foo->newctx();
|
|
|
|
|
|
|
|
ok = c->foo->init(c->provctx);
|
|
|
|
|
|
|
|
return ok;
|
|
|
|
}
|
|
|
|
|
|
|
|
int EVP_FooOperate(EVP_FOO_CTX *c, unsigned char *out, size_t *outl,
|
|
|
|
const unsigned char *in, size_t inl)
|
|
|
|
{
|
|
|
|
int ok = 1;
|
|
|
|
|
|
|
|
ok = c->foo->update(c->provctx, out, inl, &outl, in, inl);
|
|
|
|
return ok;
|
|
|
|
}
|
|
|
|
|
|
|
|
=head1 SEE ALSO
|
|
|
|
|
2019-10-05 05:09:19 +08:00
|
|
|
L<ossl_method_construct(3)>
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
=head1 HISTORY
|
|
|
|
|
|
|
|
The functions described here were all added in OpenSSL 3.0.
|
|
|
|
|
|
|
|
=head1 COPYRIGHT
|
|
|
|
|
|
|
|
Copyright 2019 The OpenSSL Project Authors. All Rights Reserved.
|
|
|
|
|
|
|
|
Licensed under the Apache License 2.0 (the "License"). You may not use
|
|
|
|
this file except in compliance with the License. You can obtain a copy
|
|
|
|
in the file LICENSE in the source distribution or at
|
|
|
|
L<https://www.openssl.org/source/license.html>.
|
|
|
|
|
|
|
|
=cut
|