Interoperability with oqs-openssl? about oqs-provider HOT 9 CLOSED

We then "just" need to have an RFC for that for all QSC schemes...

I also think this could be addressed after the Internet draft on key serialization is published (perhaps for a next milestone after a November release).

Until that perhaps keep it with the current scheme to not complicate things.

from oqs-provider.

Maintenance/"dev care and attention" of/for oqs-openssl111 seems to be less than that of oqs-provider (see for example open-quantum-safe/liboqs#1331 (comment)). Therefore dependence on interop with oqs-openssl seems wasteful. Thus this comment is to suggest dropping this issue. Objections anyone?

from oqs-provider.

After discussion and thinking about it, I don't see interop between 1.1.1 and 3.0 as being that important, on that matter. Emulating the coding style of other 3.0 alg implementation is highly desirable; how are they, e.g., encoding the EC keys?

from oqs-provider.

how are they, e.g., encoding the EC keys?

As far as I recall from checking it out at the start of the "provider endeavour" , all EC logic got transferred 1:1 from OSSL111 to (default, i.e., OSSL-internal/classic crypto) provider. But we could check again/in more detail...

from oqs-provider.

But we could check again/in more detail...

Here's (exemplary for x25519) proof to my statement above:
From default provider registration -> provider (dispatch) implementation -> code actually running: The latter is located in crypto/ec, i.e., within the original OpenSSL crypto lib (pre-provider times). As proof for that, here's the link to the same code in OSSL111: Names changed, but otherwise the same code (incl. the comment). Very similar approaches exist for all aspects of providers. And I can understand that: Why change running, arguably "battle-tested" code?

from oqs-provider.

I copied the pattern of the x25519 implementation when first integrating OQS into OpenSSL; so doing the same now sounds like a good strategy.

from oqs-provider.

Some PQC schemes already store the public key as part of their private key blobs. Persisting always the public key blob along with the private key is then even less efficient when the public key is stored twice. With the current opaque key format is no way for OQS to do anything about this.
A more structured key format would help, e.g. an encoding analogous to PrivateKeyInfo in RFC5958. The optional public key field will allow to "recreate" the public key without having to store it separately.

from oqs-provider.

A more structured key format would help

Completely agree. We then "just" need to have an RFC for that for all QSC schemes... Until that's generally available, shall we keep using the current "double-and-triple-store public keys scheme" OR computationally establish public/private key match for those schemes that don't store public keys within private key data (and do memcmp for those that do -- assuming we know which ones those are)? The latter option probably preferably require some new liboqs API ("extract_public_from_private_key" or so): That API could be extended/implemented over time with one in line with the above mentioned RFC without changing liboqs-based apps/libs again.

from oqs-provider.

This is a reminder that the use of RSA PKCS#1 v1.5 padding (for hybrid signatures) is something to reconsider (see #40):

from oqs-provider.