OSSL_PARAMs

[Dr Paul Dale]

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 <levitte at openssl.org> 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         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190605/1582a2ab/attachment-0001.html>