OSSL_PARAMs

[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 <paul.dale at oracle.com> 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 <levitte at openssl.org <mailto: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 <mailto:levitte at openssl.org>
>> OpenSSL Project         http://www.openssl.org/~levitte/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openssl.org_-7Elevitte_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=b1aL1L-m41VGkedIk-9Q7taAEKIshTBwq95Iah07uCk&m=ngbUohXK9OQMcC6T1S9Xvhy8OvC7dSslJ9RwAfHWnek&s=pbKG4wSDo_zd6yyp8bCPGDKXxFbG0-M5B4SRDEB-XA4&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190605/c57c52fe/attachment.html>