wolfssl icon indicating copy to clipboard operation
wolfssl copied to clipboard
verified publisher icon wolfSSL

Help Needed: wolfSSL Build Issue with Latest Version and Runtime Error with Dilithium Certificates

Open SanzidaH opened this issue 1 year ago • 7 comments

Version

6af54d3de23598437b5455b934de55615b4f7a58

Description

I am stuck on the following issues with wolfSSL, and I would greatly appreciate any guidance or suggestions to resolve them.

  1. Runtime Issue with an Older wolfSSL Version: With an earlier version of wolfSSL that successfully installed few days ago, I face a runtime error when using Dilithium-based certificates (i.e. dilithium2) generated using liboqs library.

wolfSSL Entering GetAlgoId Unknown or not compiled in key OID Decode to key failed wolfSSL Leaving ProcessBuffer, return -463 wolfSSL error: can't load server cert file, check file and run from wolfSSL home dir

It seems wolfSSL does not recognize the OID for dilithium2. For configure this is what I run: ./configure --enable-certreq --enable-certgen --enable-certext --enable-keygen --enable-cryptocb --with-liboqs --disable-psk --disable-shared --enable-intelasm --enable-aesni --enable-sp-math-all --enable-sp-asm --enable-experimental --enable-kyber CFLAGS="-Os"

  1. Build Issue with Latest wolfSSL: When building the latest wolfSSL version, I get the following error -

./wolfssl/wolfcrypt/dilithium.h:515:39: error: ‘OQS_SIG_ml_dsa_87_ipd_length_public_key’ undeclared here (not in a function); did you mean ‘OQS_SIG_ml_dsa_87_length_public_key’? 515 | #define DILITHIUM_LEVEL5_PUB_KEY_SIZE OQS_SIG_ml_dsa_87_ipd_length_public_key | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./wolfssl/wolfcrypt/dilithium.h:515:39: note: in definition of macro ‘DILITHIUM_LEVEL5_PUB_KEY_SIZE’ 515 | #define DILITHIUM_LEVEL5_PUB_KEY_SIZE OQS_SIG_ml_dsa_87_ipd_length_public_key | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./wolfssl/wolfcrypt/dilithium.h:596:12: note: in expansion of macro ‘DILITHIUM_MAX_PUB_KEY_SIZE’ 596 | byte p[DILITHIUM_MAX_PUB_KEY_SIZE]; | ^~~~~~~~~~~~~~~~~~~~~~~~~~ ./wolfssl/wolfcrypt/dilithium.h:513:39: error: ‘OQS_SIG_ml_dsa_87_ipd_length_secret_key’ undeclared here (not in a function); did you mean ‘OQS_SIG_ml_dsa_87_length_secret_key’? 513 | #define DILITHIUM_LEVEL5_KEY_SIZE OQS_SIG_ml_dsa_87_ipd_length_secret_key | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./wolfssl/wolfcrypt/dilithium.h:513:39: note: in definition of macro ‘DILITHIUM_LEVEL5_KEY_SIZE’ 513 | #define DILITHIUM_LEVEL5_KEY_SIZE OQS_SIG_ml_dsa_87_ipd_length_secret_key | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./wolfssl/wolfcrypt/dilithium.h:597:12: note: in expansion of macro ‘DILITHIUM_MAX_KEY_SIZE’ 597 | byte k[DILITHIUM_MAX_KEY_SIZE]; | ^~~~~~~~~~~~~~~~~~~~~~ make[2]: *** [Makefile:7294: wolfcrypt/src/src_libwolfssl_la-sha.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... In file included from ./wolfssl/wolfcrypt/cryptocb.h:83, from wolfcrypt/src/aes.c:63: ./wolfssl/wolfcrypt/dilithium.h:515:39: error: ‘OQS_SIG_ml_dsa_87_ipd_length_public_key’ undeclared here (not in a function); did you mean ‘OQS_SIG_ml_dsa_87_length_public_key’? 515 | #define DILITHIUM_LEVEL5_PUB_KEY_SIZE OQS_SIG_ml_dsa_87_ipd_length_public_key | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./wolfssl/wolfcrypt/dilithium.h:515:39: note: in definition of macro ‘DILITHIUM_LEVEL5_PUB_KEY_SIZE’ 515 | #define DILITHIUM_LEVEL5_PUB_KEY_SIZE OQS_SIG_ml_dsa_87_ipd_length_public_key | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./wolfssl/wolfcrypt/dilithium.h:596:12: note: in expansion of macro ‘DILITHIUM_MAX_PUB_KEY_SIZE’ 596 | byte p[DILITHIUM_MAX_PUB_KEY_SIZE]; | ^~~~~~~~~~~~~~~~~~~~~~~~~~ ./wolfssl/wolfcrypt/dilithium.h:513:39: error: ‘OQS_SIG_ml_dsa_87_ipd_length_secret_key’ undeclared here (not in a function); did you mean ‘OQS_SIG_ml_dsa_87_length_secret_key’? 513 | #define DILITHIUM_LEVEL5_KEY_SIZE OQS_SIG_ml_dsa_87_ipd_length_secret_key | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./wolfssl/wolfcrypt/dilithium.h:513:39: note: in definition of macro ‘DILITHIUM_LEVEL5_KEY_SIZE’ 513 | #define DILITHIUM_LEVEL5_KEY_SIZE OQS_SIG_ml_dsa_87_ipd_length_secret_key | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./wolfssl/wolfcrypt/dilithium.h:597:12: note: in expansion of macro ‘DILITHIUM_MAX_KEY_SIZE’ 597 | byte k[DILITHIUM_MAX_KEY_SIZE]; | ^~~~~~~~~~~~~~~~~~~~~~ make[2]: *** [Makefile:7280: wolfcrypt/src/src_libwolfssl_la-aes.lo] Error 1 make[2]: Leaving directory '/home/sanzida-pqc/osp/oqs/wolfssl' make[1]: *** [Makefile:9027: install-recursive] Error 1 make[1]: Leaving directory '/home/sanzida-pqc/osp/oqs/wolfssl' make: *** [Makefile:9502: install] Error 2

It seems that some macros, such as OQS_SIG_ml_dsa_87_ipd_length_public_key, are undefined. Is this a compatibility issue between liboqs and wolfSSL, or am I missing some configuration steps?

I will really appreciate any suggestion/guidance to resolve these issues.

SanzidaH avatar Nov 29 '24 01:11 SanzidaH

Second one got resolved as I updated liboqs to 0.10.0. I will really appreciate any suggestion for first one. Please let me know if any additional info is required.

SanzidaH avatar Nov 29 '24 16:11 SanzidaH

Hello @SanzidaH Thank you for your interest in our post-quantum implementations in wolfSSL! Note that we currently support both MLDSA and Dilithium. This particular snippet from asn.c might be of interest to you:

#ifdef HAVE_DILITHIUM
#ifdef WOLFSSL_DILITHIUM_FIPS204_DRAFT
    /* Dilithium Level 2: 1.3.6.1.4.1.2.267.12.4.4 */
    static const byte keyDilithium_Level2Oid[] =
        {43, 6, 1, 4, 1, 2, 130, 11, 12, 4, 4};

    /* Dilithium Level 3: 1.3.6.1.4.1.2.267.12.6.5 */
    static const byte keyDilithium_Level3Oid[] =
        {43, 6, 1, 4, 1, 2, 130, 11, 12, 6, 5};

    /* Dilithium Level 5: 1.3.6.1.4.1.2.267.12.8.7 */
    static const byte keyDilithium_Level5Oid[] =
        {43, 6, 1, 4, 1, 2, 130, 11, 12, 8, 7};
#endif

    /* ML-DSA Level 2: 2.16.840.1.101.3.4.3.17 */
    static const byte keyMlDsa_Level2Oid[] =
        {96, 134, 72, 1, 101, 3, 4, 3, 17};

    /* ML-DSA Level 3: 2.16.840.1.101.3.4.3.18 */
    static const byte keyMlDsa_Level3Oid[] =
        {96, 134, 72, 1, 101, 3, 4, 3, 18};

    /* ML-DSA Level 5: 2.16.840.1.101.3.4.3.19 */
    static const byte keyMlDsa_Level5Oid[] =
        {96, 134, 72, 1, 101, 3, 4, 3, 19};
#endif /* HAVE_DILITHIUM */

can you please try using --enable-dilithium=fips204-draft and let us know if that helps?

Warm regards, Anthony

anhu avatar Nov 29 '24 16:11 anhu

Here at wolfSSL we love learning about how the academic community is using our source code. Can you please tells more about yourself and your project?

  • where are you located?
  • what are the goals of your project?
  • will there be a paper published based on your work on this project?
  • is there a specific institution and/or professor associated to this project?
  • any other relevant information you'd like to share.

If you are hesitant to share this information on a public platform, you can send me email at [email protected].

Warm regards, Anthony

anhu avatar Nov 29 '24 16:11 anhu

I'm encountering similar issues (problem 2). While I can compile wolfSSL v5.7.0-stable with liboqs 0.12.0, this wolfSSL version yields problems with Dilithium 2 and Dilithium 3 certificates in my libcoap application (the problem relates to keyType being set to dilithium_level5_sa_algo in line 7937 of src/ssl.c). This issue doesn't occur with wolfSSL's example server and client. So I cannot use this version for my research. I see this part of the code has changed since v5.7.2-stable so the fix is no longer required, but I don't know which target liboqs version works with this version of wolfSSL.

fj-blanco avatar Dec 19 '24 10:12 fj-blanco

Hello all. I am a colleage of @fj-blanco and we are actively working with his wolfSSL implementation into libcoap.

I've encountered and investigated the same issue to the extent I could grasp. These are my findings:

  1. The build error (problem 2) is due to a naming mismatch between wolfSSL and the latest liboqs version. The wolfSSL code is looking for identifiers with 'ipd' in their names (e.g., OQS_SIG_ml_dsa_87_ipd_length_public_key), but current liboqs uses names without 'ipd' (e.g., OQS_SIG_ml_dsa_87_length_public_key). They removed the IPD intermediate values recently (see this note).

  2. Removing 'ipd' from the macro definitions in wolfssl/wolfcrypt/dilithium.h and the '_ipd' ones from wolfcrypt/src/dilithium.c fixes this issue and building finishes normally. So, in principle, this reconciliates latest liboqs, oqs-provider and wolfSSL versions.

  3. The predefined benchmarks with ./wolfcrypt/benchmark/benchmark -pq complete succesfully but do not show any Dilithium metric, just ML-DSA. On the other hand, the predefined test with ./build/wolfcrypt/test/testwolfcrypt fail when it reaches Dilithium

ED448    test passed!
KYBER    test passed!
DILITHIUM test failed!
 error L=42200 code=-790 (unknown error number)
 [fiducial line numbers: 8773 27740 43402 55860]
Exiting main with return code: -1

The failing wolfcrypt test suggests there might be additional considerations needed beyond just updating the macro names, possibly related to test vectors or internal function mappings in the test script. This could be related to the ongoing transition in liboqs where Dilithium implementations are being consolidated under ML-DSA names. What I have not entirely clear is if wolfSSL maps only to the ML-DSA or if there is also a way to access the old Dilithium (both are still available through the provider).

dasobral avatar Jan 17 '25 15:01 dasobral

Hello. I am using version 5.8.0 and the benchmark mentioned by @dasobral runs like a charm:

DESKTOP-R3NACDK:/opt/5.8.0# ./wolfcrypt/benchmark/benchmark -pq
wolfSSL version 5.8.0
Math: Multi-Precision: Wolf(SP) word-size=64 bits=4096 sp_int.c
Single Precision: ecc 256 384 521 rsa/dh 2048 3072 4096 asm sp_x86_64.c
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
ML-KEM 512 128 key gen 135000 ops took 1.000 sec, avg 0.007 ms, 134944.919 ops/sec
ML-KEM 512 128 encap 121800 ops took 1.001 sec, avg 0.008 ms, 121724.515 ops/sec
ML-KEM 512 128 decap 282300 ops took 1.000 sec, avg 0.004 ms, 282244.888 ops/sec
ML-KEM 768 192 key gen 66100 ops took 1.001 sec, avg 0.015 ms, 66002.514 ops/sec
ML-KEM 768 192 encap 67000 ops took 1.000 sec, avg 0.015 ms, 66994.585 ops/sec
ML-KEM 768 192 decap 240500 ops took 1.000 sec, avg 0.004 ms, 240433.791 ops/sec
ML-KEM 1024 256 key gen 40100 ops took 1.000 sec, avg 0.025 ms, 40085.282 ops/sec
ML-KEM 1024 256 encap 39900 ops took 1.002 sec, avg 0.025 ms, 39835.322 ops/sec
ML-KEM 1024 256 decap 170700 ops took 1.000 sec, avg 0.006 ms, 170688.972 ops/sec
ML-DSA 44 key gen 26800 ops took 1.002 sec, avg 0.037 ms, 26733.929 ops/sec
ML-DSA 44 sign 6800 ops took 1.012 sec, avg 0.149 ms, 6717.335 ops/sec
ML-DSA 44 verify 24500 ops took 1.002 sec, avg 0.041 ms, 24453.155 ops/sec
ML-DSA 65 key gen 14000 ops took 1.003 sec, avg 0.072 ms, 13956.138 ops/sec
ML-DSA 65 sign 4200 ops took 1.004 sec, avg 0.239 ms, 4182.846 ops/sec
ML-DSA 65 verify 15200 ops took 1.001 sec, avg 0.066 ms, 15186.419 ops/sec
ML-DSA 87 key gen 9800 ops took 1.001 sec, avg 0.102 ms, 9790.040 ops/sec
ML-DSA 87 sign 3500 ops took 1.009 sec, avg 0.288 ms, 3468.204 ops/sec
ML-DSA 87 verify 9400 ops took 1.009 sec, avg 0.107 ms, 9313.694 ops/sec
Benchmark complete

Nevertheless, I am having the same problem as described by @fj-blanco. When I use the pregenerated certificates in DTLS1.3 the interaction looks good:

DESKTOP-R3NACDK:/opt/5.8.0# examples/server/server -v 4 -u -A ../osp/oqs/mldsa87_root_cert.pem -c ../osp/oqs/mldsa44_entity_cert.pem -k ../osp/oqs/mldsa44_entity_key.pem --pqc P521_ML_KEM_1024 Using Post-Quantum KEM: P521_ML_KEM_1024
 Alternate cert chain used 
   issuer : /C=CA/ST=ON/L=Waterloo/O=wolfSSL Inc./OU=Engineering/CN=Root Certificate/[email protected] 
   subject: /C=CA/ST=ON/L=Waterloo/O=wolfSSL Inc./OU=Engineering/CN=Entity Certificate/[email protected] 
   altname = 127.0.0.1 
   serial number:33 
SSL version is DTLSv1.3 
SSL cipher suite is TLS_AES_256_GCM_SHA384 
SSL signature algorithm is SHA256
SSL curve name is P521_ML_KEM_1024 
Server Random : FC34BC7962DDEBFC4AF53BF69CADDC4501304FCF5A628DFEF0054EAC652AA75D 
Client message: hello wolfssl!

But if I generate them with the provided script at osp.git:

@DESKTOP-R3NACDK:~# bash generate_dilithium_chains_with_providers.sh
Certificate request self-signature ok
subject=C = CA, ST = ON, L = Waterloo, O = wolfSSL Inc., OU = Engineering, CN = Entity Certificate, emailAddress = [email protected]
Certificate request self-signature ok
subject=C = CA, ST = ON, L = Waterloo, O = wolfSSL Inc., OU = Engineering, CN = Entity Certificate, emailAddress = [email protected]
Certificate request self-signature ok
subject=C = CA, ST = ON, L = Waterloo, O = wolfSSL Inc., OU = Engineering, CN = Entity Certificate, emailAddress = [email protected]
mldsa44_entity_cert.pem: OK
mldsa65_entity_cert.pem: OK
mldsa87_entity_cert.pem: OK

And then I try to use them, I receive a fatal error:

@DESKTOP-R3NACDK:/opt/5.8.0# examples/server/server -v 4 -u -A ../osp/oqs/mldsa87_root_cert.pem -c ../osp/oqs/mldsa44_entity_cert.pem -k ../osp/oqs/mldsa44_entity_key.pem --pqc P521_ML_KEM_1024 Using Post-Quantum KEM: P521_ML_KEM_1024
Using Post-Quantum KEM: P521_ML_KEM_1024
SSL_accept error -313, received alert fatal error
wolfSSL error: SSL_accept failed

My openssl provider is:

@DESKTOP-R3NACDK:/opt/5.8.0# openssl list -providers
Providers:
  default
    name: OpenSSL Default Provider
    version: 3.0.16
    status: active
  oqsprovider
    name: OpenSSL OQS Provider
    version: 0.8.1-dev
    status: active

And my version of liboqs is 0.11.0:

@DESKTOP-R3NACDK:/opt/5.8.0# ldd /usr/lib/x86_64-linux-gnu/ossl-modules/oqsprovider.so
        linux-vdso.so.1 (0x00007ffc4219d000)
        liboqs.so.6 => /lib/x86_64-linux-gnu/liboqs.so.6 (0x00007f0f54c16000)
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f0f54790000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0f545af000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0f5540a000)
@DESKTOP-R3NACDK:/opt/5.8.0# ls -l /lib/x86_64-linux-gnu/liboqs.so.6
lrwxrwxrwx 1 root root 16 May 26 16:18 /lib/x86_64-linux-gnu/liboqs.so.6 -> liboqs.so.0.11.0

Thanks for the help

aml-upm avatar May 28 '25 07:05 aml-upm

This is no longer an issue. Update to liboqs 0.13.0 and liboqsprovider 0.9.0 and it works!

Hello. I am using version 5.8.0 and the benchmark mentioned by @dasobral runs like a charm:

DESKTOP-R3NACDK:/opt/5.8.0# ./wolfcrypt/benchmark/benchmark -pq
wolfSSL version 5.8.0
Math: Multi-Precision: Wolf(SP) word-size=64 bits=4096 sp_int.c
Single Precision: ecc 256 384 521 rsa/dh 2048 3072 4096 asm sp_x86_64.c
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
ML-KEM 512 128 key gen 135000 ops took 1.000 sec, avg 0.007 ms, 134944.919 ops/sec
ML-KEM 512 128 encap 121800 ops took 1.001 sec, avg 0.008 ms, 121724.515 ops/sec
ML-KEM 512 128 decap 282300 ops took 1.000 sec, avg 0.004 ms, 282244.888 ops/sec
ML-KEM 768 192 key gen 66100 ops took 1.001 sec, avg 0.015 ms, 66002.514 ops/sec
ML-KEM 768 192 encap 67000 ops took 1.000 sec, avg 0.015 ms, 66994.585 ops/sec
ML-KEM 768 192 decap 240500 ops took 1.000 sec, avg 0.004 ms, 240433.791 ops/sec
ML-KEM 1024 256 key gen 40100 ops took 1.000 sec, avg 0.025 ms, 40085.282 ops/sec
ML-KEM 1024 256 encap 39900 ops took 1.002 sec, avg 0.025 ms, 39835.322 ops/sec
ML-KEM 1024 256 decap 170700 ops took 1.000 sec, avg 0.006 ms, 170688.972 ops/sec
ML-DSA 44 key gen 26800 ops took 1.002 sec, avg 0.037 ms, 26733.929 ops/sec
ML-DSA 44 sign 6800 ops took 1.012 sec, avg 0.149 ms, 6717.335 ops/sec
ML-DSA 44 verify 24500 ops took 1.002 sec, avg 0.041 ms, 24453.155 ops/sec
ML-DSA 65 key gen 14000 ops took 1.003 sec, avg 0.072 ms, 13956.138 ops/sec
ML-DSA 65 sign 4200 ops took 1.004 sec, avg 0.239 ms, 4182.846 ops/sec
ML-DSA 65 verify 15200 ops took 1.001 sec, avg 0.066 ms, 15186.419 ops/sec
ML-DSA 87 key gen 9800 ops took 1.001 sec, avg 0.102 ms, 9790.040 ops/sec
ML-DSA 87 sign 3500 ops took 1.009 sec, avg 0.288 ms, 3468.204 ops/sec
ML-DSA 87 verify 9400 ops took 1.009 sec, avg 0.107 ms, 9313.694 ops/sec
Benchmark complete

Nevertheless, I am having the same problem as described by @fj-blanco. When I use the pregenerated certificates in DTLS1.3 the interaction looks good:

DESKTOP-R3NACDK:/opt/5.8.0# examples/server/server -v 4 -u -A ../osp/oqs/mldsa87_root_cert.pem -c ../osp/oqs/mldsa44_entity_cert.pem -k ../osp/oqs/mldsa44_entity_key.pem --pqc P521_ML_KEM_1024 Using Post-Quantum KEM: P521_ML_KEM_1024
 Alternate cert chain used 
   issuer : /C=CA/ST=ON/L=Waterloo/O=wolfSSL Inc./OU=Engineering/CN=Root Certificate/[email protected] 
   subject: /C=CA/ST=ON/L=Waterloo/O=wolfSSL Inc./OU=Engineering/CN=Entity Certificate/[email protected] 
   altname = 127.0.0.1 
   serial number:33 
SSL version is DTLSv1.3 
SSL cipher suite is TLS_AES_256_GCM_SHA384 
SSL signature algorithm is SHA256
SSL curve name is P521_ML_KEM_1024 
Server Random : FC34BC7962DDEBFC4AF53BF69CADDC4501304FCF5A628DFEF0054EAC652AA75D 
Client message: hello wolfssl!

But if I generate them with the provided script at osp.git:

@DESKTOP-R3NACDK:~# bash generate_dilithium_chains_with_providers.sh
Certificate request self-signature ok
subject=C = CA, ST = ON, L = Waterloo, O = wolfSSL Inc., OU = Engineering, CN = Entity Certificate, emailAddress = [email protected]
Certificate request self-signature ok
subject=C = CA, ST = ON, L = Waterloo, O = wolfSSL Inc., OU = Engineering, CN = Entity Certificate, emailAddress = [email protected]
Certificate request self-signature ok
subject=C = CA, ST = ON, L = Waterloo, O = wolfSSL Inc., OU = Engineering, CN = Entity Certificate, emailAddress = [email protected]
mldsa44_entity_cert.pem: OK
mldsa65_entity_cert.pem: OK
mldsa87_entity_cert.pem: OK

And then I try to use them, I receive a fatal error:

@DESKTOP-R3NACDK:/opt/5.8.0# examples/server/server -v 4 -u -A ../osp/oqs/mldsa87_root_cert.pem -c ../osp/oqs/mldsa44_entity_cert.pem -k ../osp/oqs/mldsa44_entity_key.pem --pqc P521_ML_KEM_1024 Using Post-Quantum KEM: P521_ML_KEM_1024
Using Post-Quantum KEM: P521_ML_KEM_1024
SSL_accept error -313, received alert fatal error
wolfSSL error: SSL_accept failed

My openssl provider is:

@DESKTOP-R3NACDK:/opt/5.8.0# openssl list -providers
Providers:
  default
    name: OpenSSL Default Provider
    version: 3.0.16
    status: active
  oqsprovider
    name: OpenSSL OQS Provider
    version: 0.8.1-dev
    status: active

And my version of liboqs is 0.11.0:

@DESKTOP-R3NACDK:/opt/5.8.0# ldd /usr/lib/x86_64-linux-gnu/ossl-modules/oqsprovider.so
        linux-vdso.so.1 (0x00007ffc4219d000)
        liboqs.so.6 => /lib/x86_64-linux-gnu/liboqs.so.6 (0x00007f0f54c16000)
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f0f54790000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0f545af000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0f5540a000)
@DESKTOP-R3NACDK:/opt/5.8.0# ls -l /lib/x86_64-linux-gnu/liboqs.so.6
lrwxrwxrwx 1 root root 16 May 26 16:18 /lib/x86_64-linux-gnu/liboqs.so.6 -> liboqs.so.0.11.0

Thanks for the help

aml-upm avatar May 28 '25 16:05 aml-upm

Hi All,

Sorry this fell off my plate. Luckily you were not waiting for me! I will now close this issue.

Warm regards, Anthony

anhu avatar Nov 11 '25 16:11 anhu