The problem that I see is that there's a set of parameters (such as
OSSL_PKEY_PARAM_EC_COFACTOR), not described in the man pages, with
under-specified type.
E.g., how is one to know where's "normal" ~~sloppiness~~ imperfection in
writing, and where "unsigned integer" truly means 'NOT C type "un
Better might be just adding a note to the parameters unlikely to fit
into a machine integer rather than confounding things with an additional
type which isn't really a separate type.
Pauli
"unsigned BIGNUM" instead of "unsigned integer" would be short and
much clearer
in the description and
On 1/4/22 11:49 PM, Gaurav Jain wrote:
Hello Boris/John
I am from NXP and currently working on enabling KTLS on NXP platforms via
openssl.
I see that you enabled KTLS support in openssl
3.0(https://www.openssl.org/news/changelog.html#openssl-30).
when I configure openssl 3.0 or 3.1.0 with ena
You are welcome. Determining why TLS handshakes fail is a challenge
since it does require knowledge of what cipher suites and algorithms
are required by the server and are missing in the client.
On Tue, 2022-01-04 at 23:08 +, Ma Zhenhua wrote:
> Hi Mark,
>
>
>
>
>
>
>
> Thanks so much f
On 2022-01-05 09:45, Tomas Mraz wrote:
...
So you're basically asking to put something like - "The parameter most
probably won't fit into unsigned int." - to every such parameter
documented for PKEYs?
"unsigned BIGNUM" instead of "unsigned integer" would be short and much
clearer
in the descr
Also it's bit weird that responder *may* choose to return error if
data_size is not suitable. What else it might do? Is it valid (from
responder's point of view) to just truncate the value to that it would
fit into unsigned int (that would obviously be useless behavior, I'm
just curious if it w
On 2022-01-05 09:45:14 +0100, Tomas Mraz wrote:
> > How does one know (without going through
> > EVP_PKEY_gettable_params(EVP_PKEY *pkey) and
> > EVP_PKEY_get_params(const EVP_PKEY *pkey, OSSL_PARAM params[])) what
> > method to use to retrieve what parameter?
>
> So you're basically asking to put
On Tue, 2022-01-04 at 19:25 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> > > But, considering that the man pages describe C API, wouldn't it
> > be
> > > nice to mention (even though it may be obvious that a number of
> > order
> > > 2^384 might not fit into 32 or even 64 bits) that the actual