It depends on the way they are defined: Ed25519 and Ed448 are standardized as twisted edward curves, while traditional curves in the EC module are defined in short weirstrass form.
The set of parameters describing the curves and their equation form are different: - for Edwards curves you have an expression of the form: `a x^2 + y^2 = 1 + d x^2 y^2`, and the parameters `a` and `d` have to satisfy certain properties; - for short Weierstrass curves the expression has the form: `y^3 = x^3 + a x + b`, and the parameters `a` and `b` have to satisfy a different set of properties. While it would have been technically possible to (hackishly) "overload" the existing EC module to support Ed curves, it wouldn't make too much sense, as the standards use different encodings and codepoints for describing keys and curve points (so one cannot reuse the existing ASN1 methods associated with traditional EC objects). In addition to that, EC objects are supposed to support a common set of arithmetic primitives on top of which cryptosystems like ECDH, cofactor-ECDH and ECDSA are defined, but again the standardized Edwards curve are instead associated with a different digital signature cryptosystem (EdDSA) and the `derive` (i.e. equivalent to ECDH) operation is defined on different (although related) Montgomery curves (i.e. X25519 for Ed25519 and X448 for Ed448). Hope this answers your question, Nicola On Fri, Mar 15, 2019, 20:20 Sam Roberts <vieuxt...@gmail.com> wrote: > It seems like they are EC keys, with specific curve designs, and that > also have some algorithms designed specifically for them, like EdDSA > -- though it looks like that alg is being generalized to other curve > types (https://tools.ietf.org/html/rfc8032#ref-EDDSA2). > > What about them makes it necessary to make them distinct, both from > each other, and EVP_PKEY_EC? > > Thanks, > Sam >
