Use of non-default OSSL_LIB_CTX* within OpenSSL construction

[RodriM11]

Hi! I wanted to propose the improvement of using a OSSL_LIB_CTX * library context generated within liboqs, instead of the default (NULL) that is being used now, particularly regarding randomness generation, and also fetching procedures, when liboqs is constructed with OQS_USE_OPENSSL=ON.
I think this modification on itself is of interest, as liboqs would generate its own library context and would not rely on the default NULL library context, which could be potentially modified by other application using the same OpenSSL libraries, potentially impacting where randomness is derived from, and the definition of the underlying primitives being fetched.

Additionally, I wanted to also ask whether it would be of interest that, once this modification is performed, liboqs should account for some "personalization" of this library context (e.g. with OpenSSL's RAND_set_DRBG_type, or maybe with more detailed procedures for specific parameters). Although maybe this is outside of the scope of what liboqs should account for.

[baentsch]

Thanks for the proposal @RodriM11 -- this somewhat begs the question, though, how (and where/via which API) this specific libctx shall be configurable?

[RodriM11]

Yes, precisely my doubt as well. At first, I was thinking of exposing an API that would let you precisely configure the "more relevant" parameters within an OpenSSL's DRBG (i.e., the type, and the underlying cipher/digest to employ, as RAND_set_DRBG_type does). But some could argue that "what if I want to configure more specific parameters, like reseed_requests, etc..." and that would entail maybe employing the OSSL_PARAM as part of the API and so on.
I can, on a first approximation, include the use of a non-default library context (which I think is, on itself, relevant), and we can debate as to which/if further configuration is desirable, and how to proceed with it.

[baentsch]

on a first approximation, include the use of a non-default library context (which I think is, on itself, relevant),

Which relevance do you see if there's now way to configure it?

[RodriM11]

Which relevance do you see if there's now way to configure it?

At the very least, not relying on a global library context which is shared between all applications using the same OpenSSL libraries (noy only liboqs), and that can in turn be modified by any of them, having (plausibly non-noticeable) repercussions on liboqs.
I think though that, if included, further configuration along OpenSSL's lines would also be desirable, and would have to decide then up to which point/how to allow it to happen.

[baentsch]

At the very least, not relying on a global library context which is shared between all applications using the same OpenSSL libraries (noy only liboqs), and that can in turn be modified by any of them, having (plausibly non-noticeable) repercussions on liboqs.

True. But at least there is a way for apps to get at and change the default libctx. I don't see how this would work for a libctx specific to liboqs. Maybe you could document a concrete usage scenario a non-default libctx would enable (and how it's used by the app)?

[RodriM11]

Yes, that is true. It is precisely the capacity of liboqs of modifying the default provider (as any other application running over the same OpenSSL libraries as liboqs is) what I would argue should be controlled, by infusing liboqs with its own library context. In my mind, it is not that a non-default libctx "enables" something, more so the opposite, it blocks the possibility of an undesirable DRBG to be used, or a flawed algorithm implementation to be fetched. But, in doing so, it also blocks the personalization possibilities of the default libctx, which can be accessed from any app. Since this library context could not be "personalized" unless an API is prepared for it, and that could be desirable for users, I would propose the following:

• A liboqs API that allows to configure the type, seed source and digest/cipher to employ (i.e., a way to mix RAND_set_DRBG_type and RAND_set_seed_source_type). For it, you would need 3/4 const char * params, to determine each of the values (in line with OpenSSL's nomenclature).
• Additionally, it could also be desired to establish special OSSL_PARAM to the underlying DRBGs. In order to do so, I can think of two ways: Either the API accounts for an additional void * context, which should represent the OSSL_PARAM * buffer to be later used (this way, it is a clean selection, and leaves to the user and OpenSSL to establish what should and should not be established as parameters). Or, an explicit OQS_... struct is constructed and added to the API, which holds the specific parameters liboqs wishes to allow to be set (this solution would have the setback of having to update this set of possibilities if OpenSSL were to update the collection of settable parameters, which currently are two, reseed_requests and reseed_time_interval)

In any case, this would allow both to add control by "honoring" a library context, and provide the same personalization options you would have by modifying the default library context.