Update supported algorithms

[geedo0]

The supported algorithms here no longer align with the supported algorithms in liboqs here. We need to update the algorithms supported in the OpenSSH OQS fork back in line.

I went through the two lists by hand to identify all the mismatches since the last time these algorithms were updated. I can use some help from the maintainers as to how these newer algorithms should be brought into OpenSSH. Some specific questions off the top of my head:

• If they should be brought in at all.
• How they should be named/renamed.
• Hybrid/Hash pairing for the algorithms.

Listing of algorithms that exist in liboqs, but not in OpenSSH and some initial notes/thoughts:

• BIKE Round-4
  • Adds a new parameter set BIKE-L5.
  • Existing KEX names are qualified with r3 and need to be updated.
• ML-KEM and ML-DSA IPD
  • Forthcoming NIST standards for Kyber/Dilithium.
  • Follow conventions set by the pre-NIST implementation?
  • Some names/pairings are proposed here
  • The security levels in the draft RFC do not align on the security levels which is the convention followed by the OQS library
  • The draft RFC uses x25519, need to figure out how to wire that up.
  • The IPD version exists in OQS and an alias without the IPD qualifier is provided.
• sntrup761
  • This would allow interop with upstream OpenSSH
  • Also would conflict with upstream OpenSSH implementation
  • Upstream name sntrup761x25519-sha512@openssh.com
• Falcon PADDED format
  • Existing KEX uses the COMPRESSED format.
• MAYO
  • New signature algorithm
• XMSS and LMS
  • Stateful algorithms not suitable for SSH signatures.

[baentsch]

At the time when oqs-openssh and oqs-openssl were equally well supported by OQS, their code-generator scripts were closely in sync, thus creating a very similar user "config experience".

And that's what I'd suggest trying to achieve again. If you could subscribe to this goal, @geedo0 , please check out the oqsprovider code generator config file: It documents "user-level" algorithm names, incl. hybrid and composite ones, incl. the "co-related" classic algs' strengths. If you don't like to work with .yml, this file is generated from it for better readability.

As per your specific per-algorithm questions, my suggestions would thus be as follows:

• Bike, Mayo, Falcon, ML-KEM/DSA: Use oqsprovider config as-is (i.e., add new "openssh" alg monikers; in the case of ML-*, oqsprovider promises to shield its users from any NIST last-minute changes in that the name will persist, but the algorithm logic will adapt to any changes in spec. In other words, mlkem/mldsa can be requested by users and currently will be implemented by the -ipd code and in the future by a possibly different, finally standardized, code. )
• sntrup761: That's a challenge -- but its use in openssh is actually the only reason why liboqs still supports it. My personal preference would be to see what it takes to achieve interop with the version openssh anyway supports (e.g., by way of creating an "oqssntrup761x25519" hybrid and running that against what "baseline" openssh has built-in). If this were possible, we should pause and talk: Personally, I'd then completely drop "sntrup761" from OQS for good. If this were not possible, well, we also need to talk and understand what's the problem then. Personally, I'd most likely suggest checking whether that variant would interop with the "oqs-opensshv8" version -- and if so, keep it. If not, drop it (why keep something that cannot talk with anything else?).
• XMSS/LMS: Unusable

[geedo0]

Yes, that's exactly the goal I had in mind. Get OpenSSH up to date and back in-line with the other OQS projects.

From your oqsprovider pointer, getting the new algorithm support in-line ooks straightforward. The only new issue I noticed is that there are hybrid algorithms for x448/x25519, this would be new development for the OpenSSH fork. Here's a proposal for the plan of attack:

1. Add missing algorithm support for Mayo, Bike, Falcon, ML-KEM, ML-DSA with conventional naming/hybrids.
2. Rename Bike to use the round 4 qualifier.
3. Match ML-KEM's naming and hybrids to the draft RFC's specifications (omit x25519 implementation for now).
4. Look into the work around sntrup761 and align on a path forward for OQS.
5. Look into x448/x25519 support for oqs-openssh.

I've got the items 1-3 on-deck, but need to get PR #161 and #162 merged before I can submit.

[tttekk]

Thank you for your hard work. I am studying this project. I have some concerns about the following function, so I would like to post it. If you have already noticed this, please discard it.

kex_kem_generic_with_x25519_enc

  /* generate and encrypt KEM key with client key */
  if (OQS_KEM_encaps(kem, public_key, private_key, client_pub)
      != OQS_SUCCESS) {
+   r = SSH_ERR_LIBCRYPTO_ERROR; // I don't know if this definition is good.
    goto out;
  }
  client_pub += kem->length_public_key;
  public_key += kem->length_ciphertext;
- private_key += kem->length_shared_secret; // I think this is unnecessary.

[geedo0]

Feel free to drop that as a comment directly on PR #169 which is still open. I agree that incrementing private_key is unnecessary. The error code is more subjective. Looking at ssherr.h, there doesn't seem to be a better error code than SSH_ERR_LIBCRYPTO_ERROR which suggests an error in the underlying libcrypto (i.e. OpenSSL). In this case, I understand that the library that's returning an error is liboqs but I'd prefer the more precise albeit slightly inaccurate error code over SSH_ERR_INTERNAL_ERROR or introducing a whole new series of error codes for this.

[geedo0]

Algorithm support is now fully in sync with liboqs.