Created attachment 3264 [details] Use SSH KDF from OpenSSL The new OpenSSL 1.1.1b implements the SSH KDF [1], which should be preferably used in (portable) OpenSSH instead of the internal implementation. The attached patch implements alternative derive_key() function inside of kex.c, which is compiled in when the new KDF API in OpenSSL is detected during build time. [1] https://www.openssl.org/docs/manmaster/man7/EVP_KDF_SSHKDF.html
I don't see any advantages to using an external implementation of a core piece of the SSH protocol.
One big advantage to having the option to offload SSH KDF to OpenSSL is potential easier FIPS compliance. Assuming OpenSSL goes through FIPS validation where its SSH KDF implementation is FIPS validated, then if OpenSSH was to offloads its KDF to OpenSSL one could claim "FIPS Inside" for OpenSSH. As of today this is not possible because key derivation is done by OpenSSH, not by OpenSSL.
A general solution would be to put the cryptographic primitives used by OpenSSH into their own shared library so that someone who desires to create a cryptographic boundary around it would be able to do so. In this way, an OpenSSH built with --without-openssl could still be functional and become a stand-alone cryptographic module. I fully expect that NIST FIPS 186-5 will be published soon and will provide for a number of new algorithms which will also include ed25519, ed448 and chacha20-poly1305 in addition to the current set. The future may also hold curve25519 and curve448 even though they seem not to be in the next set of FIPS documents. Making these algorithms easy to test via the Automated Cryptographic Validation Testing URL: https://csrc.nist.gov/Projects/Automated-Cryptographic-Validation-Testing would seem to be generally useful to me in the long run as it would provide for fully exercising the cryptographic primitive implementations. Isolation of the algorithms from the SSH protocol may also allow for better optimization of these primitives and include the possibility of using acceleration instructions like AES (AES-NI) and SHA (SHA-NI) instructions available for some kinds of CPU (AMD, ARM, Intel, etc.)
Just as an fyi, for those watching this enhancement request, some Linux vendors have started using SSHKDF from OpenSSL. Source: https://www.suse.com/support/update/announcement/2020/suse-ru-20200581-1/
closing resolved bugs as of 8.6p1 release