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:
>
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
>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
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
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
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
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
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
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
--
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
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,
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 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
The controls are easier to understand and use currently.
The advantage of params is that you can batch them, so that the order no longer
matters during setup (e.g- I need to set EVP_MD first).
The params are not being used in anger yet.
My main problem with the params is that no data is set into
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
15 matches
Mail list logo
