Re: Thoughts on OSSL_ALGORITHM

2019-03-22 Thread Tim Hudson
"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

Re: Thoughts on OSSL_ALGORITHM

2019-03-22 Thread Dr Paul Dale
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

Re: Thoughts on OSSL_ALGORITHM

2019-03-22 Thread Matt Caswell
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

Thoughts on OSSL_ALGORITHM

2019-03-22 Thread 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