feat: add support for Uint8Array

[DavideSegullo]

This PR adds support for keys such as uint8array for the prepareSecretKey method, I noticed while trying to generate a mnemonic with the following code:

import { generateMnemonic as generateBIP39Mnemonic } from '@scure/bip39';
import { wordlist } from '@scure/bip39/wordlists/english';

That due to the checks within prepareSecretKey, keys in the format of Uint8Array were not supported and this generated the following exception:

Invalid argument type for "key". Need ArrayBuffer, KeyObject, CryptoKey, string

[boorad]

couple of things:

• Does binaryLikeToArrayBuffer help us here? i.e. should we try it on more than just typeof key === 'string' and if it throws, then this function throws too? It might be the better way to go.
• One small change to error message, now that we will also handle TypedArrays
• Add a test with a Uint8Array that would have failed without your code changes. (look in example app importKey() for aes tests)

[boorad]

Can you add TypedArray or similar to the error message?

[DavideSegullo]

Thank you! Done here: 287ed66

[boorad]

binaryLikeToArrayBuffer here or earlier?

[DavideSegullo]

Thank you! Done here: 287ed66

[DavideSegullo]

couple of things:

• Does binaryLikeToArrayBuffer help us here? i.e. should we try it on more than just typeof key === 'string' and if it throws, then this function throws too? It might be the better way to go.
• One small change to error message, now that we will also handle TypedArrays
• Add a test with a Uint8Array that would have failed without your code changes. (look in example app importKey() for aes tests)

All done!

[boorad]

Looking good, almost there...

[boorad]

Can we fit the other TypedArray types in here?

Maybe just call binaryLikeToArrayBuffer instead of type conditionals, and see if it throws.

[DavideSegullo]

Ye I tried it but we have some types missmatch on the first argument of binaryLikeToArrayBuffer(key, encoding):

The argument of type 'string | KeyObject | CryptoKey | RandomTypedArrays' is not assignable to the parameter of type 'BinaryLikeNode'.
  The type 'KeyObject' is not assignable to the type 'BinaryLikeNode'.
    The property 'equals' is missing in the type 'KeyObject', but is mandatory in the type 'import(“crypto”).KeyObject'.ts(2345)

And also

The argument of type 'string | CryptoKey | RandomTypedArrays' is not assignable to the parameter of type 'BinaryLikeNode'.
  The type 'CryptoKey' is not assignable to the type 'BinaryLikeNode'.
    The 'CryptoKey' type is missing the following properties of the 'KeyObject' type: export, equalsts(2345)

[DavideSegullo]

I also tried the following one, but binaryLikeToArrayBuffer doesn't throw any errors if the key isn't a valid one, it just return the raw input.

if (!(key instanceof KeyObject) && !(key instanceof CryptoKey)) {
    return binaryLikeToArrayBuffer(key, encoding);
  }

[boorad]

I wouldn't use it here, but rather after the two object types

[boorad]

or, change the types in BinaryLikeNode - these types are a mess :(

[boorad]

TypedArray should be moved out of random, too ... le sigh

[boorad]

🚀

[shamilovtim]

neither Float32Array nor Float64Array should be allowable here, that's why RandomTypedArrays existed. this should be throwing a type error and should not have compiled with tsc since it conflicts with Node's getRandomValues

[DavideSegullo]

Oh, that's a good point, @boorad what do you think? I can create a different PR were we export RandomTypedArrays again and use it for getRandomValues

[boorad]

yes plz 🙏

[shamilovtim]

To be fair I don't think the change here is super harmful but I'm more curious how tsc was able to compile given the type error. I think the bigger concern is why there wasn't a type error here

[DavideSegullo]

I think because randomFillSync just extend it, and it also use any:

[DavideSegullo]

I'll create anyway the PR, because even if typescript doesn't complain about that it's a wrong type definition

[DavideSegullo]

Done here: #330