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 struc
On 22/03/2019 15:45, Matt Caswell wrote:
> 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.
I meant "An alternative is for the c
I’ve no issue having a provider data field there. It will be useful for more
than just this (S390 AES e.g. holds data differently to other implementations).
I also don’t think forcing separate functions is a big problem — most providers
will only implement one or two algorithm families which wi
"handle" is the wrong name for this - if you want to have private const
data then do that rather than something which might be abused for instance
specific information. It could just be an int even or a short. It doesn't
have to be a pointer.
That would reduce the likely of it being used to hold n
I also like the provider data approach.
-Ben
On Sat, Mar 23, 2019 at 09:11:23AM +1000, Dr Paul Dale wrote:
> I’ve no issue having a provider data field there. It will be useful for more
> than just this (S390 AES e.g. holds data differently to other
> implementations).
>
> I also don’t think
