Closed geedo0 closed 2 weeks ago
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:
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. )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?).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:
oqs-openssh
.I've got the items 1-3 on-deck, but need to get PR #161 and #162 merged before I can submit.
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.
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.
Algorithm support is now fully in sync with liboqs.
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:
Listing of algorithms that exist in liboqs, but not in OpenSSH and some initial notes/thoughts:
BIKE-L5
.r3
and need to be updated.sntrup761x25519-sha512@openssh.com