search

nodejs / webcrypto

This repository has been archived. The WebCrypto API has been implemented in recent versions of Node.js and does not require additional packages.
69 stars 20 forks source link

Add ECDSA prototype #18

Closed tniessen closed 5 years ago

tniessen commented 5 years ago

This should have been easy, but OpenSSL generates ASN.1 signatures while WebCrypto uses a simpler format, so we need to implement some (potentially slow) conversion logic.

As for RSA, only SPKI and PKCS#8 are currently supported for import/export.

Fixes: https://github.com/nodejs/webcrypto/issues/6

panva commented 5 years ago

Yup,

If we could get these from node it’d be great.

tniessen commented 5 years ago

Seems to be another thing that was only standardized as part of JOSE / JWK / WebCrypto. I'm not sure if it is a good idea to add small parts of those things to node core, but it would be easy to implement efficiently.

panva commented 5 years ago

But you do kind of feel like doing this conversion on a library level sucks right? :)

tniessen commented 5 years ago

Sure, it's the daily "What belongs in core" discussion: It would definitely be useful to have this in core for a few use cases, but I am worried about turning node core into a patchwork of partially supported JOSE / JWK features. I'm not saying that it should not be in core, just sharing my concerns.

panva commented 5 years ago

COSE follows the same path btw.

tniessen commented 5 years ago

I know. They probably do because the whole COSE standard was designed based on JOSE / JWK, and CBOR itself is just a neat way to express JSON IIRC.

Again, I am not saying it should not be a part of node core, but I want to be careful not to create an even worse patchwork than node crypto currently is. Adding more and more small features that only make sense within JOSE / COSE (without intending to ever fully support JOSE / COSE) does not seem like a good idea to me. But I do see the advantages :-)

tniessen commented 5 years ago

I researched this a bit more. It seems that the ASN.1 format (despite being fully standardized in 2002 in RFC3279, and extended in SEC 1 in 2009) predates the year 2000. Most crypto libraries and protocols seem to employ this well-standardized and widely used format.

In 2000, the IEEE P1363 standard was published. Section E.3.1 suggests concatenation of r and s to represent DSA signatures (and ECDSA is not at all different from DSA in this case), but also explicitely mentions ASN.1 as a more structured alternative. And while that section can't really be counted as a specification, some crypto libraries seem to have picked it up. As far as I can tell, at least .NET and pycryptodome use the P1363 format by default, and Crypto++ at least supports it.

So it seems that this "P1363 encoding" does have some (more or less standardized) existence outside of JOSE / COSE, which, in my opinion, makes it a candidate for inclusion in node core. What do you think, @panva and @sam-github?

panva commented 5 years ago

It is of no surprise to me that the webcrypto/JOSE/COSE signature format is not proprietary and is rooted in something generally available and I'd love to see the option to produce and accept r and s simply concatenated as an option for core sign/verify functions.

I'm going to repeat myself but here goes - one should not need to write asn1 schemas and use community parsers for something this fundamental (by today's standards).

This goes for ASN.1 ECDSA signatures, x509 certs and likely more as you'll find out yourself while working on webcrypto.

As a sidenote - EdDSA signatures produced by OpenSSL are already in this "r || s" format.