In this post I’m going to analyze the impact this feature will have on the IPFS ecosystem and how a specific need in a niche area has become a mechanism to fund the web. Let’s start with a brief introduction of the feature and why it is important for the web platform.<\/p>\n\n\n\n
Ed25519 key pairs have become a standard in many web applications, and the IPFS protocol adopted them as the default some time ago. From the outset, Ed25519 public keys have also served as primary identifiers in systems like dat\/hypercore and SSB. Projects within this technology ecosystem tend to favor Ed25519 keys due to their smaller size and the potential for faster cryptographic operations compared to RSA keys.<\/p>\n\n\n\n
In the context of Web Applications, the browser is responsible for dealing with the establishment of a secure connection to a remote server, which necessarily entails signature verification. There are two possible approaches for application developers:<\/p>\n\n\n\n
- \n
- using the browser\u2019s native cryptographic primitives, via the Web Cryptography API<\/li>\n\n\n\n
- bundling crypto libraries into the application itself (eg as JS source files or WebAssembly binaries).<\/li>\n<\/ol>\n\n\n\n
Developers have often faced a difficult choice between using RSA keys, which are natively supported in browsers, and the Ed25519 keys they generally prefer, since using the latter required relying on external libraries until M137. These external software components introduce potential security risks if compromised, for which the developer and the application could be held responsible. In most cases, it’s desirable for private keys to be non-extractable in order to prevent attacks from malicious scripts or browser extensions, something that cannot be guaranteed with JS\/WASM-based implementations that \u201cbundle in\u201d cryptography capabilities. Additionally, \u201cuser-space\u201d implementations like these are necessarily vulnerable to supply chain attacks out of the developer\u2019s control, further increasing the risk and liability surface.<\/p>\n\n\n\n
The work Igalia<\/a> has been doing in recent years to contribute to the implementation of the Curve25519-based algorithms in the 3 main browsers (Chrome, Firefox and Safari) made it possible to promote Ed25519 and X25519 from the Web Incubation Group to the official W3C Web Cryptography API specification. This is a key milestone for the IPFS development community, since it guarantees a stable API to native cryptography primitives in the browser, allowing simpler, more secure, and more robust applications. Additionally, not having to bundle in cryptography means less code to maintain and fewer surfaces to secure over time.<\/p>\n\n\n\n
Impact the entire Web Platform – and that\u2019s a huge win<\/h2>\n\n\n\n
As already mentioned, Secure Curves like Ed25519 and X25519 play an important role in the cryptographic related logic of dApps. However, what makes this project particularly interesting is that it targets the commons \u2013 the Web Platform itself. The effort to fund and implement a key advantage for a niche area has the potential to positively impact the entire Web Platform \u2013 and that\u2019s a huge win.<\/p>\n\n\n\n
There are several projects that will benefit from a native implementation of the Curve25519 algorithms in the browser\u2019s Web Cryptography API.<\/p>\n\n\n\n
Proton services<\/h3>\n\n\n\n
Proton offers services like Proton Mail, Proton Drive, Proton Calendar and Proton Wallet which use Elliptic Curve Cryptography (ECC)<\/a> based on Curve25519 by default. Their web applications make use of the browser\u2019s Web Cryptography API<\/a> when available. The work we have done to implement and ship the Ed25519 and X25519 algorithms in the 3 main browser engines allows users of these services to rely on the browser\u2019s native implementation of their choice, leading to improved performance and security. It\u2019s worth mentioning that Proton is also contributing to the Web Cryptography API via the work Daniel Huigens is doing as spec editor<\/p>\n\n\n\n
Matrix\/Riot<\/h3>\n\n\n\n
The Matrix instant messaging web application uses Ed25519 <\/a>for its device identity and cryptographic signing operations. These are implemented by the matrix-sdk-crypto<\/a> Rust component, which is shared by both the web and native clients. This unified crypto engine is compiled to WebAssembly and integrated into the web client via the JavaScript SDK. Although theoretically, the web client could eventually use the browser\u2019s Web Crypto API to implement the Ed25519-related operations, it might not be the right approach<\/strong> for now. The messaging app also requires other low-level cryptographic primitives that are not yet available in the Web API. Continued evolution of the Web Crypto API, with more algorithms and low level operations, is a key factor in increasing adoption of the API.<\/p>\n\n\n\n
Signal<\/h3>\n\n\n\n
The Signal Protocol is well known for its robust end-to-end encrypted messaging capabilities, and the use of Ed25519 and X25519 is an important piece of its security model. The Signal web client, which is implemented as an Electron application<\/strong>, is based on the Signal Protocol, which relies on these algorithms. The cryptographic layer is implemented in the libsignal<\/strong> internal component, and it is used by all Signal clients. The point is that, as an Electron app, the web client may be able to take advantage of Chrome\u2019s Web Crypto API; however, as with the Matrix web client, the specific requirement of these messaging applications, along with some limitations of the Web API, might be reasons to rule out this approach<\/strong> for the time being.<\/p>\n\n\n\n
Use of Ed25519 and X25519 in the IPFS ecosystem<\/h2>\n\n\n\n
Developing web features implies a considerable effort in terms of time and money. Contributing to a better and more complete Web Platform is an admirable goal, but it does not justify the investment if it does not address a specific need. In this section I\u2019m going to analyze the impact of this feature in some projects in the IPFS ecosystem.<\/p>\n\n\n\n
Libp2p<\/h3>\n\n\n\n
According to the spec<\/a>, implementations MUST support Ed25519. The js-libp2p implementation for the JS APIs exposed by the browser provides a libp2p-crypto library that depends on the WebCrypto API<\/a>, so it doesn\u2019t require building third-party crypto components. The upstream work to replace the Ed25519 operations with Web Crypto alternatives has also shown benefits in terms of performance; see the PR 3100<\/a> for details. Backward compatibility<\/a> with the JavaScript based implementation, provided via @noble\/curves<\/a>, is guaranteed though. <\/p>\n\n\n\n
There are several projects that depend on libp2p<\/strong> that would benefit from the use of the Web Cryptography API to implement their Ed25519 operations: <\/p>\n\n\n\n
- \n
- Hellia<\/strong> \u2013 <\/strong>a pure JavaScript implementation of the IPFS protocol capable of running in a browser or a Node.js<\/a> server. <\/li>\n\n\n\n
- Peergos<\/strong> \u2014 a decentralised protocol and open-source platform for storage, social media and applications.<\/li>\n\n\n\n
- Lodestar<\/strong> \u2013 an Ethereum consensus client written in JS\/TypeScript.<\/li>\n\n\n\n
- HOPR<\/strong> \u2013 a privacy-preserving network protocol for messaging.<\/li>\n\n\n\n
- Peerbit<\/strong> \u2013 a decentralized database framework with built-in encryption.<\/li>\n\n\n\n
- Topology<\/strong> \u2013 a decentralized network infrastructure tooling suite.<\/li>\n<\/ul>\n\n\n\n
Helia<\/h3>\n\n\n\n
The Secure Curves are widely implemented<\/a> in the main JavaScript engines, so now that the main browsers offer support in their stable releases, Helia developers can be fairly confident in relying on the Web Cryptography API implementation. The eventual removal of the @noble\/curves dependency to implement the Ed25519 operations is going to positively impact the Helia project, for the reasons already explained. However, Helia depends on @libp2p\/webrtc for the implementation of the WebRTC transport layer. This package depends on @peculiar\/x509, probably for the X509 certificate creation and verification, and also on @peculiar\/webcrypto. The latter is a WebCrypto API polyfill<\/strong> that probably would be worth removing, given that most of the JS engines already provide a native implementation.<\/p>\n\n\n\n
Lodestar<\/h3>\n\n\n\n
This project heavily depends on js-libp2p to implement its real-time peer-to-peer network stack (Discv5, GossipSub, Resk\/Resq and Noise). Its modular design enables it to operate as a decentralized Ethereum client for the libp2p applications ecosystem. It\u2019s a good example because it doesn\u2019t use Ed25519 for the implementation of its node identity; instead it\u2019s based on secp256k1<\/a>. However, Lodestar\u2019s libp2p-based handshake uses the Noise protocol<\/strong>, which itself uses X25519 (Curve25519)<\/strong> for the Diffie\u2013Hellman key exchange to establish a secure channel between peers. The Web Cryptography API provides operations for this key-sharing algorithm, and it has also been shipped in the stable releases of the 3 main browsers.<\/p>\n\n\n\n
Peergos<\/h3>\n\n\n\n
This is an interesting example; unlike Hellia, it\u2019s implemented in Java so it uses a custom libp2p implementation (in Java) built around jvm-libp2p<\/a>, a native Java libp2p stack, and integrates cryptographic primitives on the JVM. It uses the Ed25519 operations for key generation, signatures, and identity purposes, but provides its own implementation as part of its cryptographic layer. Back in July 2024 they integrated a WebCryptoAPI based implementation<\/a>, so that it’s used when supported in the browser. As a technology targeting the Web Platform, it\u2019d be an interesting move to eventually get rid of the custom Ed25519 implementation and rely on the browser\u2019s Web Cryptography API instead, either through the libp2p-crypto<\/em> component or its own cryptographic layer.<\/p>\n\n\n\n
Other decentralized technologies<\/h2>\n\n\n\n
The implementation of the Curve25519 related algorithms in the browser\u2019s Web Cryptography API has had an impact that goes beyond the IPFS community, as it has been widely used in many other technologies across the decentralized web. <\/p>\n\n\n\n
In this section I\u2019m going to describe a few examples of relevant projects that are \u2013 or could potentially be \u2013 getting rid of third-party libraries to implement their Ed25519 and X25519 operations, relying on the native implementation provided by the browser.<\/p>\n\n\n\n
Phantom wallet<\/h3>\n\n\n\n
Phantom was built specifically for Solana<\/strong> and designed to interact with Solana-based applications. Solana uses Ed25519 keys for identity and transaction signing, so Phantom generates and manages these keys within the browser or mobile device. This ensures that all operations (signing, message verification, address derivation) conform to Solana\u2019s cryptographic standards. This integration comes from the official Solana JavaScript SDK: @solana\/web3.js. In recent versions of the SDK, the Ed25519 operations use the native Crypto API if it is available<\/a>, but it still provides a polyfill implemented with @noble\/ed25519. According to the npm registry<\/a>, the polyfill has a bundle size of 405 kB<\/strong> unpacked (minimized around 100 – 150 kB).<\/p>\n\n\n\n
Making the Case for the WebCrypto API<\/h2>\n\n\n\n
In the previous sections we have discussed several web projects where the Ed25519 and X25519 algorithms are a fundamental piece of their cryptographic layer. The variety of solutions adopted to provide an implementation of the cryptographic primitives, such as those for identity and signing, has been remarkable.<\/p>\n\n\n\n
- \n
- @noble\/curves<\/a> – A high-security, easily auditable set of contained cryptographic libraries, Zero or minimal dependencies, highly readable TypeScript \/ JS code, PGP-signed releases and transparent NPM builds.<\/li>\n\n\n\n
- TweetNaCL.js<\/a> – Port of TweetNaCl<\/a> \/ NaCl<\/a> to JavaScript for modern browsers and Node.js. Public domain.<\/li>\n\n\n\n
- Web Cryptography polyfills\n
- \n
- @solana\/webcrypto-ed25519-polyfill<\/a> – Provides a shim for Ed25519 crypto for the Solana SDK when the browser doesn\u2019t support it natively.<\/li>\n\n\n\n
- @yoursunny\/webcrypto-ed25519 <\/a>– A lightweight polyfill or ponyfill (25\u202fkB unpacked) for browsers lacking native Ed25519 support.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- Custom SDK implementations\n
- \n
- matrix-sdk-crypto <\/a>– A no-network-IO implementation of a state machine that handles end-to-end encryption for Matrix<\/a> clients. Compiled to WebAssembly and integrated into the web client via the JavaScript SDK.<\/li>\n\n\n\n
- Bouncy Castle Crypto<\/a> – The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms. <\/li>\n\n\n\n
- libsignal<\/a> – signal-crypto provides cryptographic primitives such as AES-GCM<\/em>; it uses RustCrypto<\/a>‘s where possible.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
As mentioned before, some web apps have strong cross-platform requirements, or simply the Web Crypto API is not flexible enough or lacks support for new algorithms (eg, Matrix and Signal). However, for the projects where the Web Platform is a key use case, the Web API offers way more advantages in terms of performance, bundle size, security and stability. <\/p>\n\n\n\n
The Web Crypto API is supported in the main JavaScript engines (Node.js, Deno) and the main web browsers (Safari, Chrome and Firefox). This full coverage of the Web Platform ensures high levels of interoperability and stability for both users and developers of web apps. Additionally, with the recent milestone announced in this post \u2013 the shipment of Secure Curves support in the latest stable Chrome release \u2013 the availability of this in the Web Platform is also remarkable:<\/p>\n\n\n\n
<\/figure>\n\n\n\n
Investment and prioritization<\/h3>\n\n\n\n
The work to implement and ship the Ed25519 and X25519 algorithms in the 3 main browser engines has been a long path. It took a few years to stabilize the WICG document, prototyping, increasing the test coverage in the WPT repository and incorporating both algorithms in the W3C official draft of the Web Cryptography API specification. Only after this final step, could the shipment procedure be finally completed, with Chrome 137 being the last one to ship the feature enabled by default. <\/p>\n\n\n\n
This experience shows another example of a non-browser vendor pushing forward a feature<\/strong> that benefits the whole Web Platform, even if it initially covers a short-term need of a niche community, in this case the dWeb ecosystem. It\u2019s also worth noting how the prioritization of this kind of web feature works in the Web Platform development cycle, and more specifically the browser feature shipment process. The browsers have their own budgets and priorities,<\/strong> and it\u2019s the responsibility of the Web Platform consumers to invest in the features they consider critical for their user base. Without non-browser vendors pushing forward features, the Web Platform would evolve at a much slower pace.<\/p>\n\n\n\n
The flaws of trying to use the Web Crypto API for some projects have been noted in this post, which prevent a bigger adoption of this API in favor of third-party cryptography components. The API needs to incorporate new algorithms, as has been recently discussed<\/a> in the Web App Sec Working Group meetings; there is an issue<\/a> to collect ideas for new algorithms and a WICG draft<\/a>. Some of the proposed algorithms include post-quantum secure and modern cryptographic algorithms like ML-KEM, ML-DSA, and ChaChaPoly1305.<\/p>\n\n\n\n
Recap and next steps<\/h2>\n\n\n\n
The Web Cryptography API specification has had a difficult journey in the last few years, as was explained in a previous post<\/a>, when the Web Cryptography WG was dismantled. Browsers gave very low priority to this API until Daniel Huigens (Proton<\/a>) took over the responsibility and became the only editor of the spec. The implementation progress has been almost exclusively targeting standalone JS engines until this project by Igalia was launched 3 years ago. <\/p>\n\n\n\n
The incorporation of Ed25519 and X25519 into the official W3C draft, along with default support in all three major web browsers, has brought this feature to the forefront of web application development where a cryptographic layer is required. <\/p>\n\n\n\n
The use of the Web API provides several advantages to the web authors:<\/p>\n\n\n\n
- \n
- Performance<\/strong> – Generally more performant implementation of the cryptographic operations, including reduced bundled size of the web app.<\/li>\n\n\n\n
- Security<\/strong> – Reduced attack surface, including JS timing attacks or memory disclosure via JS inspection; no supply-chain vulnerabilities. <\/li>\n\n\n\n
- Stability and Interoperability –<\/strong> Standardized and stable API, long-term maintenance by the browsers\u2019 development teams. <\/li>\n<\/ul>\n\n\n\n
Streams and WebCrypto<\/h3>\n\n\n\n
This is a \u201cdecade problem\u201d, as it\u2019s noticeable from the WebCrypto issue 73<\/a>, which now has some fresh traction thanks to a recent proposal<\/a> by WinterTC, a technical committee focused on web-interoperable server runtimes; there is also an alternate proposal<\/a> from the WebCrypto WG. It\u2019s still unclear how much support to expect from implementors, especially the three main browser vendors, but Chrome has at least expressed strong opposition to the idea of a streaming encryption \/ decryption. However, there is a clear indication of support for hashing of streams, which is perhaps the use case from which IPFS developers would benefit most. Streams would have a big impact on many IPFS related use cases, especially in combination with better support for BLAKE3 which would be a major step forward.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Introduction Chrome M137 is the first stable version shipping the Ed25519 feature enabled by default, joining Safari and Firefox in their support. This is the last milestone of a three-year collaboration between Protocol Labs (who initiated the project), the IPFS Foundation, Open Impact Foundation, and WebTransitions.org. In this post I’m going to analyze the impact … Continue reading Ed25519 Support Lands in Chrome: What It Means for Developers and the Web.\u00a0<\/span><\/a><\/p>\n","protected":false},"author":20,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1950","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts\/1950","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/comments?post=1950"}],"version-history":[{"count":4,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts\/1950\/revisions"}],"predecessor-version":[{"id":1958,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts\/1950\/revisions\/1958"}],"wp:attachment":[{"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/media?parent=1950"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/categories?post=1950"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/tags?post=1950"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Security<\/strong> – Reduced attack surface, including JS timing attacks or memory disclosure via JS inspection; no supply-chain vulnerabilities. <\/li>\n\n\n\n
- Bouncy Castle Crypto<\/a> – The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms. <\/li>\n\n\n\n
- @yoursunny\/webcrypto-ed25519 <\/a>– A lightweight polyfill or ponyfill (25\u202fkB unpacked) for browsers lacking native Ed25519 support.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- TweetNaCL.js<\/a> – Port of TweetNaCl<\/a> \/ NaCl<\/a> to JavaScript for modern browsers and Node.js. Public domain.<\/li>\n\n\n\n
- Peergos<\/strong> \u2014 a decentralised protocol and open-source platform for storage, social media and applications.<\/li>\n\n\n\n
- Hellia<\/strong> \u2013 <\/strong>a pure JavaScript implementation of the IPFS protocol capable of running in a browser or a Node.js<\/a> server. <\/li>\n\n\n\n