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

[will]

Hello EdgeFam,

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

Thank you.

[DotMrCode]

Hello,

Web Crypto · Cloudflare Workers docs

2018/9/20 Release Notes: ECDSA, PEM, better garbage collection

Hi all, Many people don’t realize this, but we update Workers every single week. Historically we haven’t been telling people what changed in every release, but we’ve decided to start posting release notes starting this week. This is somewhat of an experiment; we may change the format in future weeks. This week: New features: V8 has been updated to version 7.0. The WebCrypto API now supports ECSDA import, signing, and verification. The WebCrypto API now supports PKCS#8 and SPKI import for RS…

WebCrypto ECDH - Unrecognized or unimplemented key generation algorithm requested

Hello, I want to use the ECDH algorithm to exchange public keys, then obtain the same derivedKey for client and server, then crypt / encrypt their messages, so my PWA is using End-to-End encryption. My code works 100% fine in Chrome, on both client and simulated server on client. When I try the code for real on server, especially when I generate a ECDH key pair (privateKey / publicKey), I receive the following error message from my Cloudflare Worker : Unrecognized or unimplemented key gener…

[KentonVarda]

@will

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

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.

[will]

@KentonVarda

BoringSSL

Thank you for the answers guys.

Kenton,

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.

[KentonVarda]

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.

[will]

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.

[thomas4]

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.