You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! I wanted to propose a minor (but I think interesting) feature for the key generation, encapsulation and signature procedures, to ensure that the OSSL_LIB_CTX* context in which the provider is loaded is used within these three procedures. This would help ensure, for example, that whatever DRBG construction loaded into it is also used in these three probabilistic procedures (for the classical parts).
I am aware that an equivalent solution would be to ensure that the default NULL OSSL_LIB_CTX* context is established with the same DRBG as the libctx in which the provider is loaded, but this can be somewhat undesirable depending upon use, situation, etc... Meanwhile, I believe that this solution is fairly simple:
For Key Generation, the OSSL_LIB_CTX *libctx context received as parameter to the procedure ''oqsx_key_new'' would need to be propagated to the procedures oqsx_hybsig_init and oqshybkem_init_ecp/oqshybkem_init_ecx, for this context to then be used in the associated EVP_PKEY_CTX_new (to be modified to EVP_PKEY_CTX_new_from_pkey).
For Encapsulation, oqs_evp_kem_encaps_keyslot should be modified, to employ the OSSL_LIB_CTX* context inside pkemctx in the procedure EVP_PKEY_CTX_new_from_pkey (instead of EVP_PKEY_CTX_new).
For Sign, the procedure oqs_sig_sign should be expanded in a similar way to include the same libctx where appropiate.
Thanks in advance.
The text was updated successfully, but these errors were encountered:
Hi! I wanted to propose a minor (but I think interesting) feature for the key generation, encapsulation and signature procedures, to ensure that the
OSSL_LIB_CTX*
context in which the provider is loaded is used within these three procedures. This would help ensure, for example, that whatever DRBG construction loaded into it is also used in these three probabilistic procedures (for the classical parts).I am aware that an equivalent solution would be to ensure that the default NULL
OSSL_LIB_CTX*
context is established with the same DRBG as thelibctx
in which the provider is loaded, but this can be somewhat undesirable depending upon use, situation, etc... Meanwhile, I believe that this solution is fairly simple:oqsx_hybsig_init
andoqshybkem_init_ecp/oqshybkem_init_ecx
, for this context to then be used in the associatedEVP_PKEY_CTX_new
(to be modified toEVP_PKEY_CTX_new_from_pkey
).oqs_evp_kem_encaps_keyslot
should be modified, to employ theOSSL_LIB_CTX*
context insidepkemctx
in the procedureEVP_PKEY_CTX_new_from_pkey
(instead ofEVP_PKEY_CTX_new
).oqs_sig_sign
should be expanded in a similar way to include the same libctx where appropiate.Thanks in advance.
The text was updated successfully, but these errors were encountered: