This is a follow-up to
When building Erlang on RedHat/CentOS/Fedora-based systems with the default OpenSSL library, a number of elliptic curves are listed as supported, but result in a runtime error when referenced in Erlang code.
This appears to impact crypto when using RHEL/CentOS/Fedora OpenSSL libraries, which are built with FIPS support (but not with it turned on, or with enabled in the Erlang build via --enable-fips). Here are some example systems that are impacted:
- OpenSSL 1.0.1e-fips 11 Feb 2013 (CentOS release 6.9)
- OpenSSL 1.0.2k-fips 26 Jan 2017 (Amazon Linux AMI release 2017.09)
- OpenSSL 1.0.2k-fips 26 Jan 2017 (Amazon Linux AMI release 2018.03)
I haven't done a thorough examination, but I suppose that this impacts the "system" OpenSSL for most if not all RHEL/CentOS/Fedora releases (and derivatives, like Amazon Linux) over the past 5 years.
The following curves result in a runtime error:
On the other hand, these similar curves function as expected:
This appears to be due to an intentional limitation of OpenSSL with the OPENSSL_FIPS set, even if it is not explicitly enabled. It may be limited to RHEL/CentOS/Fedora-based OpenSSLs, but I am not sure. I've noticed this commit in OTP: Check the result of EC_GROUP_new_curve_* calls:
The FIPS-enabled OpenSSL on RHEL disallows the use of < 256 bit prime
fields (like secp128r1 or secp160k1), and the EC_GROUP_new_cuve_GFp
call would return a NULL pointer for such fields. Not checking for
this failure could result in a segfault in the NIF code.
The commit above observed the issue, but it looks like it just returns an error when these curves are used. It seems like it would be preferable to disable support for these non-functioning curves when this OPENSSL_FIPS header is defined.
The following example code can be used to demonstrate this problem.
When I run this on the outputs of the curves in crypto:ec_curves/0, I get this result: