OSSL_PARAMs

Wed Jun 5 02:47:56 UTC 2019

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 owner isn't interested
in the size (this is obviously the case when the OSSL_PARAM array is
to be used with a set_params type of call, but may also be true in a
get_params type of call if the owner knows the expected size through
some other means, such as a parameter being documented to *always* be
a 32-bit integer, or for a OSSL_PARAM_UTF8_STRING where the ending NUL
byte is always trustable)

But you're talking about allocating the whole OSSL_PARAM array on the
heap, aren't you?  While not structly opposed (even though I think
that's wasteful), I think this should be done with a separate set of
functions (intuitively, having names with '_alloc_' rather than
'_construct_' could be an idea).

> 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?
> 
> Pauli
> -- 
> 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 <paul.dale at oracle.com> 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/