On 01/02/2023 21:35, Dr Paul Dale wrote:
Try the query string: "?provider=myprov". This is prefer your provider
over other implementations.
Just to expand on this - for the above to work you must make sure that
your provider actually defines the "provider=myprov" property for all
algorithms that it supplies.
Matt
Pauli
On 2/2/23 08:29, Afshin Pir wrote:
Hi
Let’s assume that I have a custom provider that supports only RSA
signature/verification and I want to use it in an SSL/TLS connection.
But Since SSL/TLS needs other cryptography operation such as symmetric
encryption/decryption and key exchange too, I want to fall-back on
FIPS(or default) module for these operations.
I have used a code like this to load my provider and fall-back
provider and connect them to SSL context:
lib = OSSL_LIB_CTX_new();
defctxnull = OSSL_PROVIDER_load(NULL, "null");
OSSL_LIB_CTX_load_config(lib, "prov.cnf");
SSL_CTX *ctx = SSL_CTX_new_ex(lib, NULL, method);
From the logs inside my provider, I have noticed that my code works as
I want. Signature is done by my provider and rest of operations by my
fall-back provider. But the problem is that I don’t understand how the
fetching of signature algorithm happens here. How is it guaranteed
that my provider’s signature/verification is used rather than
signature/verification that is surely available in fall-back provider
too? I cannot resolve it by query string because if I use a query
string like this:
SSL_CTX *ctx = SSL_CTX_new_ex(lib, “provider=myprov”, method);
openssl will not match algorithms from fall-back module and since my
provider does not implement everything, I will not be able to use SSL/TLS.
Any idea how I can guarantee that only signature/verification of
SSL/TLS happens from my provider?
Best Regards,
Afshin
------------------------------------------------------------------------
This email is confidential and may contain information subject to
legal privilege. If you are not the intended recipient please advise
us of our error by return e-mail then delete this email and any
attached files. You may not copy, disclose or use the contents in any
way. The views expressed in this email may not be those of Gallagher
Group Ltd or subsidiary companies thereof.
------------------------------------------------------------------------
