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.
>
> Th
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, SH
--
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
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
> 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 ch
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 ow
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
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
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 effi
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 (th
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
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
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 GitH
>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 definitiv
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/Autom
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 i
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 contr
17 matches
Mail list logo
