The following "curves" were added to the 'ec' key type in #36879:

• NODE-ED25519
• NODE-ED448
• NODE-X25519
• NODE-X448

However, none of these are pure EC curves, for example, Curve25519 does not work with ECDSA, which is one of the reasons why crypto.getCurves() does not include Curve25519.

Node.js already supported these special algorithms through their own key types (thanks to #26554, #26774, and #31178):

• crypto.generateKeyPairSync('ed25519').publicKey.asymmetricKeyType === 'ed25519'
• crypto.generateKeyPairSync('ed448').publicKey.asymmetricKeyType === 'ed448'
• crypto.generateKeyPairSync('x25519').publicKey.asymmetricKeyType === 'x25519'
• crypto.generateKeyPairSync('x448').publicKey.asymmetricKeyType === 'x448'

With #36879, we now also have this:

• crypto.generateKeyPairSync('ec', { namedCurve: 'NODE-ED25519' }).publicKey.asymmetricKeyType === 'ed25519'
• crypto.generateKeyPairSync('ec', { namedCurve: 'NODE-ED448' }).publicKey.asymmetricKeyType === 'ed448'
• crypto.generateKeyPairSync('ec', { namedCurve: 'NODE-X25519' }).publicKey.asymmetricKeyType === 'x25519'
• crypto.generateKeyPairSync('ec', { namedCurve: 'NODE-X448' }).publicKey.asymmetricKeyType === 'x448'

This also means that two keys, both generated through some call to crypto.generateKeyPairSync('ec', { namedCurve }) result in different ASN.1 representations, which is also highly unusual and counter-intuitive.

#36879 technically also landed without full approval.