Although disappointed about the current status of the Ed25519 in Chrome, I\u2019m very satisfied to see the results of our efforts, with the implementation now moving forward in other major web engines and shipping by default for both Ed25119\u00a0[1]<\/a>\u00a0and X25119\u00a0[2]<\/a>.<\/p>\n Finally, I want to remark about the work done to improve interoperability, which is a relevant debt this feature carried the last few years, to ensure applications can realiably use the Curve21559 features in any of the major browsers.<\/p>\n Before analyzing the current status and blockers, it\u2019s important to understand why browser support for this feature matters, why merging the WICG draft into the Web Cryptography API specification is key.<\/p>\n I\u2019ve already written about this in my\u00a0last post<\/a>\u00a0so I\u2019m not going to elaborate too much, but it\u2019s important to describe some of the advantages for the Web Platform users this API has over the current alternatives.<\/p>\n The Ed25519 algorithm for EdDSA signing and the X25519 function for key-agreement offer stronger security and better performance than other algorithms. For instance, the RSA keys are explicitly\u00a0banned from new features like Web Transport<\/a>. The smaller key size (32 bytes) and EdDSA signatures (64 bytes) provide advantages in terms of transmission rates, especially in distributed systems and peer-to-peer communications.<\/p>\n The lack of a browser API to use the Curve25519 algorithms have forced web authors to rely on\u00a0external components<\/a>, either JS libraries or WASM compiled, which implies a security risk. This situation is especially sad, considering that browsers already have support for these algorithms as part of the TLS 1.3 implementation; it\u2019s just not exposed to web authors.<\/p>\n To get an idea of of what the time-frame and effort required to develop a web feature like this looks like, lets consider the following milestones:<\/p>\n This is a good example of a third-party actor not affiliated with a browser-vendor investing time and money to change the priorities of the companies behind the main browsers to bring an important feature to the Web Platform. It\u2019s been a large effort during 2 years, reaching agreement between 3 different browsers, spec editor and contributors and the W3C Web App Sec WG, which manages the Web Cryptography API specification.<\/p>\n It\u2019s worth mentioning that a large part of the time has been invested in increasing the testing coverage in the Web Platform Tests\u2019\u00a0WebCryptoAPI test suite<\/a>\u00a0and improving the interoperability between the three main web engines. This effort implies filing bugs in the corresponding browsers, discussing in the Secure Curves WICG about the best approach to address the interop issue and writing tests to ensure we don\u2019t regress in the future.<\/p>\n Unfortunately, a few of these interop issues are the reason why the Ed25519 algorithm has not been shipped when I expected, but I\u2019ll elaborate more in this later in this post.<\/p>\n The following table provides a high-level overview of the support of the Secure Curve25519 features in some of the main browsers:<\/p>\n If we want to take a broader look at the implementation status of these algorithms, there is a nice table in the\u00a0issue #20<\/a>\u00a0at the WICG repository:<\/p>\n As I commented before, most of the work done during this year was focused on improving the spec and increasing the test coverage by the WPT suite. The main goal of these efforts was improving the interoperability of the feature between the three main browsers. It\u2019s interesting to compare the results with the data shown in my\u00a0previous<\/a>\u00a0post.<\/p>\n Test\u00a0results<\/a>\u00a0for the\u00a0generateKey<\/a>\u00a0method:<\/p>\n Current<\/strong><\/p>\n Before<\/strong> Test\u00a0results<\/a>\u00a0for the\u00a0deriveBits<\/a>\u00a0and\u00a0deriveKey<\/a>\u00a0methods:<\/p>\n Current<\/strong><\/p>\n Before<\/strong><\/p>\n Tests\u00a0results<\/a>\u00a0for the\u00a0importKey<\/a>\u00a0and\u00a0exportKey<\/a>\u00a0methods:<\/p>\n Current<\/strong><\/p>\n Before<\/strong><\/p>\n Tests\u00a0results<\/a>\u00a0for the\u00a0sign<\/a>\u00a0and\u00a0verify<\/a>\u00a0methods:<\/p>\n Current<\/strong><\/p>\n Tests\u00a0results<\/a>\u00a0for the\u00a0wrap<\/a>\u00a0and\u00a0unwrap<\/a>\u00a0methods:<\/p>\n Current<\/strong><\/p>\n Before<\/strong><\/p>\n The blockers that prevented the Intent-To-Ship request of the Ed25519 are primarily these 2 issues in the spec:<\/p>\n There are other minor disagreements regarding the Ed25519 specification, like the removal of the \u201calg\u201d member in the JWK format in the import\/export operations. There is a\u00a0bug 40074061<\/a>\u00a0in Chrome to implement this spec change, but apparently it has not been agreed on by Chrome, and now there is not enough support to proceed. Firefox already implements the specified behavior and there is a similar bug report in WebKit (bug 262613<\/a>) where it seems there is support to implement the behavior change. However, I\u2019d rather avoid introducing an interop issue and delay the implementation until there is more consensus regarding the spec.<\/p>\n The issue about the use of randomized EdDSA signatures comes from the fact that WebKit\u2019s CryptoKit, the underlaying cryptography component of the WebKit engine, follows that approach in their implementation of the Ed25519 generateKey() operation. It\u2019s been always in the spirit of the Secure Curves spec to rely completely on the corresponding official RFCs. In the case of the Ed25519 algorithm it refers to the\u00a0RFC8032<\/a>, where it\u2019s stated the\u00a0deterministic<\/strong>\u00a0nature of the Ed25519 keys. However, the CRFG is currently discussing the issue and there is a\u00a0proposal<\/a>\u00a0of defining a Ed25519-bis with randomized signatures.<\/p>\n The small-order issue is more complex, it seems. The spec states clearly that any invalid or small-order point should be rejected during the Verify operation. This behavior is based on the RFC8032 mentioned before. Ideally, the underlying cryptography library should take care of performing these checks, and this has been the approach followed by the three main browsers in the implementation of the whole API; in the case of Chrome, this cryptography library is BoringSSL. The main problem here is that there are\u00a0differences<\/a>\u00a0in how the cryptography libraries implement these checks, and BoringSSL is not an exception. The WPT I have implemented to cover these cases also show\u00a0interop issues<\/a>\u00a0between the three main engines. I\u2019ve filed the\u00a0bug 697<\/a>, but it was marked as low priority. The alternative would be to implement the additional checks in the WebCrypto implementation, but Chrome is not very positive about this approach.<\/p>\n The small-order checks has been a request from Mozilla since the initial\u00a0standard-position request<\/a>\u00a0submitted long time ago. This has been\u00a0stated<\/a>\u00a0again in the\u00a0PR#362<\/a>\u00a0and Apple expressed positive opinions about this as well, so I believe this is going to be the selected approach.<\/p>\n I believe that Secure Curves being added into the Web Cryptography specification is a great achievement for the Web Platform and brings a very powerful feature for web developers. This is especially true in the realm of a\u00a0decentralized web<\/strong>\u00a0where Content Addressing is a key concept, which is based on cryptography hashes. Browsers exposing APIs to use Ed25519 and X25519 is going to offer a big advantage for decentralized web applications. I want to thank Daniel Huigens, editor of the Web Cryptography API specification, for his huge effort to address all the spec issues filed during the years, driving discussions always with the aim to reach consensus based resolutions, despite how frustrating the process sometimes is to develop a feature like this until it\u2019s shipped in the browser.<\/p>\n The implementation in the three major browsers is a clear sign of the stability of these features and ensures it will be maintained properly in the future. This includes the effort to keep interoperability of the three implementations, which is crucial for a healthy Web Platform ecosystem and ultimately to the web authors. The fact that we couldn\u2019t ship Ed25519 in Chrome is the only negative aspect of the work done this year but I believe it\u2019s going to be resolved soon.<\/p>\n At Igalia we expect to continue working in 2025 on the Web Cryptography API specification, at least until the blocker issues mentioned before are addressed and we can send the Intent-To-Ship request. We hope to also find the opportunity to contribute to the spec to add new algorithms and also carry out maintenance work; ensuring an interoperable Web Platform has been always a priority for Igalia and an important factor when evaluating the projects we take on as a company.<\/p>\n","protected":false},"excerpt":{"rendered":" Long story short, yes, it\u2019s possible to use the Ed25519 and X25519 algorithms through the Web Cryptography API exposed by the major browser engines: Blink (Chrome, Edge, Brave, \u2026), WebKit (Safari) and Gecko (Firefox). However, despite the hard work during the last year we haven\u2019t been able to ship Ed25519 in Chrome. It\u2019s still available … Continue reading Can I use Secure Curves in the Web Platform?<\/span><\/a><\/p>\n","protected":false},"author":20,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1913","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts\/1913","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=1913"}],"version-history":[{"count":9,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts\/1913\/revisions"}],"predecessor-version":[{"id":1948,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts\/1913\/revisions\/1948"}],"wp:attachment":[{"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/media?parent=1913"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/categories?post=1913"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/tags?post=1913"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}<\/i>Context<\/h2>\n
<\/i>Web Platform Feature Development Timeline: Key Milestones<\/h3>\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
<\/i>Current implementation status of the Curve25519 algorithms<\/h2>\n
![\"\"](\"http:\/\/blogs.igalia.com\/jfernandez\/files\/2025\/02\/Screenshot-from-2025-03-06-19-35-20-300x145.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/notes.igalia.com\/uploads\/841a6c83-eae0-4de6-b97e-05e772db4bea.png\")
<\/p>\n<\/i>Interoperability<\/h3>\n
![\"\"](\"https:\/\/notes.igalia.com\/uploads\/c3b9927d-fe67-499f-94c2-c2efbaa03a08.png\")
<\/p>\n![\"\"](\"http:\/\/blogs.igalia.com\/jfernandez\/files\/2025\/02\/Screenshot-from-2025-03-07-00-34-56.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/notes.igalia.com\/uploads\/7c59b8ef-07d6-424f-8e3a-aa6283654887.png\")
<\/p>\n![\"\"](\"http:\/\/blogs.igalia.com\/jfernandez\/files\/2025\/02\/Screenshot-from-2025-03-07-00-37-03.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/notes.igalia.com\/uploads\/7ac07ce2-dc98-46fd-b659-cc81903ec6c4.png\")
<\/p>\n![\"\"](\"http:\/\/blogs.igalia.com\/jfernandez\/files\/2025\/02\/Screenshot-from-2025-03-07-00-57-40.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/notes.igalia.com\/uploads\/da539951-be17-4e59-b4b9-7efcd5172cbe.png\")
Before<\/strong><\/p>\n![\"\"](\"http:\/\/blogs.igalia.com\/jfernandez\/files\/2025\/02\/Screenshot-from-2025-03-07-01-01-03.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/notes.igalia.com\/uploads\/9a8b305e-ca05-40c1-affa-355fe14f9f1a.png\")
<\/p>\n![\"\"](\"http:\/\/blogs.igalia.com\/jfernandez\/files\/2025\/02\/Screenshot-from-2025-03-07-01-02-15.png\")
<\/a><\/p>\n<\/i>Why Chrome didn\u2019t ship the Ed25519 feature ?<\/h3>\n
\n
<\/i>Conclusions<\/h2>\n