2 hybrid KEMs failing about oqs-provider HOT 8 CLOSED

kyber90s768 (just KEM) and p384_kyber768 work fine?

Yes: You can also see for yourself: ./testrun.sh openquantumsafe/oqs-ossl3 (in oqs-demos/openssl3/fulltest).

Testing ecdsap256:
    Tested KEM * successfully.
    Tested KEM X25519 successfully.
Error testing p256_oqs_kem_default: 
 Call to SSL_CONF_cmd(-groups, p256_oqs_kem_default) failed
 

    Tested KEM frodo640aes successfully.
    Tested KEM frodo640shake successfully.
    Tested KEM frodo976aes successfully.
    Tested KEM frodo976shake successfully.
    Tested KEM frodo1344aes successfully.
    Tested KEM frodo1344shake successfully.
    Tested KEM bike1l1cpa successfully.
    Tested KEM bike1l3cpa successfully.
    Tested KEM kyber512 successfully.
    Tested KEM kyber768 successfully.
    Tested KEM kyber1024 successfully.
    Tested KEM ntru_hps2048509 successfully.
    Tested KEM ntru_hps2048677 successfully.
    Tested KEM ntru_hps4096821 successfully.
    Tested KEM ntru_hrss701 successfully.
    Tested KEM lightsaber successfully.
    Tested KEM saber successfully.
    Tested KEM firesaber successfully.
    Tested KEM sidhp434 successfully.
    Tested KEM sidhp503 successfully.
    Tested KEM sidhp610 successfully.
    Tested KEM sidhp751 successfully.
    Tested KEM sikep434 successfully.
    Tested KEM sikep503 successfully.
    Tested KEM sikep610 successfully.
    Tested KEM sikep751 successfully.
    Tested KEM bike1l1fo successfully.
    Tested KEM bike1l3fo successfully.
    Tested KEM kyber90s512 successfully.
    Tested KEM kyber90s768 successfully.
    Tested KEM kyber90s1024 successfully.
    Tested KEM hqc128 successfully.
    Tested KEM hqc192 successfully.
    Tested KEM hqc256 successfully.
    Tested KEM ntrulpr653 successfully.
    Tested KEM ntrulpr761 successfully.
    Tested KEM ntrulpr857 successfully.
    Tested KEM sntrup653 successfully.
    Tested KEM sntrup761 successfully.
    Tested KEM sntrup857 successfully.
    Tested KEM p256_frodo640aes successfully.
    Tested KEM p256_frodo640shake successfully.
    Tested KEM p384_frodo976aes successfully.
    Tested KEM p384_frodo976shake successfully.
    Tested KEM p521_frodo1344aes successfully.
    Tested KEM p521_frodo1344shake successfully.
    Tested KEM p256_bike1l1cpa successfully.
    Tested KEM p384_bike1l3cpa successfully.
    Tested KEM p256_kyber512 successfully.
    Tested KEM p384_kyber768 successfully.
    Tested KEM p521_kyber1024 successfully.
    Tested KEM p256_ntru_hps2048509 successfully.
    Tested KEM p384_ntru_hps2048677 successfully.
    Tested KEM p521_ntru_hps4096821 successfully.
    Tested KEM p384_ntru_hrss701 successfully.
    Tested KEM p256_lightsaber successfully.
    Tested KEM p384_saber successfully.
    Tested KEM p521_firesaber successfully.
    Tested KEM p256_sidhp434 successfully.
    Tested KEM p256_sidhp503 successfully.
    Tested KEM p384_sidhp610 successfully.
    Tested KEM p521_sidhp751 successfully.
    Tested KEM p256_sikep434 successfully.
    Tested KEM p256_sikep503 successfully.
    Tested KEM p384_sikep610 successfully.
    Tested KEM p521_sikep751 successfully.
    Tested KEM p256_bike1l1fo successfully.
    Tested KEM p384_bike1l3fo successfully.
    Tested KEM p256_kyber90s512 successfully.
Error testing p384_kyber90s768: 
 CONNECTED(00000003)
481B31CD447F0000:error:0A000417:SSL routines:ssl3_read_bytes:sslv3 alert illegal parameter:ssl/record/rec_layer_s3.c:1588:SSL alert number 47
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 1521 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
 

    Tested KEM p521_kyber90s1024 successfully.
    Tested KEM p256_hqc128 successfully.
    Tested KEM p384_hqc192 successfully.
    Tested KEM p521_hqc256 successfully.
    Tested KEM p256_ntrulpr653 successfully.
    Tested KEM p384_ntrulpr761 successfully.
    Tested KEM p384_ntrulpr857 successfully.
    Tested KEM p256_sntrup653 successfully.
    Tested KEM p384_sntrup761 successfully.
    Tested KEM p384_sntrup857 successfully.
  Successfully concluded testing ecdsap256

The first error message indeed is different, so your assessment probably already has nailed that one. Nice.

And was p384_kyber90s768 interop so far tested e.g. between BoringSSL and OSSL111

Yes, here's the test between OSSL111 and nginx:

[...all other SIGs...]
Testing rsa3072_sphincsshake256128frobust:
[...all other KEMs with that SIG....]
    Tested KEM p384_kyber90s768 successfully.

Interop between OSSL111 and Boring should be tested with each PR & merge. Last successful run here

from oqs-provider.

Tagging @bhess : Is there anything in your mind that could explain this specific failure combination? I'm puzzled.

from oqs-provider.

Thanks @baentsch for the report. It seems that we don't register "oqs_kem_default" which explains why the second test fails.

I will take a closer look at p384_kyber90s768. Just to confirm: kyber90s768 (just KEM) and p384_kyber768 work fine? And was p384_kyber90s768 interop so far tested e.g. between BoringSSL and OSSL111?

from oqs-provider.

Thanks @baentsch, I could reproduce the issue.

It turns out that the origin is an incorrect claimed_security_level for kyber90s768 (1, should be 3), which is inherited from the upstream-yml:
https://github.com/open-quantum-safe/liboqs/blob/f8e339dcae8432b41e60621d25a4a3596bd14a14/src/kem/kyber/kem_kyber_768_90s.c#L18

Oqsprovider combines hybrids according to the claimed security level taken from the liboqs algorithm struct. So in this case, the hybrid used was actually p256/kyber90s768. The self-tests pass that way, but luckily we have the interop tests.

I can add two PRs to solve the issue: 1. in oqsprovider to register "oqs_kem_default", 2. in liboqs to correct the claimed security level (temporarily as a patch for copy-from-upstream to not block this here).
..and then a third one in pqcrystals to correct the yml-file used by copy-from-upstream.

from oqs-provider.

Thanks for finding the issue so quickly and looking forward to the PRs.

It turns out that the origin is an incorrect claimed_security_level for kyber90s768

This is a bummer. But then isn't there something more broken: If the claimed NIST level is wrong, why did the hybrid read "p384_kyber90s768" and not "p256_kyber90s768"? That mismatch would have been obvious immediately. In any case, this makes https://github.com/open-quantum-safe/liboqs/discussions/1011 moot.

from oqs-provider.

..and then a third one in pqcrystals to correct the yml-file used by copy-from-upstream

One more thought: Instead of doing a temporary patch in liboqs' copy_from_upstream (that will have to be reverted again) shouldn't it be quicker to correct it first in pqcrystals? For all I know that code base does not depend on this YML, so a fix should be seamless/quick to approve there, no? If that code base had used the YML (e.g., to generate the code constants), the error would never have occurred (or become obvious very fast with KATs failing), right?

from oqs-provider.

If the claimed NIST level is wrong, why did the hybrid read "p384_kyber90s768" and not "p256_kyber90s768"? That mismatch would have been obvious immediately.

It isn't optimal. The names (p384_..) are generated at compile time using the bit_security fields from https://github.com/open-quantum-safe/openssl/blob/OQS-OpenSSL_1_1_1-stable/oqs-template/generate.yml. The hybrid pairs are derived from the claimed_security_level which is available at runtime. We seem to not automatically sync these fields (which we should probably do/check from time to time) so it can lead to inconsistencies.
Since OSSL111/Boring use only the bit_security yml fields it doesn't affect them. I think we should do the same in oqsprovider to be more robust.

One more thought: Instead of doing a temporary patch in liboqs' copy_from_upstream (that will have to be reverted again) shouldn't it be quicker to correct it first in pqcrystals? For all I know that code base does not depend on this YML, so a fix should be seamless/quick to approve there, no? If that code base had used the YML (e.g., to generate the code constants), the error would never have occurred (or become obvious very fast with KATs failing), right?

The ymls from pqcrystals were added for oqs and yes I think their code base doesn't depend on it. I agree that it's better to not do a patch and revert it later again. If I do the fix mentioned above to only use bit_security in oqsprovider, the fix doesn't depend on fixing the claimed_security_level, which makes it not a blocker for here (although it should be quick to approve in upstream).

from oqs-provider.

Thanks & agreed to all of the above. FYI, I'm working on open-quantum-safe/openssl#315 (working around the issues you also point out makes this indeed a bit more convoluted than I originally thought). It'd be goodness if oqsprovider wouldn't have the same weakness (as per your suggestion in the fix). Nevertheless, this is a blocker for liboqs.

from oqs-provider.