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 something like - "The parameter most > probably won't fit into unsigned int." - to every such parameter > documented for PKEYs? I think changing the description of EVP_PKEY_get_int_param to something like: EVP_PKEY_get_int_param() retrieves a key pkey integer value *out associated with a name of key_name. This function might fail if the number is too large too fit, so for some parameters you should use (or retry with) EVP_PKEY_get_bn_param. Might suffice? To give some additional context (since I'm the original poster): I definitely did read the man pages. I've really tried to understand. But the fact the `unsigned integer` does not mean `unsigned int` was totally lost on me. Even now, when I know what to look for, I have hard time finding the relevant content in the man page. Sure, I guess this could have been the correct hint: The parameter data is an integer (signed or unsigned) of arbitrary length [..] But I so did not connect the dots there. I think adding into this paragraph mention then it can be access by both _int_param and _bn_param (depending on the size) would work as well. 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 would be compliant based on the man page). On separate note, my code is now passing the tests when running on openssl 3.0.1, so thank you very much for the guidance you've provided. W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
Attachment:
signature.asc
Description: PGP signature
