Node.js `crypto` and the WebCrypto API

[daviddias]

I've been looking for documentation and/or notes about the plans for the Node.js core crypto module and somethings are still unclear to me (but on that I'm sure I'm simply missing a lot of context, which I hope to get :)), namely:

• Since there is a WebCrypto Standard now, is there any goal of accessing the WebCryptoAPI available in Chrome from Node.js?
• Node.js crypto module stands on top of openssl lib, what would be the obstacles if we wanted to move to the WebCryptoAPI, not being dependent on the openssl lib that is installed in the host (and from that, enable crypto code to move between Node.js and the Browser without any trouble).
• What is the state of ECDSA in Node.js
• Is there plans for a Crypto WG? Or is there a channel that I should be posting these questions instead of here?

Thank you :)

[Fishrock123]

cc @nodejs/crypto

[mscdex]

1. It hasn't really been discussed before, but IMHO this is something that I think could easily be done in userland. crypto provides most of the features of the Web Cryptography API already, it's just a difference in function names.
2. By default, the bundled OpenSSL is used for the crypto module, not the host's copy of OpenSSL. The obstacles would be creating a compatibility layer that maps the Web Cryptography API to the crypto API counterparts. There's probably a few features that do not currently exist in the crypto module. Technically those things could be polyfilled in userland too.
3. I'm not sure what you mean here, but you can already sign/verify data using ecdsa keys in node.
4. There is no crypto WG currently, but there is a crypto team (as @Fishrock123 showed). I'm not exactly sure what the goals of a crypto WG would be.

[daviddias]

Thank you for getting back to me, @mscdex :)

Here goes some comments:

1. Having a 'webcrypto' module that picks the right API depending of where the code is being run would definitely be nice.
2. Good to know, hadn't realised that.
3. Could you share an example? I was unable to get it working and started using the ecdsa module instead
4. Apparently the team is private, not sure if that is intended. I just wanted to understand if there was a best place to post my questions

[rvagg]

Private just as a result of the way github does teams, anyone who feels qualified to weigh in and help whenever that team is pingged is welcome to join, if you have the time and interest @diasdavid then I'd happily add you to that team.

There is no WG, there hasn't been a need for it, but anyone who wants to spend the time to start and help run a working group is welcome to do so, you can bootstrap it here by getting some discussion happening and figuring out what that WG might do, the level of interest and response might tell you whether such a group would even be practical. Again, you're more than welcome to try and make that happen but be patient obviously.

[indutny]

@mscdex goals of crypto WG should be cryptic...

[indutny]

I'm overall +1 for the WebCrypto, sounds like a good idea.

[daviddias]

Thank you for clarifying that, @rvagg :) and thank you, @indutny, for validating the idea :)

I'm always glad to help and crypto is definitely on my pool of subjects of interest! What are the current endeavours that the crypto team is taking?

I've added the WebCrypto module to my list of things to build for libp2p + node-ipfs and what I think its best for me to do is to continue following up with the crypto team if I find anything or simply for clarifications.

[rvagg]

What are the current endeavours that the crypto team is taking?

I believe the team primarily exists as support for all things crypto rather than undertaking specific endeavours, beyond upgrading and maintaining openssl that is. So it's up to you to propose a way forward that would turn this into a slightly more formalised team rather than just a crypto-support team.

[tomgco]

I have also come across various quirks around the crypto subsystem, specifically not having an API that can create ECDSA private and public keys (unless I am mistaken), and format the exported keys into "raw", "pkcs8" and "spki", would also be nice to include JsonWebKey's as an auxiliary input and output key format in node core.

Would we be interested in allowing the generation of certificates from within the node crypto submodule, something like this would help?

[tomgco]

specifically not having an API that can create ECDSA private and public keys (unless I am mistaken)

By this I mean that It is not simple to be able to create these keys without having to go through the convoluted way of using ECDH.generateKeys, even then we are able to grab the private key as a BN_bn2bin and place it into a buffer. But we then lack the ability to format into PEM, thus meaning we cannot pass it as an argument into sign.sign. Meaning that the api is not compatible with itself.

[mikeal]

perhaps the best way forward is for someone to write a module that meets the standard API and give this ticket input if anything in the API isn't possible with the existing functionality exposed by crypto.