You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the Curve25519-specific arithmetic is closely-coupled to its use in this EdDSA implementation. Part of the reason for this was to make it theoretically easier to generically support other EdDSA instantiations in the library, such as Ed448. However, the close coupling makes it difficult to reuse the Curve25519 arithmetic for either X25519 operations, or as an internal representation for ristretto255.
Meanwhile, since this library was created, the wider community has standardised Ed25519 and Ed448 in RFC 8032. In particular, section 3 states:
The generic EdDSA digital signature system with its 11 input
parameters is not intended to be implemented directly. Choosing
parameters is critical for secure and efficient operation. Instead,
you would implement a particular parameter choice for EdDSA (such as
Ed25519 or Ed448), sometimes slightly generalized to achieve code
reuse to cover Ed25519 and Ed448.
Therefore, in the next version of this library I plan to move the Curve25519 arithmetic out of this library, and remove the BigInteger-based arithmetic.
This is a breaking change, because the current API of this library exposes arithmetic classes that will be moved (such as GroupElement).
My strategy for this will be:
Create a new library, instantiated with the Curve25519 group and field arithmetic from this library.
Refactor the arithmetic code within the new library as necessary to create a standalone API there.
Publish the new library.
Replace the Curve25519 arithmetic in this library with the new library, refactoring the API here as necessary.
This library will then solely be focused on implementing the EdDSA algorithm, the JCA engine, and the higher-level encoding formats such as X.509.
The text was updated successfully, but these errors were encountered:
So my plan now is to have this library wrap ed25519-elisabeth for backwards-compatibility with JCA usages.
str4d
changed the title
Extract Curve25519 arithmetic into a separate library
Rewrite to wrap around curve25519-elisabeth and ed25519-elisabeth
Aug 3, 2019
Currently the Curve25519-specific arithmetic is closely-coupled to its use in this EdDSA implementation. Part of the reason for this was to make it theoretically easier to generically support other EdDSA instantiations in the library, such as Ed448. However, the close coupling makes it difficult to reuse the Curve25519 arithmetic for either X25519 operations, or as an internal representation for ristretto255.
Meanwhile, since this library was created, the wider community has standardised Ed25519 and Ed448 in RFC 8032. In particular, section 3 states:
Therefore, in the next version of this library I plan to move the Curve25519 arithmetic out of this library, and remove the
BigInteger
-based arithmetic.This is a breaking change, because the current API of this library exposes arithmetic classes that will be moved (such as
GroupElement
).My strategy for this will be:
This library will then solely be focused on implementing the EdDSA algorithm, the JCA engine, and the higher-level encoding formats such as X.509.
The text was updated successfully, but these errors were encountered: