key component order in hybrid keys

[petrovr]

Documentation "Internet-Draft":

1. • Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
2. • PQ/T Hybrid Key Exchange in SSH

According documentation X25519MLKEM768(see 1) group match mlkem768x25519-sha256(see 2) key exchange.

The difference is between "SecP256r1MLKEM768" and "mlkem768nistp256-sha256" and "mlkem1024nistp384-sha384" from (2). SSH draft defines always classical(traditional) key as second. TLS draft puts P-256 first in SecP256r1MLKEM768, as reason is in (1).

Also oqs-provider defines "p384_mlkem1024" using rules from (1).

Question (defect, enhancement) is how to use oqs-provider to get key order according specifications.

---

Unlike #572 this is specific to some hybrid definitions.

[baentsch]

Ouch. Are you saying that the TLS RFC for the same hybrid combination requires a different concatenation order (plus a hash) than the SSH RFC? A quick glance over both documents seems to confirm this:

https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-10:

concatenated_shared_secret = MyECDH.shared_secret || MyPQKEM.shared_secret

vs

https://datatracker.ietf.org/doc/html/draft-kampanakis-curdle-ssh-pq-ke/

K = HASH(K_PQ || K_CL)

--> This clearly is currently not supported by oqsprovider: It only caters for the TLS1.3 KEM use case.

That said, it should be possible to define a different(ly named) hybrid supporting the SSH semantics -- but that requires code changes... Thus, the enhancement label seems appropriate....

[petrovr]

For protocol just published second part from pkix-ssh [hybrid-demo] (https://gitlab.com/secsh/pkixssh/-/commits/hybrid_demo), commits

• HYBRID-DEMO: add experimental PKEY based hybrid post-quantum key exchange ML-KEM768 with P256 and P384
• HYBRID-DEMO: swap keys hack

Quite from "hack": interoperability test between asyncssh as client and pkix-ssh as server pass.

[petrovr]

Let put "on hold" any implementation attempts (enhancements) in "oqs-provider".

I'm still thinking about model to use. One possible model uses two pkeys.

[baentsch]

Let put "on hold" any implementation attempts (enhancements) in "oqs-provider".

Completely agree.

I'm still thinking about model to use. One possible model uses two pkeys.

That's the approach pursued in OpenSSL: openssl/openssl#25884

[baentsch]

@dstebila As you are the author of both specs, can you shed some light on this: It seems you intentionally created different logic for what's conceptually the same thing: Why? The below is a bit shy on details:

This is similar, but not the same (for efficiency), logic as in TLS 1.3 [I-D.ietf-tls-hybrid-design]. In [I-D.ietf-tls-hybrid-design], the classical and post-quantum exchanged secrets are concatenated and used in the key schedule whereas in this document they are concatenated and hashed before being used in SSH's key derivation methodology

Is your expectation that a "hybrid" implementation takes an option to differentiate the "flavour" to support both? Or would there be a rationale for completely separate implementations? What's your expectation how (whether?) oqsprovider should handle either (or indeed, both)? In my eyes TLS hybrid logic always took preference, neglecting SSH hybrids.

Or even more generally, in which way do you envision OQS cares about SSH using (want to support use of?) openssl (and oqsprovider in turn) in this regard? Could you see a way to streamline the support for "oqs-openssh" by way of using oqsprovider instead of a bespoke fork if we'd find a way to bring these hybrids "together" somehow? Apologies for the possibly silly questions -- I never really looked into that (code/project) relationship...

[dstebila]

In a sense, TLS also hashes the concatenated shared secrets together, it's just that that operation is already part of the existing TLS key schedule (HKDF.Extract to get handshake secret), whereas SSH does not have a key schedule in between the raw shared secret derivation and the next level of the SSH key exchange computations (called the "exchange hash"), so the SSH draft explicitly hashes the concatenation before feeding it up to the "exchange hash" portion of the protocol. Of course in TLS one could hash the raw concatenation before feeding it up to the existing TLS key schedule; but that introduces an extra hash computation, increasing cost.

I'm struggling to understand the rest of your comment. Right now, oqs-provider does several things, including: exposing un-hybridized KEMs via the EVP API; and adding hybrid key exchange groups to TLS 1.3 key exchange in OpenSSL. SSH implementations needing to build hybrid key exchange to implement the SSH draft can do so by separately calling the un-hybridized KEMs via the EVP API, regardless of whatever hybridization post-processing is done in the TLS 1.3 hybrid key exchange portion of oqs-provider.

Unless you are asking if oqs-provider should add new functionality exposing hybridized KEMs via the EVP API, in which case the question becomes: what hybridization format/flavour? Each hybridization format/flavour effectively has 3 choices: how to hybridize public keys, how to hybridize ciphertexts, and how to hybridize shared secret calculation. If this is what you are wanting to do, then unfortunately yes, one would require differentiating between different hybridization formats/flavours:

• TLS (concatenation, concatenation, concatenation)
• SSH (concatenation, concatenation, concatenate-then-hash)
• X-Wing (concatenation, concatenation, concatenate shared secrets with some but not all public keys / ciphertexts, then hash)
• probably also the composite and/or hybrid KEMs in LAMPS, which I haven't kept up on the design of

[baentsch]

Thanks for the background @dstebila .

SSH implementations needing to build hybrid key exchange to implement the SSH draft can do so by separately calling the un-hybridized KEMs via the EVP API

Good solution. It'd be nice if the provider hybrid code doesn't get even more convoluted and hard to grasp by adding another option just for SSH.

If this is what you are wanting to do, then unfortunately yes, one would require differentiating between different hybridization formats/flavours

I don't want to do it; the thought crossed my mind that it may be a "friendly" option that might eliminate "the need" for OQS maintaining a separate SSH fork and SSH users having to write separate code. But then again, I don't know enough about (Open)SSH to judge whether this is realistic/possible.

Either way, OK to close the issue as per the recommendation by @dstebila above, @petrovr ?

[petrovr]

PKIX-SSH is different project that uses OpenSSL EVP API in preference while OpenSSH still produce code with deprecated in OpenSSL 0.9.8 (released in 2005) API.

Using EVP API plus PKEY allows easily to integrate functionality profiled by cryptographic library.
Key takeaways from PKIX-SSH HYBRID-DEMO are:

1. Encapsulation API is usable.
2. Some non-significant functions fail.
3. Does not exist "description" functionality.

 
About (2) - Issue #570 means that code must use context based key generation as this is working with releases in production. Issue #569 is not significant as is only for debug and content could be extracted differently.

 
About (3) - Currently hard-coded "composite" algorithms are suitable for TLS . It seems to me it is two line issue - to duplicate exiting one and to drop "reversion" flag. This is applicable when is used P-256 and P-384 (*).

 
Lack of "description" functionality mean that third party code cannot define own "composite" algorithm. It could use
SecP256r1MLKEM768 and p384_mlkem1024 but must "swap" content send to remote and received from remote.

Another point is #572. It seems to me code may use "....encoded..." function instead "...raw..." one (**).

---

Dilemma: To use (*) and (**) with exiting functionality or to implement own composite algorithm.

It seems to me second one ensure easy integration with functionality already delivered (existing OS packages).
Use of own(custom) composition will require only ML-KEM-NNN to be provided by cryptographic library. Alternative is dynamic load of library that support mlkem.

---

Conclusion: Hybrid Key Exchange in SSH requires only 3 new description records in oqs-provider but I'm not sure who will use this.
AsyncSSH loads dynamically oqs library with own "concatenation" while in PKIX-SSH I will use only mlkem provided by cryptographic library.

---

Off-topic: final "digest" - it is part of another expired draft with "Streamlined NTRU Prime" i.e., used in existing ssh programs that implements it. So those programs need only TLS like functionality to exist and should reuse "digest" specific to ssh.