feat(extensions/crypto): implement generateKey() & sign()

[littledivy]

Related #1891
Implements CryptoKey related logic along with the following methods:

generateKey() and sign()

• RSASSA-PKCS1-v1_5
• RSA-PSS
• ECDSA
• HMAC

Uses ring for ECDSA & HMAC
Uses rsa for RSA-*

[lucacasonato]

Unfortunately we cannot test sign until we have verify, because they are both used in the WPT tests.

[lucacasonato]

Happy with this now. Thanks a lot @littledivy, and sorry that this took so long to land.

@bartlomieju could you additionally review?

@bnoordhuis could you review the key generation ops for any egregious security issues?

[bartlomieju]

This TODO is outdated

[lucacasonato]

No, I am waiting for RustCrypto/RSA@366ff6e to land in a release.

[punkeel]

perf nit: we could enable the asm feature of sha-1/sha2. Should we?

[bnoordhuis]

Rust bits LGTM. Thanks for the PR!

[bnoordhuis]

Using different PRNGs is kind of regrettable, although I understand you can't really get around that. I trust both rand and ring to get it right but still...

[bartlomieju]

LGTM too

[panva]

@lucacasonato

To circumvent these issues I suggest we drop support for "non extractable" keys and throw a SecurityError DOMException when you try to create one. The bytes that back a key should be stored on the JS object, and no resources should be involved.

Can you reconsider the way non-extractable keys are handled. Existing libraries that implement higher level functions often work with generating single-use keys generated on the fly to use in lower level functions. These use extractable: false (also because some algorithms only work with extractable: false, e.g. PBKDF2).

This lack of support will mean existing libraries will not be usable under deno, only because of this one thing.

[lucacasonato]

@panva We are happy to reconsider, but first we need clarification from the spec authors if "non extractable keys" are meant to be a security primitive or not. Deno has no way to implement non extractable keys securely if they are meant to be a security primitive.

I'll do some more research and will reach out to some WebCrypto API authors to figure out the details.

[panva]

@panva We are happy to reconsider, but first we need clarification from the spec authors if "non extractable keys" are meant to be a security primitive or not. Deno has no way to implement non extractable keys securely if they are meant to be a security primitive.

I'll do some more research and will reach out to some WebCrypto API authors to figure out the details.

Thank you, that's fair.

I have not encountered a normative language in the spec that would say e.g. that the memory used to hold the non-extractable keying material must be out of reach, it only says the raw keying material may not be exported by the application.

extractable
Reflects the [[extractable]] internal slot, which indicates whether or not the raw keying material may be exported by the application.

[lucacasonato]

I have opened #11481 to figure this out.