Is there support for the k-256 Curve in ECDSA WebCrypto?

Hello EdgeFam,

Is there support for the k-256 Curve in ECDSA WebCrypto?

Thank you.


At present we only support the curves that are in the WebCrypto standard: "P-256", "P-384", and "P-521"

In principle it should be very easy for us to enable K-256 since we wrap BoringSSL, which already has support. But we’d want a couple things before we expose this:

  • Confidence that we’re exposing it the “right” way, and not in a way that could end up incompatible with future revisions of WebCrypto.
  • Test vectors. We use the W3C Web Platform Tests, but obviously they won’t cover a non-standard extension.

If there happens to be a formal extension spec floating around out there for K-256 support in WebCrypto, I’d love to know about it so we can follow it.

1 Like

Thank you for the answers guys.


I understand that you would not want to implement it incorrectly and I can’t find any ready made solution around to implement in BoringSSL but while looking at the BoringSSL code I did notice it has an implementation of Ripemd160 in it. Do we have access to that? That would be good.

Thanks again.

Hi @will,

I think you misread me slightly. BoringSSL already supports K-256 from what I can tell. Exposing it in Workers would probably take one line of code.

However, once exposed we’re stuck with it. So, we need to make sure that this is the right thing to do, and make sure we have test vectors. These are hard given there’s no official spec for supporting K-256 in WebCrypto.

Ripemd160 is probably the same story. Since webcrypto doesn’t officially support it, we would be going off-spec, and while the implementation is easy (since we use BoringSSL), we still need to put together tests and verify we really are matching what people expect.

Thanks for the reply Kenton,

I actually was misreading the BoringSSL codebase. That is great news. I really don’t mind being a tester for it as what I am building won’t go into production for at least 6 months and I will be testing the results with different libraries on the client side, and Bitcoin nodes so will be checking the results with various implementations of the curve.

Maybe you could open it as ‘test-k-256’ so that nobody accidentally uses it. This curve is very useful for many Cryptocurrency projects and also for a lot of Self Sovereign Identity projects too.

I understand your cautiousness on the topic though and respect that.

Thanks Kenton and team Cloudflare.

And there’s no possibility to use a temporary “off-spec” implementation that don’t use WebCrypto?
For example, basing it on the existing node.js variant? Because I see a lot of cases where WebCrypto will lag in implementation.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.