Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite to wrap around curve25519-elisabeth and ed25519-elisabeth #71

Open
str4d opened this issue Jan 28, 2019 · 1 comment
Open

Rewrite to wrap around curve25519-elisabeth and ed25519-elisabeth #71

str4d opened this issue Jan 28, 2019 · 1 comment
Milestone

Comments

@str4d
Copy link
Owner

str4d commented Jan 28, 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:

   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:

  1. Create a new library, instantiated with the Curve25519 group and field arithmetic from this library.
  2. Refactor the arithmetic code within the new library as necessary to create a standalone API there.
  3. Publish the new library.
  4. 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.

@str4d str4d added this to the 0.4 milestone Jan 28, 2019
@str4d str4d pinned this issue Jan 28, 2019
@str4d
Copy link
Owner Author

str4d commented Aug 3, 2019

My new Curve25519 library is here: https://github.com/cryptography-cafe/curve25519-elisabeth

I have decided to also create a new Ed25519 library with a more modern API, which I am working on here: https://github.com/cryptography-cafe/ed25519-elisabeth

So my plan now is to have this library wrap ed25519-elisabeth for backwards-compatibility with JCA usages.

@str4d str4d changed the title Extract Curve25519 arithmetic into a separate library Rewrite to wrap around curve25519-elisabeth and ed25519-elisabeth Aug 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant