Add support for hybrid-PQ key exchange with x25519 #169
Conversation
This adds support for hybrid-PQ key exchanges with x25519. This allows for the implementation of `mlkem768x25519-sha256` as defined by [draft-kampanakis-curdle-ssh-pq-ke-02](https://datatracker.ietf.org/doc/draft-kampanakis-curdle-ssh-pq-ke/) and `[email protected]` as defined by upstream OpenSSH. We also take the opportunity to add hybrid implementations for all existing PQ key exchanges which supported NIST P-256. Due to the conflicting implementation for `[email protected]` we omit an OQS exclusive version for now and will plan for it in a future PR. Unlike in `oqs-provider`, we cannot provide support for x448 hybrid algorithms since the x448 algorithm is not available within OpenSSH. The way this all works is by introducing a new source file `kexoqsx25519.c` which is a synthesis of `kexoqsecdh.c` and `kexsntrup761x25519.c`. These files provide example implementations of hybrid-PQ for OQS-backed algorithms and x25519 usage. In that source file, we define functions to implement OpenSSH's KEX interface for each hybrid algorithm using an `oqs-template` file. Within the `generate.yml`, we add a new boolean key to flag `x25519` hybrids similar to how the `rsa` key works for hybrid signatures. Related to issue open-quantum-safe#163. Signed-off-by: Gerardo Ravago <[email protected]>
There was a problem hiding this comment.
Basically LGTM. Again, explanation and test process description is very clear: Thanks! Code also seems OK. The "doubly" tagging x25519 in generate.yml does not seem user-friendly, though: What about the idea to only mandate one of the two and generate the other within generate.py? That way, consistency checks (for/or user errors) can be avoided and your code-gen logic retained. Last question: Any chance the tests you mentioned can be added to the CI chain for "continuous live CI"? We do something similar in oqsprovider...
I totally agree with you and don't like it myself either. The choice was driven by the precedent set for RSA hybrid KEX signatures here (and all the related usage patterns). While it may look nicer to change it for the PR, it proliferates two different ways of accomplishing the same thing in this code base which is also undesirable for readability/maintainability.
That's a good idea, but unfortunately it does require some persistent resources to exist and be paid for somewhere. I don't have a good place for our team to own/maintain/secure it long-term right now, but it is an interesting idea for ways to host an integration test endpoint for SSH. I'll float it up with the team. |
ACK. Then allow me to suggest creating an issue for this: Could be labelled "refactoring generator code" (with concrete suggestion what to change). May also help posterity (or anyone willing to get their feet wet in the code as a way to get started)...
Well, we already have "test.openquantumsafe.org" and running an OpenSSH test endpoint there doesn't sound outlandish. Or is that bespoke AWS software that would cause worldwide server outages or other allergic reactions on either side when run on an "IBM cloud" VM? :-) |
Unfortunately, this is a closed-source implementation for our managed file transfer service (tl;dr - it exposes an SFTP front-end for reading/writing to AWS managed storage like S3). The only way this would work is if we had one of these managed endpoints running in an AWS account and a CNAME record in your DNS zone file pointed to it. Honestly, it's less of a technical challenge than it is a bureaucratic one. |
This adds support for hybrid-PQ key exchanges with x25519. This allows for the implementation of
mlkem768x25519-sha256as defined by draft-kampanakis-curdle-ssh-pq-ke-02 and[email protected]as defined by upstream OpenSSH. We also take the opportunity to add hybrid implementations for all existing PQ key exchanges which supported NIST P-256. Due to the conflicting implementation for[email protected]we omit an OQS exclusive version for now and will plan for it in a future PR. Unlike inoqs-provider, we cannot provide support for x448 hybrid algorithms since the x448 algorithm is not available within OpenSSH.The way this all works is by introducing a new source file
kexoqsx25519.cwhich is a synthesis ofkexoqsecdh.candkexsntrup761x25519.c. These files provide example implementations of hybrid-PQ for OQS-backed algorithms and x25519 usage. In that source file, we define functions to implement OpenSSH's KEX interface for each hybrid algorithm using anoqs-templatefile. Within thegenerate.yml, we add a new boolean key to flagx25519hybrids similar to how thersakey works for hybrid signatures.Related to issue #163.
Testing
In addition to the CI checks, I performed interop testing with the AWS Transfer for SFTP service's PQ support. The snippet below opens an SFTP connection to an AWS Transfer for SFTP server using the
[email protected]algorithm.