search

paulmillr / noble-curves

Audited & minimal JS implementation of elliptic curve cryptography.
https://paulmillr.com/noble
MIT License
664 stars 62 forks source link

Add support for Sr25519 (Schnorr over Ristretto Ed25519 points)? #68

Open ntn-x2 opened 1 year ago

ntn-x2 commented 1 year ago

Has there been any talks about adding support for the Sr25519 crypto scheme, very popular inside the Polkadot space?

I would contribute with code myself, but I am not a cryptographer and would not feel comfortable doing so, but I could offer all the help needed, as much as I can.

The current implementation that Polkadot provides relies on WASM logic, and it would be extremely useful for a variety of reasons to have a pure TS/JS library.

paulmillr commented 1 year ago

ed25519 (eddsa) is a variant of schnorr. What is a benefit of a different schnorr scheme, if eddsa is already schnorr?

I don't think this is a good fit for noble-curves. The feature seems very unpopular and only used in polkadot, which would be cool to have in a separate repository.

For example, i've created separate repo for stark curve: micro-starknet.

ntn-x2 commented 1 year ago

ed25519 (eddsa) is a variant of schnorr. What is a benefit of a different schnorr scheme, if eddsa is already schnorr?

As I said, this question goes well beyond my head. As far as I know, also Cosmos supports Sr25519 keys.

What would be the process for having a new signature scheme in a different repo, that would benefit from all the auditing and testing this repo gets?

paulmillr commented 1 year ago

What would be the process for having a new signature scheme in a different repo, that would benefit from all the auditing and testing this repo gets?

Even if we place sr25519 inside of noble-curves, it may not get audited. For example, the last audit was mostly focused on weierstrass curves. Some code is shared with ed25519, but not all of it.

So, it depends on whether there would be specific parties that are willing to fund such audit. If there would be such a party, there would be no difference to them: a separate repo that depends on noble-curves, or just noble-curves.

What would be the process

Creating a repository, writing tests with test vectors, then we can place its url into README.

paulmillr commented 1 year ago

To summarize:

Great idea for a separate repo. Not a great idea for curves, because the feature is rare nowadays.

ShankarWarang commented 1 month ago

So, it depends on whether there would be specific parties that are willing to fund such audit. If there would be such a party, there would be no difference to them: a separate repo that depends on noble-curves, or just noble-curves.

@paulmillr, we can help you draft a Polkadot treasury proposal to fund such an audit. (Every step in this proposal curation process will be transparent and public.) This package would benefit many Polkadot ecosystem chains/protocols as there isn't a single generic and purely JS/TS implementation package for sr25519. Would you be interested in that?

farwayer commented 1 month ago

sr25519 is the default for keys in polkadot. And they use noble heavily in their SDK. It would be really cool to have a native JS implementation for integration with various Polkadot networks.

paulmillr commented 1 month ago

this is in estimation phase currently

paulmillr commented 2 weeks ago

Seems like we may have a funding for that: URL.