Interoperability with oqs-openssl?

[baentsch]

Unlike OpenSSL 1.1.1, OpenSSL3.0 permits EVP keys that do not have both public and private key material. Therefore, supporting only "half" PK key pairs as EVP keys makes sense. This also allows for loading (and storing) "true" private EVP OQS keys now. This in turn in in contrast with the oqs-openssl implementation of storing (persisting) public key material together with private key material.

This issue is about discussing whether we should (also) do this in oqs-provider, ensuring interoperability with oqs-openssl-generated (persistent) data or whether we want to be more efficient and only store private key material in oqs-provider EVP keys, but thus breaking interoperability between oqs-provider and oqs-openssl(1.1.1).

The question also will be how to match private and public keys via the provider: Simply comparing key material (as is possible now), doing actual sign/verify operations, or some "hybrid" (hashing) based approach. Example code currently here.

Already extending the feature set is that oqs-provider supports more hybrid KEM mechanisms. But for full TLS signature operations oqs-openssl will remain more relevant until openssl/openssl#10512 is resolved thus making interoperability between oqs-openssl and oqs-provider desirable for users (of most functionality and future-proof OpenSSL).

Thoughts welcome, @dstebila @christianpaquin

[christianpaquin]

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?

[baentsch]

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...

[baentsch]

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?

[christianpaquin]

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

[bhess]

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.

[baentsch]

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.

[bhess]

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.

[bhess]

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

[baentsch]

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?