Development of @noble/curves/sr25519 package by Paul Miller and audit sponsorship (1/2)

2mos ago
8 Comments

Overview

The @noble/curves package is a highly secure and thoroughly audited JavaScript library designed for elliptic curve cryptography (ECC). As a part of the noble cryptography suite, this package emphasizes security, minimalism, and ease of audit, all while maintaining zero or minimal dependencies. Its streamlined design and comprehensive feature set make it an ideal choice for a wide array of cryptographic applications, such as secure messaging, digital signatures, and key exchange protocols.

With its focus on robust security, straightforward auditability, and high performance, the @noble/curves package stands as a reliable solution for modern web and mobile applications that require strong cryptographic operations.

 

About Paul Miller

Paul is the founding developer behind @noble packages which are used by different web3 ecosystems. He is well known for his contributions via @noble/curves and @noble/hashes packages which are directly/indirectly being used by the majority of the modern web3 protocols/toolings/platforms which includes even the forum you’re currently reading this proposal on!

 

Importance

The Polkadot ecosystem currently lacks a well-maintained and audited sr25519 npm package in a pure JavaScript/TypeScript implementation. While the @noble/ed25519 package is already available and utilized by Polkadot-JS over @polkadot/wasm-crypto for handling BigInt operations, there is no equivalent for sr25519. This gap presents a challenge for developers who require a reliable and efficient way to work with sr25519 in native JS/TS within the Polkadot ecosystem, particularly when dealing with large numbers that exceed JavaScript's standard Number primitive. Filling this gap with a properly maintained package would enhance developer reach and flexibility across the ecosystem.

 

Impact

Developer Tooling Benefits:

  • Enhanced Simplicity: The @noble/curves package offers a straightforward solution for developers using JavaScript, TypeScript, React, and Next.js, making it easier to work with the native sr25519 package.
  • Advanced BigInt Handling: Developers gain the ability to handle BigInt operations more effectively, overcoming limitations posed by the @polkadot/wasm-crypto package, which relies on Rust libraries in a WebAssembly wrapper.
  • Increased Security: The adoption of alternative implementations like @noble/curves will help mitigate the risks associated with dependence on a single package in case of zero-day exploits, acting as an additional layer for ecosystem-wide security.

Marketing Benefits:

  • Reputational Boost: By integrating with a widely-used library, the Polkadot ecosystem can enhance its reputation within the broader developer community also getting featured by Paul for sponsoring the development/auditing which puts out a good precedent for the ecosystem.
  • Increased Visibility: As many developers already use the @noble/curves package, this collaboration could attract more attention to the Polkadot community, particularly among developers who may not yet be familiar with Polkadot's capabilities.

Edgetributor SubDAO’s role

We came across the noble packages while preparing for our next project. We found that there is the ed25519 package which can be used with some patchy ways for our implementation. Then we came across the discussion on a closed issue by ntn-x2 where Paul showed interest in the integration of the sr25519 curve, subject to sponsorship availability. So we followed up with him and he wanted to pursue this further. Considering the impact of Paul’s work on the whole web3 space, we decided to voluntarily curate his proposal and take care of all the administrative work (as per his request). The entire amount corresponding to this proposal and the audit sponsorship proposal (yet to be proposed) will go to him and the auditing entity. In this whole process, Edgetributor SubDAO or Edgeware DAO or any Edgeware contributors are not getting financially benefited by any means.

 

Budget and Timeline

Budget distribution:

  • Part a (sign, verify, Point, pubkey) would take up to 1 working week, costing a maximum of 10000 USD for implementation. It could have been smaller, but it uses Merlin, which further utilizes Strobe.
  • Part b (hdkd, musig, vrf) would take up to 1 working week, thus the implementation would cost a maximum of 10000 8000 USD. {Depending upon the viability, we might have a separate @scure/sr25519 package for the musig and/or vrf instead of including them it under @noble/curves/sr25519.}

Notable terms:

  • If the development finishes earlier than 2 work weeks, the corresponding unused funds will be returned.
  • Paul suggested the Cure53 auditing firm which doesn’t need any upfront payment. He received the all-included quotation of 22500 EUR for a maximum total of 18 working days.
  • However, Cure53 is booked until January. So he is open to getting the auditing done through any other auditing firms. We are already discussing this with an auditing firm having an earlier availability. If anyone from the community knows of any auditing firms available within 1-2 months, feel free to suggest them in the comments.
  • For now, this proposal will be proposed for only the development of the @noble/curves/sr25519 package and another proposal can be proposed for the auditing after the development.
  • Paul requested payment through Github Sponsorships. For the same, we will buy 8-10 prepaid Visa/Mastercard cards using USDT which will incur 4-10% fees. We will share proof of the prepaid cards’ purchases and the unused fee buffer amount for the fiat conversion will be returned to the treasury.

Requested amount: 20000 18000 USD

Fee buffer amount for fiat conversion(10%): 2000 1800 USD {unused amount will be refunded to the treasury}

Total: 22000 19800 USDT

Multisig: 14XNJmoUzkvmh9cYoqG4axBRR4BWzWRbnFP79oiZgKu7V9bz


Changelog:

Jeff Burdges suggested removing MuSig, considering its near-to-no adoption across the ecosystem. He also suggested supporting the upcoming OLAF protocol, which can be done through a separate proposal as it is currently in the WIP phase. The proposal has been updated as per the new estimation by Paul Miller after removing the MuSig from the development scope. Huge thanks to Shawn Tabrizi for the feedback on the AAG presentation and for advocating to take feedback from Jeff Burdges.

Up
Comments
No comments here