Why were edwards curves given distinct key types, aren't they EC keys?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Why were edwards curves given distinct key types, aren't they EC keys?

Sam Roberts
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
Reply | Threaded
Open this post in threaded view
|

Re: Why were edwards curves given distinct key types, aren't they EC keys?

OpenSSL - User mailing list
Maybe because EVP_PKEY_EC designates an ECDSA key, that an EdDSA key is not generated the same way (particularly the public part), and that the encodings are different?

Cordialement,
Erwann Abalea

Le 15/03/2019 19:20, « openssl-users au nom de Sam Roberts » <[hidden email] au nom de [hidden email]> a écrit :

    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
   

Reply | Threaded
Open this post in threaded view
|

Re: Why were edwards curves given distinct key types, aren't they EC keys?

Nicola
In reply to this post by Sam Roberts
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Why were edwards curves given distinct key types, aren't they EC keys?

Sam Roberts
That helps a lot, I can see why they are different enough from EC key
types to be distinct.

It still leaves me wondering whe two edwards curves have key types
distinct from each other? Why aren't they both EVP_PKEY_ED? (or
something of the like)

Cheers,
Sam
Reply | Threaded
Open this post in threaded view
|

Re: Why were edwards curves given distinct key types, aren't they EC keys?

Nicola
Well, they just don't have their individual type either: they are just
`EVP_PKEY`s, with `EVP_PKEY` being the top level API in libcrypto for
public key cryptography.
The difference with `RSA_KEY`, `DSA_KEY`, `EC_KEY` (that can be
encapsulated in a generic `EVP_PKEY` object) is that Ed* keys don't
share a common module (apart from reusing common functions for parts
of the ASN1 encoding/decoding).
RSA, DSA and EC in libcrypto are submodules on their own, with a
dedicated `{RSA,DSA,EC}_*` API, in part for legacy reasons. By the
time X25519, Ed25519 and *448 were added, the new direction in the
project was to minimise the size of the public API and recommend the
use of the unified EVP API, so it did not make any sense to have a
separate submodule with its own data types and API.

This is of course to the best of my knowledge and mostly based on
guesses, as I was not actively contributing to the project while some
of these decisions were made, and I don't have the same insight on the
history of the design of the library as other project members.

BR, 

Nicola 

On Sat, Mar 16, 2019, 17:00 Sam Roberts <[hidden email]> wrote:
That helps a lot, I can see why they are different enough from EC key
types to be distinct.

It still leaves me wondering whe two edwards curves have key types
distinct from each other? Why aren't they both EVP_PKEY_ED? (or
something of the like)

Cheers,
Sam
Reply | Threaded
Open this post in threaded view
|

Re: Why were edwards curves given distinct key types, aren't they EC keys?

Sam Roberts
That helps a lot, thanks.

On Sat, Mar 16, 2019 at 8:05 AM Nicola <[hidden email]> wrote:

>
> Well, they just don't have their individual type either: they are just
> `EVP_PKEY`s, with `EVP_PKEY` being the top level API in libcrypto for
> public key cryptography.
> The difference with `RSA_KEY`, `DSA_KEY`, `EC_KEY` (that can be
> encapsulated in a generic `EVP_PKEY` object) is that Ed* keys don't
> share a common module (apart from reusing common functions for parts
> of the ASN1 encoding/decoding).
> RSA, DSA and EC in libcrypto are submodules on their own, with a
> dedicated `{RSA,DSA,EC}_*` API, in part for legacy reasons. By the
> time X25519, Ed25519 and *448 were added, the new direction in the
> project was to minimise the size of the public API and recommend the
> use of the unified EVP API, so it did not make any sense to have a
> separate submodule with its own data types and API.
>
> This is of course to the best of my knowledge and mostly based on
> guesses, as I was not actively contributing to the project while some
> of these decisions were made, and I don't have the same insight on the
> history of the design of the library as other project members.
>
> BR,
>
> Nicola
>
> On Sat, Mar 16, 2019, 17:00 Sam Roberts <[hidden email]> wrote:
>>
>> That helps a lot, I can see why they are different enough from EC key
>> types to be distinct.
>>
>> It still leaves me wondering whe two edwards curves have key types
>> distinct from each other? Why aren't they both EVP_PKEY_ED? (or
>> something of the like)
>>
>> Cheers,
>> Sam