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

[ntn-x2]

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]

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]

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]

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]

To summarize:

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

[ShankarWarang]

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]

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]

this is in estimation phase currently

[paulmillr]

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