Re: OSSL_PARAMs

2019-06-05 Thread Richard Levitte
On Wed, 05 Jun 2019 03:17:25 +0200, Salz, Rich wrote: > > > * Is this workable or should something more significantly different be used > before things freeze > with the 3.0 release? > > Well, since you asked: https://github.com/openssl/openssl/pull/8377 For the record, I'm opposed to

Re: OSSL_PARAMs

2019-06-05 Thread Salz, Rich
* Is this workable or should something more significantly different be used before things freeze with the 3.0 release? Well, since you asked: https://github.com/openssl/openssl/pull/8377

Re: OSSL_PARAMs

2019-06-05 Thread Richard Levitte
ly possible to do this today. We already have > this pointer, it's called 'data’. > > And how is a pointer known to be malloced or not? I’m trying to make this > easy for users without > losing the efficiency that is possible if it is required somewhere. > > I’m lo

Re: OSSL_PARAMs

2019-06-04 Thread Dr Paul Dale
t allow this construct: >> >>int foo(whatever) >>{ >>int haha = 0; >>const OSSL_PARAM params[] = { >>{ 'foo', OSSL_PARAM_INTEGER, , sizeof(haha), NULL }, >>{ NULL, 0, NULL, 0, NULL } >> }; >> >&g

Re: OSSL_PARAMs

2019-06-04 Thread Dr Paul Dale
-- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 5 Jun 2019, at 12:47 pm, Richard Levitte wrote: > But you're talking about allocating the whole OSSL_PARAM array on the > heap, aren't you? While not structly opposed (even though

Re: OSSL_PARAMs

2019-06-04 Thread Dr Paul Dale
called 'data’. And how is a pointer known to be malloced or not? I’m trying to make this easy for users without losing the efficiency that is possible if it is required somewhere. I’m looking at making this kind of code work: OSSL_PARAMS params[10]; int n = 0, max_len; char my_size[20];

Re: OSSL_PARAMs

2019-06-04 Thread SHANE LONTIS
, sizeof(haha), NULL }, >{ NULL, 0, NULL, 0, NULL } >}; > >... >} > The above code is great in theory, but it looks like in practice we end up dynamically allocating in most cases anyway (via the construct_ methods). And if this is the normal use c

Re: OSSL_PARAMs

2019-06-04 Thread Richard Levitte
On Wed, 05 Jun 2019 03:11:57 +0200, Dr Paul Dale wrote: > > > For a minimally invasive change, the various OSSL_PARAM_construct_ calls > could be modified to > allocate space for the parameter and its return size if NULL is passed for > either. If NULL is passed as return_size, it means the

Re: OSSL_PARAMs

2019-06-04 Thread Richard Levitte
I assume you're talking about the |return_size| indirection here. I think you will see much more of them as soon as the asymmetric algorithms start to show up, as they should naturally contain get_params functionality for the numbers of the key objects. For the moment being, we aren't seeing much

Re: OSSL_PARAMs

2019-06-04 Thread Richard Levitte
Aside from the discussion below, if there's one thing I would like to change, it the double indirection for the _PTR data types. The data types could still be used to indicate that the value isn't short lived, but could possibly change names to something like OSSL_PARAM_UTF8_CSTRING and

Re: OSSL_PARAMs

2019-06-04 Thread Dr Paul Dale
For a minimally invasive change, the various OSSL_PARAM_construct_ calls could be modified to allocate space for the parameter and its return size if NULL is passed for either. There would need to be some indication of this and a cleanup array call. Done properly, this would permit the same

Re: OSSL_PARAMs

2019-06-04 Thread Dr Paul Dale
I thought the references were to allow const arrays of OSSL_PARAM to be viable. A quick check through the code reveals these in test and doc only. There are two instances of OSSL_PARAM arrays being declared in evp, both add the pointed to variable after creation, both only have two elements

Re: OSSL_PARAMs

2019-06-04 Thread SHANE LONTIS
I presume the reference approach was used to solve the issue of who actually owns/free's the data. > On 5 Jun 2019, at 9:18 am, Dr Paul Dale wrote: > > Shane’s major complaints are about the indirection the OSSL_PARAM structure > forces — for integers and return lengths and the necessity of

Re: OSSL_PARAMs

2019-06-04 Thread Richard Levitte
On Tue, 04 Jun 2019 14:57:00 +0200, Salz, Rich wrote: > > > >Part of the idea was that this would be a means of communication > between application and provider, just like controls are with > libcrypto sub-systems. > > > I can probably find the email thread (or maybe it was a

Re: OSSL_PARAMs

2019-06-04 Thread Salz, Rich
>Part of the idea was that this would be a means of communication between application and provider, just like controls are with libcrypto sub-systems. I can probably find the email thread (or maybe it was a GitHub comment on my proposal for params), where you said, quite

Re: OSSL_PARAMs

2019-06-04 Thread Richard Levitte
Part of the idea was that this would be a means of communication between application and provider, just like controls are with libcrypto sub-systems. The main differences are that we aren't stuck with the limitations of the control functions, that the interface is uniform (if you look at the

Re: OSSL_PARAMs

2019-06-04 Thread SHANE LONTIS
The controls are easier to understand and use currently. The advantage of params is that you can batch them, so that the order no longer matters during setup (e.g- I need to set EVP_MD first). The params are not being used in anger yet. My main problem with the params is that no data is set into

OSSL_PARAMs

2019-06-04 Thread Dr Paul Dale
A question for the committers and beyond. Should the OSSL_PARAM concept be used for more than just the libcrypto ⇿ provider interface? The one that springs to mind is a more general form of the various ctrl calls, there are some string ctrl calls that attempt to do the same thing in a less