Thoughts on OSSL_ALGORITHM

[Matt Caswell]

Currently we have the OSSL_ALGORITHM type defined as follows:

struct ossl_algorithm_st {
    const char *algorithm_name;      /* key */
    const char *property_definition; /* key */
    const OSSL_DISPATCH *implementation;
};

I'm wondering whether we should add an additional member to this structure: a
provider specific handle. i.e.

struct ossl_algorithm_st {
    const char *algorithm_name;      /* key */
    const char *property_definition; /* key */
    const OSSL_DISPATCH *implementation;
    void *handle;
};

The reason to do this is because providers are likely to want to share the same
implementation across multiple algorithms, e.g. the init/update/final functions
for aes-128-cbc are likely to look identical to aes-256-cbc with the only
difference being the key length. A provider could use the handle to point to
some provider side structure which describes the details of the algorithm (key
length, IV size etc). For example in the default provider we might have:

typedef struct default_alg_handle_st {
    int nid;
    size_t keylen;
    size_t ivlen;
} DEFAULT_ALG_HANDLE;

DEFAULT_ALG_HANDLE aes256cbchandle = { NID_aes_256_cbc, 32, 16 };
DEFAULT_ALG_HANDLE aes128cbchandle = { NID_aes_128_cbc, 16, 16 };

static const OSSL_ALGORITHM deflt_ciphers[] = {
    { "AES-256-CBC", "default=yes", aes_cbc_functions, &aes256cbchandle },
    { "AES-128-CBC", "default=yes", aes_cbc_functions, &aes128cbchandle },
    { NULL, NULL, NULL }
};

Then when the "init" function is called (or possibly at newctx), the core passes
as an argument the provider specific handle associated with that algorithm.

An alternative is for the provider to pass the algorithm name instead, but this
potentially requires lots of strcmps to identify which algorithm we're dealing
with which doesn't sound particularly attractive.

A second alternative is for each algorithm to always have unique functions
(which perhaps call some common functions underneath). This sounds like lots of
unnecessary redundancy.

Thoughts?

Matt