crypto: add crypto.hash

[tniessen]

The goal here is to provide an alternative to crypto.Hash and crypto.webcrypto.subtle.digest that is faster and simpler to use.

crypto.Hash is much faster than crypto.webcrypto.subtle.digest according to benchmark/crypto/oneshot-hash.js:

$ ./node benchmark/scatter.js --runs 20 --set method=SHA-256 benchmark/crypto/webcrypto-digest.js | Rscript benchmark/scatter.R --xaxis data --category sync
data sync rate confidence.interval
10 createHash 248292.35 17161.170
10 subtle 49045.52 6388.407
20 createHash 253097.14 15370.901
20 subtle 50490.10 7055.920
50 createHash 254165.85 13882.920
50 subtle 45121.56 7547.952
100 createHash 258058.82 10113.583
100 subtle 48923.49 11432.019

The current implementation of crypto.hash is about 20 percent faster than crypto.Hash for data smaller than 1 KiB:

$ ./node benchmark/scatter.js --runs 10 --set algo=sha256 benchmark/crypto/oneshot-hash.js | Rscript benchmark/scatter.R --xaxis len --category mode len mode rate confidence.interval
2 oneshot 698012.61 44691.1728
2 stateful 567900.50 18391.4875
128 oneshot 647694.74 62389.5464
128 stateful 546533.64 14261.0387
1024 oneshot 496249.32 26487.7879
1024 stateful 423584.00 17385.1949
65536 oneshot 26513.05 114.0699
65536 stateful 26240.26 211.5988

There is still room for improvement. For example, it still unnecessarily calls into C++ twice.

One thing I am not sure about is encoding. I think an additional encoding parameter for the output would make sense, since producing hex or even base64 digests is extremely common. That leaves no room for an input encoding, which is why strings are currently not allowed as inputs.

We can also add a callback argument (similar to crypto.sign in #26611).

Refs: #26748

[nodejs-github-bot]

Review requested:

• @nodejs/crypto

[addaleax]

We can also add a callback argument (similar to crypto.sign in #26611).

I realize that for hashing, the overhead of async calls might not be worth it, but it does worry me a bit that this would encourage consistently using synchronous calls for this when that’s a pattern that we don’t generally want to encourage.

[panva]

The current implementation of crypto.hash is about 20 percent faster than crypto.Hash for data smaller than 1 KiB.

There is still room for improvement. For example, it still unnecessarily calls into C++ twice.

🤤 so much potential, the same can be done for hmac I presume?

[tniessen]

Closing since #51044 was merged.