OSSL_PARAMs

[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 of that kind of functionality.

Cheers,
Richard

On Wed, 05 Jun 2019 02:50:07 +0200,
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 <shane.lontis at oracle.com> 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 <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> 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/
> 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/