crypto: support outputLength in XOF hash functions

[Aditi-1400]

Support outputLength option in crypto.hash() for XOF hash functions to align with the behaviour of crypto.createHash() API

Fixes: #57312

[nodejs-github-bot]

Review requested:

• @nodejs/crypto
• @nodejs/security-wg

[panva]

@Aditi-1400 please change the PR title and commit message to crypto: support outputLength in crypto.hash for XOF functions

[codecov]

Codecov Report

Attention: Patch coverage is 73.33333% with 12 lines in your changes missing coverage. Please review.

Project coverage is 90.21%. Comparing base (a4c7c9f) to head (b9379c5).
Report is 10 commits behind head on main.

Files with missing lines	Patch %	Lines
src/crypto/crypto_hash.cc	54.16%	8 Missing and 3 partials ⚠️
lib/internal/crypto/hash.js	95.23%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #58121      +/-   ##
==========================================
+ Coverage   90.20%   90.21%   +0.01%     
==========================================
  Files         635      635              
  Lines      187616   187635      +19     
  Branches    36847    36865      +18     
==========================================
+ Hits       169234   169276      +42     
+ Misses      11150    11147       -3     
+ Partials     7232     7212      -20     

Files with missing lines	Coverage Δ
lib/internal/crypto/hash.js	98.36% <95.23%> (-0.31%)	⬇️
src/crypto/crypto_hash.cc	70.95% <54.16%> (-2.06%)	⬇️

... and 30 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jasnell]

@codebytere ... can I ask you to take a look at this from a Whether-This-Will-Work-In-BoringSSL perspective?

[jasnell]

This should use EVPMDCtxPointer

[jasnell]

This could use a code comment to describe the differences between hashDigest(...) and xosHashDigest(...)

[jasnell]

I think for this I'd rather we support an alternative signature that accepts either an encoding for outputEncoding or an options object... e.g.

// current signature
crypto.hash(algorithm, data[, outputEncoding]);

crypto.hash(algorithm, data[, options]);
// where `options` is:
// { outputEncoding: '...', outputLength: ... }

Makes things more scalable in case additional options need to be added later.

[Aditi-1400]

I am not sure if we wanted to support null, for now I've kept the same behaviour as

node/lib/internal/fs/utils.js

Line 318 in 2281a04

function getOptions(options, defaultOptions = kEmptyObject) {

.
Also, crypto.createHash() just ignores all the invalid options, so let me know which behaviour we should have.

[joyeecheung]

Not supporting null is fine, it should be either a string or an object (we have many overload like this e.g. in buffer)

[joyeecheung]

Suggested change

	int output_length = args[6].As<Uint32>()->Value();
	if (isXOF) {
	return ncrypto::xofHashDigest(buf, md, output_length);
	} else if (!isXOF && output_length != EVP_MD_get_size(md)) {
	ThrowCryptoError(env, ERR_get_error(), "Invalid length or not XOF");
	return {};
	}
	int output_length = args[6].As<Uint32>()->Value();
	if (isXOF) {
	return ncrypto::xofHashDigest(buf, md, output_length);
	}
	if (output_length != EVP_MD_get_size(md)) {
	Utf8Value method(isolate, args[0]);
	std::string message = "Output length " + std::to_string(output_length) + " is invalid for ";
	message += method.ToString() + ", which does not support XOF";
	ThrowCryptoError(env, ERR_get_error(), message.c_str());
	return {};
	}
	// Does not support XOF but output length matches expected digest size.
	// Compute digest as usual.