[ssh_x509] Post-Quantum Traditional (PQ/T) hybrid key exchange methods - phase1

[ssh_x509 at roumenpetrov.info]

Hello,

I would like to inform you on the status of the hybrid key exchange 
method in PKIX-SSH.


A) History
1.) 18 Apr 2019
First implementation is based on "Streamlined NTRU Prime 4591^761" PQ 
algoritm for key encapsulation coupled with x25519 i.e.,
traditional diffie-hellman with curve25519.
It appears in PKIK-SSH 12.0 and method is disabled by default.

2.) 3 Mar 2021
PKIX-SSH 13.0 release replaces "Streamlined NTRU Prime" sntrup4591761 
with sntrup761.
Implementation has to be enabled at build time and is not enabled by 
default in configuration.

2.1.) 11 Apr 2022
PKIX-SSH 13.3.2 adds method to default configuration.
Note implementation has to be enabled at build time.

3.) 3 Oct 2024
PKIX-SSH 15.0 adds Module-Lattice based key encapsulation with level 768 
ML-KEM-768 coupled with x25519.
The release switch "Streamlined NTRU Prime" from "reference" to faster 
"compact" implementation.
Implementations has to be enabled at build time.

4) 8 Mar 2025
PKIX-SSH 16.0 implement key exchange method x25519 using generic "ECX" 
support from cryptographic library (OpenSSL 1.1.0, 25 Aug 2016).
The release update build-in ML-KEM-768 implementation with corrections 
for big-endian systems.


B) Issues
1.) integration model
All above algorithms are snapshot export from an reference 
implementation and build statically.
For a long period of time imported code remains as is.

2.) maintenance
Reference implementations does not provider stable API.
Using another snapshot requires a lot of work to integrate with the 
existing code base.

3.) security fixes
Nobody monitors reference implementation for security fixes not 
improvements.
Note that 1.) and 2.) prevent easy backporting of security fixes, if any.

4.) security review
Algorithms implemented by widely used cryptographic library are well tested.
Widespread use leads to in-depth code review.
Side effect is improved security.

5.) performance
A lot of algorithms in the widely used cryptographic library are 
implemented in assembler for fast performance.

6.) code compatibility
PKIX-SSH code is C89 compatibly with few C99 extension.
This is not the case with imported code.
For instance imported ML-KEM requires a lot of modern C functionality 
i.e., modern compiler.
Empirically testing compiler's capability with result that silently 
ignores imported code is not a user-friendly option.


Main conclusion:
To minimize use of imported code and use functionality from 
cryptographic library.
This includes model that allows user to setup build of imported code but 
excludes easy activation from configuration.
Also setup is not documented. User should review code and to find how to 
build code.
If compilation fail user should find suitable compiler or to arrange 
compiler options that build imported code.



Remark: ECX support in PKIX-SSH 16.0 eliminates part of issues above - 
Curve25519 support by cryptographic library.


Regards,
Roumen Petrov