crypto: fix webcrypto derive(Bits|Key) resolve values and docs

[panva]

Couple of issues discovered in #38115 addressed by this PR

• PBKDF2 deriveBits resolve value type
• NODE-SCRYPT deriveBits resolve value type
• docs: subtle.deriveKey resolve value type
• docs: ### Deriving bits and keys example does not work with deriveBits
• test: assert deriveBits resolve with ArrayBuffer

ad resolve value types see SubtleCrypto interface definition.

[nodejs-github-bot]

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

[tniessen]

Technically, pbkdf2 is only required to give us a Buffer, which does not necessarily have the same byte length as the backing ArrayBuffer:

> Buffer.from([1, 2, 3]).buffer.byteLength
8192
> crypto.randomFillSync(Buffer.allocUnsafe(1024)).buffer.byteLength
8192

That's one of many reasons why WebCrypto doesn't align well with Node.js. However, we know that the implementation of PBKDF2 always returns a Buffer that has the same byteLength as the backing ArrayBuffer. And, hopefully, tests will catch it if that ever changes.

[panva]

Yes, i've checked that they do. Alternatively we can do new Uint8Array(result).buffer

> const foo = Buffer.from('foo')
> foo.buffer.byteLength
8192
> new Uint8Array(foo).buffer
ArrayBuffer { [Uint8Contents]: <66 6f 6f>, byteLength: 3 }

[addaleax]

I think these would be places where adding assertions about matching lengths and byteOffsets might make sense :)

[tniessen]

Alternatively we can do new Uint8Array(result).buffer

That would create an unnecessary copy of sensitive data (the result of PBKDF2 is considered secret). And yes, I realize that arguing about memory safety is moot in JavaScript :)

[panva]

Landed in 896dc39