KEM provider in TLS and avoiding unnecessary generation

[Tomas Mraz]

What is called initially is not a key pair generation but param
generation with a group ID as a parameter. This should be just
negligible operation which basically converts the group ID into an
internal data structure representing the group which is prepared for
further computations.

Please check the selection parameter of the gen_init() call into your
provider - it is OSSL_KEYMGMT_SELECT_ALL_PARAMETERS which is completely
different set of bits than OSSL_KEYMGMT_SELECT_KEYPAIR.

Tomas Mraz, OpenSSL


On Fri, 2023-05-19 at 15:36 +0000, Ladd, Watson via openssl-users
wrote:
> Dear all,
> 
> I've written a KEM provider for TLS but do not understand one thing
> about the flow on the server. It seems that first a key gets
> generated, and then the public key from the client is decoded onto
> that key. However, the generation routine computes a keypair which is
> an expensive operation. Is there a way my generation routine can know
> (via some setting) that the generated keypair is going to be
> immediately overwritten/is there a settable context parameter with
> the public key that I should support? I've looked at OQS but haven't
> understood what I've been seeing.
> 
> I find this design perplexing: surely letting each algorithm
> provide allocation and freeing and then keypair generation, and
> decoding and encoding routines+the kem routines would have worked. I
> understand this wouldn't fit RSA as well, but generally that sort of
> design is a mistake and we've moved away from having these free
> floating parameters in newer schemes/it's accomadatable other ways.
> 
> Sincerely,
> Watson Ladd

-- 
Tomáš Mráz, OpenSSL