Add [email protected].

[jas4711]

Hi. This is work in progress, but I'm opening up a merge request for wider review and feedback. Let me know if this use of a merge request is inappropriate.

All feedback is welcome, but I'm requesting help to resolve these questions:

• How to de-duplicate the duplicated code between kexsntrup761.c and kexmceliece6688128.c? What method is preferred here? Some ideas:
  • Rename kexsntrup761.c to kexpq.c, parametrize the functions, and add stubs for both sntrup761 and mceliece6688128.
  • Inside kexmceliece6688128.c do some #define dance and then #include <kexsntrup761.c>.
  • Move most of kexsntrup761.c to a new kexpq.c that is parametrized and add stubs in kexsntrup761.c and kexmceliece6688128.c.
  • Other approaches?
• It would be nice to add GitHub Action workflow that uses libmceliece, to test that it builds with system-installed libmceliece.
• Use a better KEM combiner than SHA512. See https://gitlab.com/jas/ietf-ssh-mceliece/-/issues/1

A specification for the protocol is available here: https://datatracker.ietf.org/doc/html/draft-josefsson-ssh-mceliece

[djmdjm]

@mfriedl

A more fundamental question is: why another lattice PQ KEM? We intend to add add Kyber soon. That would give OpenSSH a LWE PQ KEM (Kyber) and a lattice PQ KEM (Streamlined NTRU Prime). Why McEliece too?

Re regression testing: basic testing of all key exchange algorithms is built in to the regression tests run by make tests. Simply adding support for the algorithm should be enough to get it some testing. If you want to run the tests that exercise key exchange specifically then make t-exec LTESTS="kextype rekey" will do it.

Is there a SUPERCOP implementation of this algorithm? If so, extracting it into the same source file as sntrup (and renaming it) might avoid some duplication.

[jas4711]

Thanks for feedback! Indeed choice of algorithms is a fundamental bigger question.

A more fundamental question is: why another lattice PQ KEM? We intend to add add Kyber soon. That would give OpenSSH a LWE PQ KEM (Kyber) and a lattice PQ KEM (Streamlined NTRU Prime). Why McEliece too?

Classic McEliece is code-based, and one argument for McEliece is to have at least one non-structured lattice-based KEM. Both Kyber and SNTRUP share some similarities: https://ntruprime.cr.yp.to/warnings.html

Yes, Classic McEliece is in SUPERCOP and the same code is inside the reduced-focus libmceliece - https://lib.mceliece.org/ - so I think it would be possible to extract a slimmed down implementation much like sntrup761.c. I'm happy with relying on libmceliece, but I'm also happy to work on a mceliece6688128.sh script if an embedded implementation is important.

I see Classic McEliece as a conservative fall-back algorithm with a long history in crypto research; significant improvements to attacks would be more remarkable than attacks on all KEMs that popped up for the last 10 years. See nice graph on historic attacks on lattice vs McEliece here: https://classic.mceliece.org/comparison.html

Two other code-based KEMs would be alternatives: BIKE and HQC, however they don't nearly have the same long history as Classic McEliece and thus doesn't offer a lot compared to SNTRUP761 or Kyber768 which are also new. BIKE and HQC offer shorter public keys than McEliece, though, but if we have sntrup761/kybe768 as state-of-the-art KEMs, it may make sense to focus remaining efforts on a conservative alternative. See https://en.wikipedia.org/wiki/NIST_Post-Quantum_Cryptography_Standardization#Round_four

[jas4711]

Hi. I've pushed an update in 639c178

This adds a mceliece6688128f.sh script that extracts a standalone mceliece6688128f.c from libmceliece, which is used when the system doesn't have libmceliece. Now GitHub Actions actually test mceliece connections.

This is also built on GitLab -- https://gitlab.com/gsasl/openssh-portable/-/pipelines -- on Debian with/without libmceliece from unstable, and on macOS. You can see performance numbers at the end of each CI/CD job, summarized here:

amd64 with libmceliece from Debian
https://gitlab.com/gsasl/openssh-portable/-/jobs/5828261508
X25519 8 seconds SNTRUP761 17 seconds MCELIECE6688128 18 seconds

macOS 13 with mceliece6688128f.c
https://gitlab.com/gsasl/openssh-portable/-/jobs/5828261510
X25519 32 seconds SNTRUP761 41 seconds MCELIECE6688128 56 seconds

amd64 with mceliece6688128f.c
https://gitlab.com/gsasl/openssh-portable/-/jobs/5828261507
X25519 9 seconds SNTRUP761 16 seconds MCELIECE6688128 71 seconds