> From: openssl-users On Behalf Of
> Blumenthal, Uri - 0553 - MITLL
> Sent: Wednesday, January 5, 2022 6:41 PM
> To: Dr Paul Dale ; openssl-users@openssl.org
> Subject: [EXTERNAL] Re: EVP_PKEY_get_int_param is not getting degree from
> EC key
>
> The problem that I see
On 05/01/2022 10:11, Wolf wrote:
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 bas
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 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
> > 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 type is
> > BIGNUM?
>
> No, the type is not a BIGNUM. Please read "man OSSL_PARAM" i
On Tue, 2022-01-04 at 17:02 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> > > In other words, the man page says it's unsigned int, but in fact
> > it's
> > > BIGNUM? Because the pointer I gave was to "unsigned int", like
> > in the
> > > OP's code.
> >
> > The param is too big to fit into int
> > In other words, the man page says it's unsigned int, but in fact it's
> > BIGNUM? Because the pointer I gave was to "unsigned int", like in the
> > OP's code.
>
> The param is too big to fit into int. If you were using some
> ridiculously small EC curve the call would succeed. The paramete
On Tue, 2022-01-04 at 16:46 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> On 1/4/22, 11:23, "Tomas Mraz" wrote:
>
> > > Theoretically, shouldn’t
> > >
> > > EVP_PKEY_get_int_param(pkey, OSSL_PARAM_EC_ORDER, &(unsigned
> > int)order)
> > >
> > > work? I verified that it does not seem to wo
On 1/4/22, 11:23, "Tomas Mraz" wrote:
> > Theoretically, shouldn’t
> >
> > EVP_PKEY_get_int_param(pkey, OSSL_PARAM_EC_ORDER, &(unsigned int)order)
> >
> > work? I verified that it does not seem to work, at least in the
> > obvious context.
>
> OSSL_PARAM_EC_ORDER is an unsigned integer
On Tue, 2022-01-04 at 14:17 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> Now I became interested. ;-)
>
> Theoretically, shouldn’t
>
> EVP_PKEY_get_int_param(pkey, OSSL_PARAM_EC_ORDER, &(unsigned
> int)order)
>
> work? I verified that it does not seem to work, at least in the
> obvious context
Now I became interested. ;-)
Theoretically, shouldn’t
EVP_PKEY_get_int_param(pkey, OSSL_PARAM_EC_ORDER, &(unsigned int)order)
work? I verified that it does not seem to work, at least in the obvious
context.
What is the purpose of that parameter and function call, and where/how can one
use it
On Tue, 2022-01-04 at 02:33 +0100, Wolf wrote:
> Thank you for the answer!
>
> On 2022-01-03 10:11:19 +0100, Tomas Mraz wrote:
> > You're using the secp384r1 curve which is a prime field curve. The
> > OSSL_PKEY_PARAM_EC_CHAR2_M parameter can be obtained only for
> > binary
> > field curves.
> >
Thank you for the answer!
On 2022-01-03 10:11:19 +0100, Tomas Mraz wrote:
> You're using the secp384r1 curve which is a prime field curve. The
> OSSL_PKEY_PARAM_EC_CHAR2_M parameter can be obtained only for binary
> field curves.
>
> If you have a group NID for the curve of the EC key, you could
On Mon, 2022-01-03 at 01:51 +0100, Wolf wrote:
> Greetings,
>
> I'm trying to port my program to openssl 3.0 and in the process I
> need
> to replace EC_GROUP_get_degree(EC_KEY_get0_group(ec)) with something
> that is not deprecated. I'm trying to use EVP_PKEY_get_int_param with
> OSSL_PKEY_PARAM_
18 matches
Mail list logo
