Re: OSSL_PARAMs

[Richard Levitte]

On Wed, 05 Jun 2019 05:07:24 +0200,
Dr Paul Dale wrote:
> 
> 
> Richard wrote:
> 
> 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.
> 
> The design was not only to be able to have nice compile time
> initialization, but also to be able to pass the array as 'const
> OSSL_PARAM *', i.e. an indication to the recipient that the array
> itself should never be modified (less chance of compromise).  Maybe
> that's overly paranoid, but that was a line of thinking.
> 
> This is a better reason, not that I think “const” is all that useful here.
> 
> An aside: having a const struct that has a pointer to non-const memory isn’t 
> entirely obvious to
> many.  This is a public API, make it as simple as necessary.

Surely, this can be alleviated with a comment or appropriate documentation?

> 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
> 
> It's actually perfectly possible to do this today.  We already have
> this pointer, it's called 'data’.
> 
> And how is a pointer known to be malloced or not?  I’m trying to make this 
> easy for users without
> losing the efficiency that is possible if it is required somewhere.
> 
> I’m looking at making this kind of code work:
> 
> OSSL_PARAMS params[10];
> int n = 0, max_len;
> char my_size[20];
>
> scanf(“%d”, &max_len);
> params[n++] = OSSL_PARAM_construct_utf8_string(“size”, &my_size, 
> sizeof(my_size), NULL);
> params[n++] = OSSL_PARAM_construct_utf8_string(“name”, NULL, max_len, 
> NULL);
> params[n++] = OSSL_PARAM_construct_end();
>
> …
>
> OSSL_PARAM_deconstruct_all(params);

Well, going along with the idea of having a separate set of functions
called something with '_alloc_' instead of '_construct_', I could
imagine an interface like this:

OSSL_PARAM OSSL_PARAM_alloc_utf8_string(const char *name,
void **buf, size_t bufsize,
size_t *return_size);

That would allow the OSSL_PARAM array owner to keep track of allocated
data by passsing in the address to a pointer, and deallocate what
needs to be deallocated after the fact.  Or in other words:

OSSL_PARAMS params[10];
int n = 0, max_len;
char my_size[20];
void *namebuf = NULL;
   
scanf(“%d”, &max_len);
params[n++] = OSSL_PARAM_construct_utf8_string(“size”, &my_size, 
sizeof(my_size), NULL);
params[n++] = OSSL_PARAM_alloc_utf8_string(“name”, &namebuf, max_len, NULL);
params[n++] = OSSL_PARAM_construct_end();
   
…
   
OPENSSL_free(namebuf);

> It is a contrived case but I think it would make using the params easier.

Not at all contrived, I can see uses for it, but then rather for the
get_params kind of call.

> 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
> 
> My major concern with that, apart from having to modify the OSSL_PARAM
> items themselves¸ is that some time in the future, we will want to add
> another native type that's larger, which means we modify the size of a
> OSSL_PARAM.  It's a public structure, so that can't be treated
> lightly.
> 
> This is a valid concern.  OSSL_UNION_ALIGN isn’t appropriate.
> Likewise, uintmax_t isn’t binary compatible.

I'm glad we agree.

> If you're thinking that the receiving side should free certain values,
> then you need to pass a pointer to the routine to be used to free the
> value rather than just a flag.
> 
> I agree, this is a bad idea.  
> 
> The API isn’t easy to use at the moment.  It is also error prone as soon as 
> something complex is
> encountered (which we haven’t yet).
> Shane struggled to figure this out and get it working when trying the KDFs 
> and he is far more
> experienced than most.

I have had some experience with the MACs...

> I’ll see if I can get some kind of diff or PR together.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OSSL_PARAMs

[Dr Paul Dale]

The OSSL_PARAM structure needs to be visible and not subject to change.
Providers shouldn’t necessarily have a dependency on functions from libcrypto.


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



> On 5 Jun 2019, at 12:47 pm, SHANE LONTIS  wrote:
> 
> 
> 
>> On 5 Jun 2019, at 12:34 pm, Richard Levitte > > wrote:
>> 
>> Aside from the discussion below, if there's one thing I would like to
>> change, it the double indirection for the _PTR data types.  The data
>> types could still be used to indicate that the value isn't short
>> lived, but could possibly change names to something like
>> OSSL_PARAM_UTF8_CSTRING and OSSL_PARAM_OCTET_CSTRING (C for Constant).
>> 
>> On Wed, 05 Jun 2019 01:18:56 +0200,
>> 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.
>> 
>> The reason why we have this issue is our base C language version
>> choice.  C90 doesn't allow this construct:
>> 
>>int foo(whatever)
>>{
>>int haha = 0;
>>const OSSL_PARAM params[] = {
>>{ 'foo', OSSL_PARAM_INTEGER, &haha, sizeof(haha), NULL },
>>{ NULL, 0, NULL, 0, NULL }
>>};
>> 
>>...
>>}
>> 
> The above code is great in theory, but it looks like in practice we end up 
> dynamically allocating in most cases anyway (via the construct_ methods).
> And if this is the normal use case then OSSL_PARAMS could be made opaque and 
> only accessed by API’s, then the argument about adding
> extra types later on should also disappear?
> 
> 
>> Because the compiler for that language version isn't allowed to emit
>> code to use '&haha' in an inititializer.  Newer C language versions
>> allow this.
>> 
>> So while this is an issue for *us*, it isn't necessarily an issue for
>> our users, all depending on what C language version they use.
>> 
>>> 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.
>> 
>> The design was not only to be able to have nice compile time
>> initialization, but also to be able to pass the array as 'const
>> OSSL_PARAM *', i.e. an indication to the recipient that the array
>> itself should never be modified (less chance of compromise).  Maybe
>> that's overly paranoid, but that was a line of thinking.
>> 
>>> 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
>> 
>> It's actually perfectly possible to do this today.  We already have
>> this pointer, it's called 'data'.
>> 
>>> 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
>> 
>> My major concern with that, apart from having to modify the OSSL_PARAM
>> items themselves¸ is that some time in the future, we will want to add
>> another native type that's larger, which means we modify the size of a
>> OSSL_PARAM.  It's a public structure, so that can't be treated
>> lightly.
>> 
>> Also, with a union of native types, we're losing uniformity on MSB
>> first platforms.  Having an exact 1:1 integer size match will be
>> crucial, and that complicates the code quite a bit...  not to mention
>> that we have a compatibility problem as soon as one end has a new
>> native type in the union and the other doesn't.
>> (one would imagine that simply using uintmax_t would cover all integer
>> sizes apart from BIGNUM, but the potential size change of that type
>> with newer compilers make such a choice precarious)
>> 
>>> 3. add a flag field to the OSSL_PARAM to indicate that the referenced value 
>>> needs to be freed.
>> 
>> By whom?  The owner of the array should be in complete control of
>> what's needed already, so should be able to know what needs being
>> deallocated or not.
>> 
>> If you're thinking that the receiving side should free certain values,
>> then you need to pass a pointer to the routine to be used to free the
>> value rather than just a flag.
>> 
>>> 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 
>>>

Re: OSSL_PARAMs

[Dr Paul Dale]

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



> On 5 Jun 2019, at 12:47 pm, Richard Levitte  wrote:

> 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).

Not the whole OSSL_PARAM array, just the data pointed to by (some) of the 
elements of one.
_alloc_ instead of _construct_ makes sense and is better than NULL.

I’m fine with `OSSL_PARAM params[20]` in code and filling as many slots as 
desired.

To do entirely heap allocated arrays, we’d want to go via a stack (which is 
something we shouldn’t require providers to depend on) or use a linked list of 
some kind.


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

Re: OSSL_PARAMs

[Dr Paul Dale]

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



> So while this is an issue for *us*, it isn't necessarily an issue for
> our users, all depending on what C language version they use.

Supporting things *we* can’t use seems a little odd.  The alternative 
construction is about as onerous (the construct calls).  On stack arrays won’t 
provide much performance benefit.  Static arrays would but without thread 
safety.


>> 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.
> 
> The design was not only to be able to have nice compile time
> initialization, but also to be able to pass the array as 'const
> OSSL_PARAM *', i.e. an indication to the recipient that the array
> itself should never be modified (less chance of compromise).  Maybe
> that's overly paranoid, but that was a line of thinking.

This is a better reason, not that I think “const” is all that useful here.

An aside: having a const struct that has a pointer to non-const memory isn’t 
entirely obvious to many.  This is a public API, make it as simple as necessary.


>> 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
> 
> It's actually perfectly possible to do this today.  We already have
> this pointer, it's called 'data’.

And how is a pointer known to be malloced or not?  I’m trying to make this easy 
for users without losing the efficiency that is possible if it is required 
somewhere.

I’m looking at making this kind of code work:

OSSL_PARAMS params[10];
int n = 0, max_len;
char my_size[20];

scanf(“%d”, &max_len);
params[n++] = OSSL_PARAM_construct_utf8_string(“size”, &my_size, 
sizeof(my_size), NULL);
params[n++] = OSSL_PARAM_construct_utf8_string(“name”, NULL, max_len, NULL);
params[n++] = OSSL_PARAM_construct_end();

…

OSSL_PARAM_deconstruct_all(params);

It is a contrived case but I think it would make using the params easier.


>> 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
> 
> My major concern with that, apart from having to modify the OSSL_PARAM
> items themselves¸ is that some time in the future, we will want to add
> another native type that's larger, which means we modify the size of a
> OSSL_PARAM.  It's a public structure, so that can't be treated
> lightly.

This is a valid concern.  OSSL_UNION_ALIGN isn’t appropriate.
Likewise, uintmax_t isn’t binary compatible.


> If you're thinking that the receiving side should free certain values,
> then you need to pass a pointer to the routine to be used to free the
> value rather than just a flag.

I agree, this is a bad idea.  

The API isn’t easy to use at the moment.  It is also error prone as soon as 
something complex is encountered (which we haven’t yet).
Shane struggled to figure this out and get it working when trying the KDFs and 
he is far more experienced than most.


I’ll see if I can get some kind of diff or PR together.


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

Re: OSSL_PARAMs

[SHANE LONTIS]

> On 5 Jun 2019, at 12:34 pm, Richard Levitte  wrote:
> 
> Aside from the discussion below, if there's one thing I would like to
> change, it the double indirection for the _PTR data types.  The data
> types could still be used to indicate that the value isn't short
> lived, but could possibly change names to something like
> OSSL_PARAM_UTF8_CSTRING and OSSL_PARAM_OCTET_CSTRING (C for Constant).
> 
> On Wed, 05 Jun 2019 01:18:56 +0200,
> 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.
> 
> The reason why we have this issue is our base C language version
> choice.  C90 doesn't allow this construct:
> 
>int foo(whatever)
>{
>int haha = 0;
>const OSSL_PARAM params[] = {
>{ 'foo', OSSL_PARAM_INTEGER, &haha, sizeof(haha), NULL },
>{ NULL, 0, NULL, 0, NULL }
>};
> 
>...
>}
> 
The above code is great in theory, but it looks like in practice we end up 
dynamically allocating in most cases anyway (via the construct_ methods).
And if this is the normal use case then OSSL_PARAMS could be made opaque and 
only accessed by API’s, then the argument about adding
extra types later on should also disappear?


> Because the compiler for that language version isn't allowed to emit
> code to use '&haha' in an inititializer.  Newer C language versions
> allow this.
> 
> So while this is an issue for *us*, it isn't necessarily an issue for
> our users, all depending on what C language version they use.
> 
>> 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.
> 
> The design was not only to be able to have nice compile time
> initialization, but also to be able to pass the array as 'const
> OSSL_PARAM *', i.e. an indication to the recipient that the array
> itself should never be modified (less chance of compromise).  Maybe
> that's overly paranoid, but that was a line of thinking.
> 
>> 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
> 
> It's actually perfectly possible to do this today.  We already have
> this pointer, it's called 'data'.
> 
>> 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
> 
> My major concern with that, apart from having to modify the OSSL_PARAM
> items themselves¸ is that some time in the future, we will want to add
> another native type that's larger, which means we modify the size of a
> OSSL_PARAM.  It's a public structure, so that can't be treated
> lightly.
> 
> Also, with a union of native types, we're losing uniformity on MSB
> first platforms.  Having an exact 1:1 integer size match will be
> crucial, and that complicates the code quite a bit...  not to mention
> that we have a compatibility problem as soon as one end has a new
> native type in the union and the other doesn't.
> (one would imagine that simply using uintmax_t would cover all integer
> sizes apart from BIGNUM, but the potential size change of that type
> with newer compilers make such a choice precarious)
> 
>> 3. add a flag field to the OSSL_PARAM to indicate that the referenced value 
>> needs to be freed.
> 
> By whom?  The owner of the array should be in complete control of
> what's needed already, so should be able to know what needs being
> deallocated or not.
> 
> If you're thinking that the receiving side should free certain values,
> then you need to pass a pointer to the routine to be used to free the
> value rather than just a flag.
> 
>> 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

Re: OSSL_PARAMs

[Richard Levitte]

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  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:
>
> O

Re: 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  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

Re: OSSL_PARAMs

[Richard Levitte]

Aside from the discussion below, if there's one thing I would like to
change, it the double indirection for the _PTR data types.  The data
types could still be used to indicate that the value isn't short
lived, but could possibly change names to something like
OSSL_PARAM_UTF8_CSTRING and OSSL_PARAM_OCTET_CSTRING (C for Constant).

On Wed, 05 Jun 2019 01:18:56 +0200,
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.

The reason why we have this issue is our base C language version
choice.  C90 doesn't allow this construct:

int foo(whatever)
{
int haha = 0;
const OSSL_PARAM params[] = {
{ 'foo', OSSL_PARAM_INTEGER, &haha, sizeof(haha), NULL },
{ NULL, 0, NULL, 0, NULL }
};

...
}

Because the compiler for that language version isn't allowed to emit
code to use '&haha' in an inititializer.  Newer C language versions
allow this.

So while this is an issue for *us*, it isn't necessarily an issue for
our users, all depending on what C language version they use.

> 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.

The design was not only to be able to have nice compile time
initialization, but also to be able to pass the array as 'const
OSSL_PARAM *', i.e. an indication to the recipient that the array
itself should never be modified (less chance of compromise).  Maybe
that's overly paranoid, but that was a line of thinking.

> 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

It's actually perfectly possible to do this today.  We already have
this pointer, it's called 'data'.

> 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

My major concern with that, apart from having to modify the OSSL_PARAM
items themselves¸ is that some time in the future, we will want to add
another native type that's larger, which means we modify the size of a
OSSL_PARAM.  It's a public structure, so that can't be treated
lightly.

Also, with a union of native types, we're losing uniformity on MSB
first platforms.  Having an exact 1:1 integer size match will be
crucial, and that complicates the code quite a bit...  not to mention
that we have a compatibility problem as soon as one end has a new
native type in the union and the other doesn't.
(one would imagine that simply using uintmax_t would cover all integer
sizes apart from BIGNUM, but the potential size change of that type
with newer compilers make such a choice precarious)

> 3. add a flag field to the OSSL_PARAM to indicate that the referenced value 
> needs to be freed.

By whom?  The owner of the array should be in complete control of
what's needed already, so should be able to know what needs being
deallocated or not.

If you're thinking that the receiving side should free certain values,
then you need to pass a pointer to the routine to be used to free the
value rather than just a flag.

> 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

Re: OSSL_PARAMs

[Dr Paul Dale]

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?


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  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

Re: OSSL_PARAMs

[Dr Paul Dale]

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

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

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

Re: OSSL_PARAMs

[Richard Levitte]

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

Re: OSSL_PARAMs

[Salz, Rich]

>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.

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?

Re: OpenSSL 3.0.0 FIPS Validation

[Matt Caswell]

On 04/06/2019 00:08, Matthew Lindner wrote:
> I notice that the OpenSSL 3.0.0 design page
> https://www.openssl.org/docs/OpenSSL300Design.html still references
> "CAVS testing" even though CAVS testing is shortly ending with the
> release of ACVP testing. See:
> https://csrc.nist.gov/Projects/Automated-Cryptographic-Validation-Testing
> The new format is JSON based and entirely different from the previous
> CAVS file format.
> 
> Is OpenSSL team simply using "CAVS Testing" generically or is OpenSSL
> team missing some information?

We're well aware of the ACVP testing that is coming down the line. At the time
we made the design decisions it was not clear whether ACVP would be available
and sufficiently mature within the timescales we needed it to be. Therefore we
made the decision to go with CAVS testing for the initial 3.0 release.

Matt

OpenSSL 3.0.0 FIPS Validation

[Matthew Lindner]

I notice that the OpenSSL 3.0.0 design page
https://www.openssl.org/docs/OpenSSL300Design.html still references
"CAVS testing" even though CAVS testing is shortly ending with the
release of ACVP testing. See:
https://csrc.nist.gov/Projects/Automated-Cryptographic-Validation-Testing
The new format is JSON based and entirely different from the previous
CAVS file format.

Is OpenSSL team simply using "CAVS Testing" generically or is OpenSSL
team missing some information?

- Matthew

Re: OSSL_PARAMs

[Richard Levitte]

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.

The main differences are that we aren't stuck with the limitations of
the control functions, that the interface is uniform (if you look at
the control functions, they have variety, all depending on when they
were crafted and by who), and that you can pass or retrieve several
parameters in one go.  Also, it's extensible (i.e. it's always
possible to add new data types if we feel the need to).

Cheers,
Richard

On Tue, 04 Jun 2019 08:12:50 +0200,
Dr Paul Dale wrote:
> 
> 
> A question for the committers and beyond.
> 
> Should the OSSL_PARAM concept be used for more than just the libcrypto ⇿ 
> provider interface?
> 
> The one that springs to mind is a more general form of the various ctrl 
> calls, there are some
> string ctrl calls that attempt to do the same thing in a less structured 
> manner.
> 
> Thoughts?
> 
> Pauli
> -- 
> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/