The crypto module

This is maybe a little premature, since https://github.com/nodejs/node/issues/21766 is still being discussed, but I think as a group we should discuss:

1. What are the goals of the crypto module? Do we imagine that it’s only used by people who know what they’re doing (i.e., cryptographers)? Should we strive to expose all OpenSSL functionality? Should the interface we expose match as closely as possible with OpenSSL?
2. Supposing crypto is in fact intended to only be used by the very small percentage of people using Node that are very comfortable thinking about cryptography, should we create another crypto module that’s intended for the average Node developer to use (say crypto-simple)? If so, we would need to propose how to build it (perhaps getting cryptographers involved to build it on top of the existing crypto module, or using a more modern crypto library with an interface that is likely to be used correctly by average developers).
3. Should this group create an additional process to review changes to APIs that are security related? It would’ve been much better to have the discussion in https://github.com/nodejs/node/issues/21766 before https://github.com/nodejs/node/pull/20816 was merged. This need may be mitigated by whatever comes from discussing points 1 and 2, but it is still something to consider.

edit: Based on the results of our discussions, we may want to propose significant changes to documentation to make sure that our users’ expectations about the use of crypto match ours

[sam-github]

I don’t agree that the distinction is between “safe” and “unsafe”. I think the distinction being drawn here would be better described as “purpose built” and “general purpose”.

Openssl’s APIs, and Node’s crypto module, are general purpose crypto APIs. The advantage of this is that they can be used to implement protocols and formats that are defined by third parties.

The disadvantage is that when a developer controls both the producer and consumer, such as the password hashing example that kicked off this conversation, the developer is forced to figure out how to use the API for their specific purpose, and can easily do this wrong. It would be better for them to use a function that was specific to that purpose.

The problem with purpose built crypto APIs is that they have an internally specified format for their intermediate formats that makes them hard or impossible to use to interoperate with the crypto APIs from other libraries, languages, or standards.

Node’s crypto library is clearly general purpose in design. It does not have the kind of APIs that NACL does, for example. The design of the current scrypt() function fits perfectly with this design, I don’t agree that a password hash function would have landed in place of it, or that its design is flawed. I do agree it is not designed to be a high-level password hashing API, such as PHP has.

I appreciate the frustration of the scrypt-for-humans author that some people are avoiding his better (for some purposes) API because a “scrypt” function exists in node.

Node is having enough trouble getting sufficient developers to fix the existing problems (the “internally compatible” point made above is particularly painful to me). I’m not sure how we can extend to designing, implementing, and supporting an entirely new higher level/functional API.

My personal preference would be for such an API to be provided out of core as an npm module, and for the Node.js crypto API docs to point to it. If instead someone PRed a functional API into Node.js and got support for it, I wouldn’t object.

I’m not familiar with https://www.w3.org/TR/WebCryptoAPI/. Node has a general trend to supporting Web standard APIs when it can. Would WebCrypto be an acceptable high-level API? If so, implementing it would be following a well-paved path into node core.

[drifkin]

Got it, I appreciate the clarifications.

I think we can start by being a little idealistic and first explore what an ideal high-level API might look like in core, and then investigate the feasibility and try to analyze the cost/benefit with respect to the whole small core problem. Based on the response from the other issue, I think we may be able to get more volunteers to work on a higher-level API (we also have a few cryptographer friends that might be interested in helping out too; API design seems like an increasingly relevant topic in cryptography these days and this could have a huge impact).