Damien Miller
2020-Dec-09 23:29 UTC
[PATCH] cipher: fix dhgex for non-GCM ciphers for OpenSSL 3.0
On Tue, 8 Dec 2020, Marc Kleine-Budde wrote:> On 12/7/20 5:10 PM, Marc Kleine-Budde wrote: > > On 12/4/20 3:36 AM, Darren Tucker wrote: > >> Thanks for the investigation. > >> > >>> The issue is that openssh needs the "current" IV state (which the > >>> now-deprecated EVP_CIPHER_CTX_iv() used to return), but it's calling the > >>> wrong openssl function to obtain it. > >> > >> It's not that simple. > >> > >> In 2018, LibreSSL added EVP_CIPHER_CTX_get_iv ( > >> https://github.com/libressl-portable/openbsd/commit/db321d7792) which > >> returns the current IV, and OpenSSH has been using it ever since. > >> > >> In 2020, OpenSSL added a function of the same name ( > >> https://github.com/openssl/openssl/commit/79f4417ed94) which behaves > >> differently. Maybe OpenSSL could change it before 3.0 instead of shipping > >> an incompatible API? EVP_CIPHER_CTX_get_original_iv would be consistent > >> with the function they deprecated. ie > >> > >> EVP_CIPHER_CTX_get_iv -> EVP_CIPHER_CTX_get_original_iv > >> EVP_CIPHER_CTX_get_iv_state -> EVP_CIPHER_CTX_get_iv > > > > I tried to wrap up the problem and created an openssl issue: > > > > https://github.com/openssl/openssl/issues/13631 > > Which turned out to be a duplicate of > > https://github.com/openssl/openssl/issues/13411 > > Are you interested in another take on a patch to fix OpenSSH with the current > OpenSSL-3.0?It looks like OpenSSL are considering renaming the API. I think we can wait for them to make up their minds before proceeding. If the go ahead with the plan to rename EVP_CIPHER_CTX_get_iv_state to get_running_iv then the fix will be a single #define in one of our compat headers AFAIK. -d
Marc Kleine-Budde
2020-Dec-10 07:43 UTC
[PATCH] cipher: fix dhgex for non-GCM ciphers for OpenSSL 3.0
On 12/10/20 12:29 AM, Damien Miller wrote:>> Are you interested in another take on a patch to fix OpenSSH with the current >> OpenSSL-3.0? > > It looks like OpenSSL are considering renaming the API. I think we can wait > for them to make up their minds before proceeding. If the go ahead with > the plan to rename EVP_CIPHER_CTX_get_iv_state to get_running_iv then the > fix will be a single #define in one of our compat headers AFAIK.Yes, but the name of EVP_CIPHER_CTX_get_iv_state(), EVP_CIPHER_CTX_get_running_iv() or something else is not the only problem. The other problem is the going-to-be-renamed OpenSSL function EVP_CIPHER_CTX_get_iv(). See my patch on trying to work around this with the current situation: https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-December/039008.html Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20201210/580e9001/attachment.asc>