summaryrefslogtreecommitdiff
path: root/ext/node/polyfills/internal/crypto/keys.ts
AgeCommit message (Collapse)Author
2024-08-08fix(ext/node): add crypto.diffieHellman (#24938)Luca Casonato
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com> Closes #21806
2024-08-07feat(ext/node): rewrite crypto keys (#24463)Luca Casonato
This completely rewrites how we handle key material in ext/node. Changes in this PR: - **Signing** - RSA - RSA-PSS 🆕 - DSA 🆕 - EC - ED25519 🆕 - **Verifying** - RSA - RSA-PSS 🆕 - DSA 🆕 - EC 🆕 - ED25519 🆕 - **Private key import** - Passphrase encrypted private keys 🆕 - RSA - PEM - DER (PKCS#1) 🆕 - DER (PKCS#8) 🆕 - RSA-PSS - PEM - DER (PKCS#1) 🆕 - DER (PKCS#8) 🆕 - DSA 🆕 - EC - PEM - DER (SEC1) 🆕 - DER (PKCS#8) 🆕 - X25519 🆕 - ED25519 🆕 - DH - **Public key import** - RSA - PEM - DER (PKCS#1) 🆕 - DER (PKCS#8) 🆕 - RSA-PSS 🆕 - DSA 🆕 - EC 🆕 - X25519 🆕 - ED25519 🆕 - DH 🆕 - **Private key export** - RSA 🆕 - DSA 🆕 - EC 🆕 - X25519 🆕 - ED25519 🆕 - DH 🆕 - **Public key export** - RSA - DSA 🆕 - EC 🆕 - X25519 🆕 - ED25519 🆕 - DH 🆕 - **Key pair generation** - Overhauled, but supported APIs unchanged This PR adds a lot of new individual functionality. But most importantly because of the new key material representation, it is now trivial to add new algorithms (as shown by this PR). Now, when adding a new algorithm, it is also widely supported - for example previously we supported ED25519 key pair generation, but we could not import, export, sign or verify with ED25519. We can now do all of those things.
2024-08-02docs: fix typos (#24820)Andreas Deininger
This PR fixes various typos I spotted in the project.
2024-07-02fix(ext/node): add Symbol.toStringTag to KeyObject instances (#24377)Filip Skokan
As per https://github.com/nodejs/node/pull/46043, this adds Symbol.toStringTag getter to KeyObject.
2024-04-29fix(ext/node): exporting rsa public keys (#23596)Divy Srivastava
Initial support for exporting rsa public KeyObject. Current assumption is that RSA keys are stored in pkcs1 der format in key storage. Ref https://github.com/denoland/deno/issues/23471 Ref https://github.com/denoland/deno/issues/18928 Ref https://github.com/denoland/deno/issues/21124
2024-03-22fix(ext/node): handle KeyObject in `prepareAsymmetricKey` (#23026)Divy Srivastava
Fixes https://github.com/denoland/deno/issues/20938
2024-03-14fix(ext/node): support `spki` format in createPublicKey (#22918)Divy Srivastava
2024-03-13fix(ext/node): initial `crypto.createPublicKey()` support (#22509)Asher Gomez
Closes #21807 Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
2024-01-29refactor: migrate 'ext/node' extension to virtual ops module (#22157)Bartek Iwańczuk
Follow up to https://github.com/denoland/deno/pull/22135
2024-01-10refactor: use `core.ensureFastOps()` (#21888)Kenta Moriuchi
2024-01-01chore: update copyright to 2024 (#21753)David Sherret
2023-12-03fix(ext/node): sign with PEM private keys (#21287)Divy Srivastava
Add support for signing with a RSA PEM private key: `pkcs8` and `pkcs1`. Fixes https://github.com/denoland/deno/issues/18972 Ref #21124 Verified fix with `npm:sshpk`. Unverfied but fixes `npm:google-auth-library`, `npm:web-push` & `oracle/oci-typescript-sdk` --------- Signed-off-by: Divy Srivastava <dj.srivastava23@gmail.com>
2023-11-09fix(node): implement createPrivateKey (#20981)Divy Srivastava
Towards #18455
2023-08-11fix(node): object keys in publicEncrypt (#20128)Divy Srivastava
Fixes https://github.com/denoland/deno/issues/19935
2023-07-02refactor: rename built-in node modules from ext:deno_node/ to node: (#19680)Bartek Iwańczuk
Closes https://github.com/denoland/deno/issues/19510
2023-06-27chore(ext/node): disable prefer-primordials on a per-file basis (#19553)Kenta Moriuchi
2023-04-06fix(ext/node): add symmetric keygen (#18609)Divy Srivastava
Towards #18455
2023-03-24feat(ext/node): implement crypto.createSecretKey (#18413)Divy Srivastava
This commit adds the `crypto.createSecretKey` API. Key management: This follows the same approach as our WebCrypto CryptoKey impl where we use WeakMap for storing key material and a handle is passed around, such that (only internal) JS can access the key material and we don't have to explicitly close a Rust resource. As a result, `createHmac` now accepts a secret KeyObject. Closes https://github.com/denoland/deno/issues/17844
2023-03-08refactor: rename InternalModuleLoader to ExtModuleLoader, use ext: scheme ↵Bartek Iwańczuk
for snapshotted modules (#18041) This commit renames "deno_core::InternalModuleLoader" to "ExtModuleLoader" and changes the specifiers used by the modules loaded from this loader to "ext:". "internal:" scheme was really ambiguous and it's more characters than "ext:", which should result in slightly smaller snapshot size. Closes https://github.com/denoland/deno/issues/18020
2023-03-05refactor(core): include_js_files! 'dir' option doesn't change specifiers ↵Bartek Iwańczuk
(#18019) This commit changes "include_js_files!" macro from "deno_core" in a way that "dir" option doesn't cause specifiers to be rewritten to include it. Example: ``` include_js_files! { dir "js", "hello.js", } ``` The above definition required embedders to use: `import ... from "internal:<ext_name>/js/hello.js"`. But with this change, the "js" directory in which the files are stored is an implementation detail, which for embedders results in: `import ... from "internal:<ext_name>/hello.js"`. The directory the files are stored in, is an implementation detail and in some cases might result in a significant size difference for the snapshot. As an example, in "deno_node" extension, we store the source code in "polyfills" directory; which resulted in each specifier to look like "internal:deno_node/polyfills/<module_name>", but with this change it's "internal:deno_node/<module_name>". Given that "deno_node" has over 100 files, many of them having several import specifiers to the same extension, this change removes 10 characters from each import specifier.
2023-02-14feat(ext/node): embed std/node into the snapshot (#17724)Bartek Iwańczuk
This commit moves "deno_std/node" in "ext/node" crate. The code is transpiled and snapshotted during the build process. During the first pass a minimal amount of work was done to create the snapshot, a lot of code in "ext/node" depends on presence of "Deno" global. This code will be gradually fixed in the follow up PRs to migrate it to import relevant APIs from "internal:" modules. Currently the code from snapshot is not used in any way, and all Node/npm compatibility still uses code from "https://deno.land/std/node" (or from the location specified by "DENO_NODE_COMPAT_URL"). This will also be handled in a follow up PRs. --------- Co-authored-by: crowlkats <crowlkats@toaxl.com> Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com> Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>