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

wip: ristretto transaction signing #1172

Closed
wants to merge 1 commit into from

Conversation

0xalank
Copy link
Contributor

@0xalank 0xalank commented Sep 28, 2023

@dominant-strategies/core-dev

This PR is extremely basic, likely has bugs, and is just a starting example of libraries we can pull from. Take everything mentioned with a grain of salt until further feedback is received from the team

Quai Network: Implementation of Ristretto Signing Curve

Overview

Ristretto is a prime order elliptic curve technique ensuring non-malleable encodings. The integration of Ristretto will enhance the Quai Network's security, speed, and capability.

Benefits:

  • Enhanced Security: Prevent various elliptic curve related attacks.
  • High-Speed Transactions: Utilize the efficiency of Curve25519 in combination with Ristretto.
  • Unique Encodings: Ensure non-malleability across cryptographic operations.
  • Privacy Potential: Enables the introduction of advanced privacy-preserving protocols like Confidential Transactions or the ZK-STARKs.
  • Community Support: Rely on a well-researched and widely adopted cryptographic foundation.

Curve25519 and secp256k1 (current Quai curve) are two different elliptic curves used in public-key cryptography.

Definition and Shape:

  • Curve25519: It's defined over the prime field 2^255 - 19 and uses Montgomery form. Its equation is (y^2 = x^3 + 486662x^2 + x).
  • secp256k1: It's defined over the prime field 2^256 - 2^32 - 977 and uses short Weierstrass form. Its equation is (y^2 = x^3 + 7).

Implementations

  1. ristretto255
  • The recommended pure go implementation of ristretto255 over filippo.io/edwards25519.
  1. ChainSafe implementation of go-schnorrkel
  1. go-ristretto

Questions

  1. Do we want to have a prefix on public to an address as encoded base58? (Polkadot does this)
  • a modification of Base-58-check from Bitcoin with some minor changes. Notably, the format contains an address type prefix that identifies an address belonging to a specific network. For example: Polkadot addresses always start with the number 1.
  1. How do we want to convert a pubkey to an address?
  2. How do we define the mapping? Like this? https://github.com/paritytech/ss58-registry/blob/main/ss58-registry.json
  3. Are we okay with putting public keys in the tx data themselves?
  4. Do we even want to support secp256k at all?
  5. Do we want to have a SigningContext?
  6. Do we want to utilize Schnorr Signature Aggregation?

References

Polkadot Accounts In-Depth

Copy link
Member

@wizeguyy wizeguyy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is something that couldn't merge to main until after testnet, even if we agreed on everything and tested it sufficiently internally. Why don't you flesh out development on your ristretto branch and hold off with the PR to main?

If you'd like to have a long form discussion of the trade-offs, I suggest starting a thread in a GitHub issue or a forum thread. PR is not a good place for this R&D exploration.

Enhanced Security: Prevent various elliptic curve related attacks.

What elliptic curve attacks do we have today in secp256k1 that Ristretto will mitigate?

Community Support: Rely on a well-researched and widely adopted cryptographic foundation.

While I love Ristretto, I think this statement is misleading. secp256k1 has one of the most robust ecosystems of tools and devs of all the curves groups. More-so than Ristretto.

@0xalank
Copy link
Contributor Author

0xalank commented Sep 29, 2023

This is something that couldn't merge to main until after testnet, even if we agreed on everything and tested it sufficiently internally. Why don't you flesh out development on your ristretto branch and hold off with the PR to main?

If you'd like to have a long form discussion of the trade-offs, I suggest starting a thread in a GitHub issue or a forum thread. PR is not a good place for this R&D exploration.

Enhanced Security: Prevent various elliptic curve related attacks.

What elliptic curve attacks do we have today in secp256k1 that Ristretto will mitigate?

Community Support: Rely on a well-researched and widely adopted cryptographic foundation.

While I love Ristretto, I think this statement is misleading. secp256k1 has one of the most robust ecosystems of tools and devs of all the curves groups. More-so than Ristretto.

Closing this PR. Forum post is up:
https://forum.qu.ai/t/quai-ristretto-implementation/473

@0xalank 0xalank closed this Sep 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants