Review requested:

• @nodejs/crypto
• @nodejs/tsc

Ok, @tniessen, I've extended this API to make it a bit more useful for variable key length and iv length ciphers. Specifically, the getCipherInfo() can include keyLength and ivLength options that will be tested against the given cipher. If they are acceptable, then the info is returned, if they are not undefined is returned. The tests are applied for OCB, GCM, and CCM mode ciphers.

So, for instance,

crypto.getCipherInfo('aes-192-ocb', { ivLength: 10 });  // works!
crypto.getCipherInfo('aes-192-ocb', { ivLength: 18 });  // returns undefined

crypto.getCipherInfo('rc4', { keyLength: 10 }); // works!
crypto.getCipherInfo('aes-192-ccm', { keyLength: 18 }); // returns undefined

This way we can at least test to see if given parameters are usable for the given cipher.

Other changes:

1. I've removed the type property
2. For stream ciphers, the blockSize property is omitted
3. For ciphers that do not use an iv, the ivLength property is omitted

@jasnell That kind of duplicates the existing functionality of calling crypto.createCipheriv() and checking if it throws an exception. I've used that technique to good effect for some years now. :-)

@bnoordhuis ... yeah, I've done the same before. I think the key difference here is just fewer possible allocations but you're right that it duplicates the behavior just a bit. The key question is whether that is ok. Another approach we can take here is to populate the createCipherInfo() return object with the known acceptable ranges for key and iv length for ciphers that are known to be variable.

For instance, something like...

{
  name: 'rc4',
  // ...
  keyLength: { min: 1 }  // no max
}

or

{
  name: 'aes-192-ocb',
  // ...
  ivLength: { min: 7, max: 15 }
}

The other question I would have is: would it be better for the lengths to be expressed in terms of bits? For instance, max iv for ocb modes is anything less than 128 bits.... so a 127 bit iv is allowed but not expressed properly in the info object if we align everything on number of bytes.

would it be better for the lengths to be expressed in terms of bits?

Since that info comes from openssl, and because openssl always expresses it in bytes, I'd stick with that unit.

One more reason: expressing it in bits complicates Buffer.alloc() calls because now you have to worry about values that aren't multiples of 8. Not super complicated - (bits + 7) >>> 3 - but still.

CI: https://ci.nodejs.org/job/node-test-pull-request/33522/ 💚

Landed in 095be6a

This builds on a semver-major commit so I've added the dont-land labels for older release lines