Thread: BUG #16815: Unable to use the X448 an X25519 elliptic curves.

The following bug has been logged on the website:

Bug reference:      16815
Logged by:          - -
Email address:      frank.buettner@mdc-berlin.de
PostgreSQL version: 13.1
Operating system:   CentOS8
Description:

The openssl version that comes with CentOS8 will support both curves.
And using the curves with the apache for example will work, so it is not an
OS related problem.
SSLOpenSSLConfCmd Groups "X448:X25519:secp521r1:secp384r1" will work.
But try the same curves on postgresql 13 will fail.
ssl_ecdh_curve  = 'X448' or
ssl_ecdh_curve  = 'X25519'
will fail with:
FATAL:  ECDH: could not create key
using the lower X it fails with:
FATAL:  ECDH: unrecognized curve name: x25519
Only the NIST ones like secp521r1 will work.

It looks like the curves with the upper X are known, but not correct
initialized.

PG Bug reporting form <noreply@postgresql.org> writes:
> The openssl version that comes with CentOS8 will support both curves.
> And using the curves with the apache for example will work, so it is not an
> OS related problem.
> SSLOpenSSLConfCmd Groups "X448:X25519:secp521r1:secp384r1" will work.
> But try the same curves on postgresql 13 will fail.
> ssl_ecdh_curve  = 'X448' or
> ssl_ecdh_curve  = 'X25519'

According to the fine manual, the allowed values for ssl_ecdh_curve
on a given system can be found out with "openssl ecparam -list_curves".
When I do that on a RHEL8 or CentOS8 system, I get

$ openssl ecparam -list_curves
  secp224r1 : NIST/SECG curve over a 224 bit prime field
  secp256k1 : SECG curve over a 256 bit prime field
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field

I have no idea what X448 and X25519 are, but they don't seem
to be known in a default Red Hat installation.  It's entirely
possible that the Apache config command you show above is
"working" because it ignores unknown entries.  (But I know zip
about Apache, so I might be wrong.)

            regards, tom lane

PG Bug reporting form <noreply@postgresql.org> writes:
> It looks like the curves with the upper X are known, but not correct
> initialized.

BTW, as far as that goes, I looked into the source code and found

    nid = OBJ_sn2nid(SSLECDHCurve);
    if (!nid)
    {
        ereport(isServerStart ? FATAL : LOG,
                (errcode(ERRCODE_CONFIG_FILE_ERROR),
                 errmsg("ECDH: unrecognized curve name: %s", SSLECDHCurve)));
        return false;
    }

    ecdh = EC_KEY_new_by_curve_name(nid);
    if (!ecdh)
    {
        ereport(isServerStart ? FATAL : LOG,
                (errcode(ERRCODE_CONFIG_FILE_ERROR),
                 errmsg("ECDH: could not create key")));
        return false;
    }

So it would appear that "X448" and "X25519" are known as names for
*some* sort of thing known to OpenSSL, but they aren't ECDH curves.

            regards, tom lane

Hi Tom,

after looking in the API of openssl, I see, that this curves use another
API part of openssl. They use the EVP_... calls of openssl.
See https://www.openssl.org/docs/manmaster/man7/X448.html for more.

This will be the reason, why the curve is know, but an key can't created.

Am 08.01.21 um 21:57 schrieb Tom Lane:
> PG Bug reporting form <noreply@postgresql.org> writes:
>> It looks like the curves with the upper X are known, but not correct
>> initialized.
>
> BTW, as far as that goes, I looked into the source code and found
>
>      nid = OBJ_sn2nid(SSLECDHCurve);
>      if (!nid)
>      {
>          ereport(isServerStart ? FATAL : LOG,
>                  (errcode(ERRCODE_CONFIG_FILE_ERROR),
>                   errmsg("ECDH: unrecognized curve name: %s", SSLECDHCurve)));
>          return false;
>      }
>
>      ecdh = EC_KEY_new_by_curve_name(nid);
>      if (!ecdh)
>      {
>          ereport(isServerStart ? FATAL : LOG,
>                  (errcode(ERRCODE_CONFIG_FILE_ERROR),
>                   errmsg("ECDH: could not create key")));
>          return false;
>      }
>
> So it would appear that "X448" and "X25519" are known as names for
> *some* sort of thing known to OpenSSL, but they aren't ECDH curves.
>
>             regards, tom lane
>


--
*Frank Büttner*
IT

MDC Berlin-Buch
Max-Delbrück-Centrum für Molekulare Medizin in der Helmholtz-Gemeinschaft
Robert-Rössle-Straße 10
13125 Berlin

☎ +49 30 9406 2038
℻ +49 30 9406 2599
✉ frank.buettner@mdc-berlin.de