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 efficiency on the owner’s side but 
would also simplify OSSL_PARAM array creation for those who aren’t as concerned.
The theoretical const array of OSSL_PARAM would still be possible.

Is this workable or should something more significantly different be used 
before things freeze with the 3.0 release?

Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

> On 5 Jun 2019, at 10:50 am, Dr Paul Dale <> wrote:
> 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 (the integer 
> and the terminator) and both are stack allocated.  I.e. there is currently is 
> no example of the use case for which the indirection is present :(
> Pauli
> -- 
> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> Phone +61 7 3031 7217
> Oracle Australia
>> On 5 Jun 2019, at 10:31 am, SHANE LONTIS < 
>> <>> wrote:
>> 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 allocating 
>>> additional memory in parallel with the OSSL_PARAM.
>>> The extra indirection was intended to support const arrays of OSSL_PARAM, 
>>> which turn out to be a rarity because they aren’t thread safe.  With most 
>>> OSSL_PARAM structure being dynamically created, the need for the 
>>> indirection seems redundant.  E.g. could the return length be moved into 
>>> OSSL_PARAM?  I think so.
>>> Moving integral values into the structure is more difficult because BIGNUMs 
>>> will always need to be references.  Allocating additional memory will still 
>>> be required.  I’ve got three obvious solutions:
>>> 1. include a void * in the OSSL_PARAM structure that needs to be freed when 
>>> the structure is destroyed or
>>> 2. have a block of data in the OSSL_PARAM structure that can be used for 
>>> native types (OSSL_UNION_ALIGN works perfectly for this) or
>>> 3. add a flag field to the OSSL_PARAM to indicate that the referenced value 
>>> needs to be freed.
>>> The memory allocation comes to the for when reading e.g. a file and 
>>> extracting data — either the reader needs a lot of local variables to hold 
>>> everything or it has to allocated for each.  The file’s data is transient 
>>> in memory.
>>> For the most part, the receiver side APIs seem reasonable.  It is the 
>>> owning side that has the complications.
>>> I think I might be able come up with some owner side routines that assist 
>>> here but allowing changes to the params structure would be far easier.
>>> I kind of like using the OSSL_PARAM arrays as a replacement for string ctrl 
>>> functions if not ctrl as well (subject to backward compatibility concerns).
>>> Pauli
>>> -- 
>>> Dr Paul Dale | Cryptographer | Network Security & Encryption 
>>> Phone +61 7 3031 7217
>>> Oracle Australia
>>>> On 4 Jun 2019, at 11:26 pm, Richard Levitte < 
>>>> <>> wrote:
>>>> 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 GitHub
>>>>> comment on my proposal for params), where you said, quite
>>>>> definitively, that this was *not* a general-purpose mechanism but
>>>>> rather a way to expose the necessary internals for opaque objects
>>>>> like RSA keys.
>>>> Either I misunderstood what you said at the time, or you misunderstood
>>>> what I said...  there's definitely a disconnect here somewhere.
>>>> What I wonder is why it should be exclusively only one of those
>>>> options?
>>>> Either way, the OSSL_PARAM is defined publically and openly (i.e.
>>>> non-opaque), and we currently have the following functions in the
>>>> public API:
>>>>    EVP_MD_CTX_set_params
>>>>    EVP_MD_CTX_get_params
>>>>    OSSL_PROVIDER_get_params
>>>> I fully expect that more will come.  I have a branch where I've
>>>> EVP_MAC_CTX_set_params, for example, and I wouldn't be surprised if
>>>> EVP_CIPHER_CTX_set_params and EVP_CIPHER_CTX_get_params appear before
>>>> long (I'm actually rather surprised they haven't already), and I'm
>>>> absolutely sure we will see similar functions for asymmetric
>>>> algorithms.
>>>>> What changed your mind?
>>>>> Perhaps not surprisingly, I agree with Shane's assessment and am
>>>>> strongly opposed to the project foisting this on everyone at this
>>>>> time.  @DavidBen, your thoughts?
>>>> Maybe we're reading differently, I didn't see Shane being opposed to
>>>> parameter passing in this way per se, just the exact form of the
>>>> OSSL_PARAM structure, which is different.
>>>> Cheers,
>>>> Richard
>>>> -- 
>>>> Richard Levitte <>
>>>> OpenSSL Project 
>>>> <>

Reply via email to