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
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 <vieuxtech@xxxxxxxxx> 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
