Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Loading oqsprovider fails via API load under Windows #237

Closed
VeronikaNguyen opened this issue Aug 29, 2023 · 16 comments · Fixed by #243
Closed

Loading oqsprovider fails via API load under Windows #237

VeronikaNguyen opened this issue Aug 29, 2023 · 16 comments · Fixed by #243

Comments

@VeronikaNguyen
Copy link
Contributor

VeronikaNguyen commented Aug 29, 2023

I am trying to load the oqsprovider via code under Windows since loading the provider over the openssl config is not an option for me.
The oqsprovider.dll file is located in D:\projects\certificate_scripts. When running the following commands

OSSL_PROVIDER_set_default_search_path(NULL, "D:\\projects\\certificate_scripts");
auto path = OSSL_PROVIDER_get0_default_search_path(NULL);
auto loaded = OSSL_PROVIDER_load(NULL, "oqsprovider");

path is set correctly, however, loaded is NULL, which indicates that the provider was not successfully loaded.

When printing out the error with

  int err = ERR_get_error();
  char buf[256];
  ERR_error_string_n(err, buf, sizeof(buf));

it says error:078C0105:common libcrypto routines::init fail.

Am I missing something here? I am grateful for every kind of input.

@baentsch
Copy link
Member

I only have very little experience with Windows, sorry. Also the error message seems to be pretty generic/not really OQS-related: Are you certain to have set up all other code correctly? For example, can you load the "default" provider via the code above OK?

@VeronikaNguyen
Copy link
Contributor Author

Thank you for the quick answer! Yes, I am quite certain that the other code is set up correctly. Loading the "default" provider via the above code works.

I will ask the same question in the openssl forum.

@baentsch
Copy link
Member

Loading the "default" provider via the above code works.

Have you loaded the default provider and then tried to load oqsprovider? The latter depends on the former.... And depending on how you built liboqs (with or without OpenSSL support?) that also may depend on OpenSSL having been properly initialized: And if the liboqs initialization fails, oqsprovider init also fails.

@VeronikaNguyen
Copy link
Contributor Author

Have you loaded the default provider and then tried to load oqsprovider?

Yes, however, this still does not work.

I used the oqsprovider.dll attached to release version 0.5.1. Loading the provider works if I set the environment variable OPENSSL_CONF and activate the oqsprovider.

@baentsch
Copy link
Member

Loading the provider works if I set the environment variable OPENSSL_CONF and activate the oqsprovider.

Ahh -- that is interesting. Then the "machinations of OQS (initialization)" don't play a role, but it's indeed a question how things have to be set up via the OpenSSL APIs: Please post a link to the discussion in OpenSSL -- I'd be curious to learn what comes up there.

Final question from my side: Have you tried running your C code in Unix/Linux to see whether this is a Windows-only issue? I'd be happy to try your code if you don't have such environment.

@marcbrevoort-cyberhive
Copy link
Contributor

marcbrevoort-cyberhive commented Aug 30, 2023

You might need to load a pq-activated config in code with CONF_modules_load_file.

@baentsch
Copy link
Member

You might need to load a pq-activated config in code with CONF_modules_load_file.

Definitely worth while trying. This shouldn't change things materially as provider activation happens implicitly when calling OSSL_PROVIDER_load, but why not checking this out?

@VeronikaNguyen
Copy link
Contributor Author

@marcbrevoort-cyberhive Thanks for the suggestion. I tried it out but it didn't change the result.

@baentsch It would be great if you could try this out under Linux for me.

#include <openssl/conf.h>
#include <openssl/provider.h>

int main()
{
    auto libctx = OSSL_LIB_CTX_new();
    //OSSL_LIB_CTX_load_config(libctx, "D:\\projects\\openssl.cfg");
    //CONF_modules_load_file("D:\\projects\\openssl.cfg", NULL, NULL);
    OSSL_PROVIDER_set_default_search_path(libctx, "D:\\projects\\certificate_scripts");     // path is set to location of oqsprovider.dll
    OSSL_PROVIDER_load(libctx, "default");
    OSSL_PROVIDER_load(libctx, "oqsprovider");
}

@baentsch
Copy link
Member

This works like a charm under Linux:

$ cat test.c
#include <openssl/conf.h>
#include <openssl/provider.h>

int main()
{
    OSSL_LIB_CTX* libctx = OSSL_LIB_CTX_new();
    OSSL_PROVIDER_set_default_search_path(libctx, "_build/lib");     // path is set to location of oqsprovider.dll
    printf("load default result: %p\n", OSSL_PROVIDER_load(libctx, "default"));
    printf("load oqsprovider result: %p\n", OSSL_PROVIDER_load(libctx, "oqsprovider"));
}


$ gcc test.c -lcrypto
$ ./a.out 
load default result: 0x55fa28183d50
load oqsprovider result: 0x55fa281846b0

@baentsch baentsch changed the title Loading oqsprovider fails Loading oqsprovider fails via API load under Windows Aug 30, 2023
@baentsch
Copy link
Member

PS: Any change (wrong path, wrong provider name, etc) lead to an expected "(nil)" output in the second line.

@VeronikaNguyen
Copy link
Contributor Author

@baentsch Thanks for trying this out for me under Linux. It's good to know that this might be a Windows error.

PS: Any change (wrong path, wrong provider name, etc) lead to an expected "(nil)" output in the second line.

Checked for the path and name multiple times.

@baentsch
Copy link
Member

I'm afraid then there's no way around asking for help from the (Windows) OpenSSL community. Please post a link here when you have opened an issue (or reference this issue) so we can learn the resolution as and when available.

@VeronikaNguyen
Copy link
Contributor Author

openssl/openssl#21903

@VeronikaNguyen
Copy link
Contributor Author

Thank you very much @baentsch for the quick fixing of the issue.

@baentsch
Copy link
Member

baentsch commented Sep 5, 2023

Thank you very much @baentsch for the quick fixing of the issue.

You're welcome. Thanks in turn for raising it and helping getting to the cause of this. Made the software a bit better... I hope -- could you confirm your issue is truly resolved?

@VeronikaNguyen
Copy link
Contributor Author

Not yet, but I will try out soon.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants