feat: Modular crypto #1292

richarddavison · 2025-12-15T21:43:11Z

Issue # (if available)

Description of changes

Refactor crypto and HTTP modules to support multiple TLS backends
This makes it easier to choose different Crypto & TLS implementations depending on deployment needs.

Checklist

Created unit tests in tests/unit and/or in Rust for my feature if needed
Ran make fix to format JS and apply Clippy auto fixes
Made sure my code didn't add any additional warnings: make check
Added relevant type info in types/ directory
Updated documentation if needed (API.md/README.md/Other)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Added support for rustls, graviola and OpenSSL TLS backends This makes it easier to choose different TLS implementations depending on deployment needs.

nabetti1720 · 2025-12-17T14:47:41Z

README.md

+
+| Feature              | Description                                   |
+| -------------------- | --------------------------------------------- |
+| `tls-ring` (default) | rustls with ring crypto                       |


While the default provider for crypto is a Pure-Rust implementation that excludes ring, tls defaults to ring. What about the idea of defaulting to a Pure-Rust implementation that supports the major cipher suites?

https://github.com/RustCrypto/rustls-rustcrypto

EDIT: Until the official support is released, we will create an experimental branch that supports the new rc crates.
https://github.com/nabetti1720/rustls-rustcrypto/tree/next

% make check cargo clippy --all-targets --all-features -- -D warnings Checking rustls-rustcrypto v0.0.2-alpha (/Users/shinya/Workspaces/rustls-rustcrypto) Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.15s % make build cargo +nightly build -r --target aarch64-apple-darwin Compiling rustls-rustcrypto v0.0.2-alpha (/Users/shinya/Workspaces/rustls-rustcrypto) Finished `release` profile [optimized] target(s) in 3.88s

@nabetti1720 I think the reason is that this is pretty much unmaintained:
https://github.com/RustCrypto/rustls-rustcrypto. Last commit was 2 years ago

@richarddavison Yes, so I am submitting a PR to update to the latest rustcrypto.
RustCrypto/rustls-rustcrypto#102

.github/workflows/build-modules.yml

To fix the issue, explicitly define minimal permissions for the workflow so the GITHUB_TOKEN is limited to what the job actually needs. In this case, the steps only need to read repository contents (for actions/checkout) and then run local build/test commands, so contents: read is sufficient.

The best way to do this without changing existing functionality is to add a root-level permissions block near the top of .github/workflows/build-modules.yml, applying to all jobs in the workflow. Concretely, insert:

permissions: contents: read

between the name: line and the on: section. No other changes (jobs, steps, or additional permissions) are required, since none of the steps perform write operations to GitHub resources. This preserves current behavior while constraining the token.

nabetti1720 · 2025-12-20T03:33:51Z

README.md

+| Feature                 | Description                                                       |
+| ----------------------- | ----------------------------------------------------------------- |
+| `crypto-rust` (default) | Pure Rust crypto using RustCrypto crates                          |
+| `crypto-ring`           | Ring-only crypto (limited algorithm support)                      |


Is there any point in providing partially supported features like crypto-ring or crypto-graviola?
By doing the following, it will be easier for users to choose a backend, and implementers will be able to optimize their internal implementations depending on the supported cipher suites of ring and glaviora without affecting users.

Feature Description

crypto-rust (default) Pure Rust crypto using RustCrypto crates

crypto-ring Ring for hashing/HMAC, RustCrypto for everything else

crypto-graviola Graviola for hashing/HMAC/AES-GCM, RustCrypto for everything else

crypto-openssl OpenSSL-based crypto

EDIT: If we want to follow the tls concept, we may want to support crypto-aws-lc.

Sytten

Almost there

Sytten · 2026-01-01T16:07:14Z

modules/llrt_tls/Cargo.toml

+
+# OpenSSL TLS backend
+tls-openssl = ["dep:openssl"]
+openssl-vendored = ["openssl?/vendored"]


You dont need to add a vendored feature everywhere.
Usually libraries will not even provide that feature, the user of the library just has to enable it on their on in their Cargo.tom by adding openssl as a dep and enabling the feature.
For you this would mean removing all the openssl-vendored features in all module crates and just adding it to the llrt/Cargo.toml. As long as it is enabled once, it is enabled everywhere since features are cumulative in rust and -sys crates can only appear one time in the build (cant have two version of the crate)

Sytten · 2026-01-01T16:07:54Z

modules/llrt_crypto/src/subtle/mod.rs

-            256 => Self::Aes256(cbc::Encryptor::new_from_slices(key, iv)?),
-            _ => return Err(InvalidLength),
-        };
+// AES variant types - only available with full subtle crypto support


This comment is unclear is you mean the _rustcrypto or the _subtlefull

I would also move that code in a different file, it makes reading this top mod hard

Sytten · 2026-01-01T16:16:27Z

modules/llrt_crypto/src/subtle/mod.rs

    Err(Exception::throw_message(ctx, "Algorithm not supported"))
 }
+
+// Stub implementations for when full subtle crypto is not available


Same idea here. For clarify I would do the following file structure:

subtle |-> import_key |-> mod.rs (export based on feature) |-> full.rs |-> stub.rs

Then later we can even create a more targeted feature only key import, key export, etc.
Also reading the code lightly I dont see dep in the import_key

Sytten · 2026-01-01T16:17:39Z

modules/llrt_http/Cargo.toml

+
+# OpenSSL TLS backend
+tls-openssl = ["llrt_tls/tls-openssl", "dep:hyper-openssl", "dep:openssl"]
+openssl-vendored = ["llrt_tls/openssl-vendored", "openssl?/vendored"]


Same idea here, you also dont need the ?

Sytten · 2026-01-01T16:18:10Z

modules/llrt_http/Cargo.toml


+# TLS crypto backend features (rustls-based)
+tls-ring = ["llrt_tls/tls-ring", "dep:hyper-rustls", "hyper-rustls?/ring", "dep:rustls"]
+tls-aws-lc = ["llrt_tls/tls-aws-lc", "dep:hyper-rustls", "hyper-rustls?/aws-lc-rs", "dep:rustls"]


You dont need the ? since the dep is requested just before it

Sytten · 2026-01-01T16:33:11Z

.github/workflows/ci.yml

+          - tls-ring
+          - tls-aws-lc
+          - tls-graviola
        include:


Unsure if you really need the include now?

Sytten · 2026-01-01T16:53:09Z

.github/workflows/build-modules.yml

+      tls_feature:
+        required: false
+        type: string
+        default: "tls-ring"


I would replace that with

crypto: required: false type: string default: "ring"

Sytten · 2026-01-01T16:53:45Z

.github/workflows/build-modules.yml

      - name: Setup Rust
        uses: actions-rust-lang/setup-rust-toolchain@v1
        with:
          toolchain: ${{ inputs.toolchain }}


Then add here:

- name: Map crypto feature to TLS and crypto features id: features shell: bash run: | case "${{ inputs.crypto }}" in graviola) echo "tls_feature=tls-graviola" >> $GITHUB_OUTPUT echo "crypto_feature=crypto-graviola" >> $GITHUB_OUTPUT ;; ring) echo "tls_feature=tls-ring" >> $GITHUB_OUTPUT echo "crypto_feature=crypto-ring" >> $GITHUB_OUTPUT ;; openssl) echo "tls_feature=tls-openssl" >> $GITHUB_OUTPUT echo "crypto_feature=crypto-openssl" >> $GITHUB_OUTPUT ;; aws-lc) echo "tls_feature=tls-aws-lc" >> $GITHUB_OUTPUT echo "crypto_feature=crypto-ring" >> $GITHUB_OUTPUT ;; *) echo "Unknown crypto feature: ${{ inputs.crypto }}" exit 1 ;; esac

You can add other cases if you want to mix and match

Sytten · 2026-01-01T16:54:11Z

.github/workflows/build-modules.yml

        uses: actions-rust-lang/setup-rust-toolchain@v1
        with:
          toolchain: ${{ inputs.toolchain }}
      - name: Run build crates


Then replace the following with

- name: Run build crates shell: bash env: RUSTFLAGS: "" TLS_FEATURE: ${{ steps.features.outputs.tls_feature }} CRYPTO_FEATURE: ${{ steps.features.outputs.crypto_feature }} run: | crates=$(cargo metadata --no-deps --format-version 1 --quiet | jq -r '.packages[] | select(.manifest_path | contains("modules/")) | .name') for crate in $crates; do echo "Compiling crate: $crate" # Use TLS feature for crates that need TLS, with --no-default-features to avoid conflicts if [ "$crate" = "llrt_fetch" ] || [ "$crate" = "llrt_http" ]; then cargo build -p "$crate" --no-default-features --features "http1,http2,webpki-roots,compression-rust,$TLS_FEATURE" elif [ "$crate" = "llrt_crypto" ]; then cargo build -p "$crate" --no-default-features --features "$CRYPTO_FEATURE" else cargo build -p "$crate" fi done - name: Run build all env: TLS_FEATURE: ${{ steps.features.outputs.tls_feature }} CRYPTO_FEATURE: ${{ steps.features.outputs.crypto_feature }} run: | cargo build -p llrt_modules --no-default-features --features "base,$TLS_FEATURE,$CRYPTO_FEATURE" - name: Run tests all env: TLS_FEATURE: ${{ steps.features.outputs.tls_feature }} CRYPTO_FEATURE: ${{ steps.features.outputs.crypto_feature }} run: | cargo test -p llrt_modules --no-default-features --features "base,$TLS_FEATURE,$CRYPTO_FEATURE"

Sytten · 2026-01-01T16:56:08Z

libs/llrt_test_tls/src/server.rs

+#[cfg(feature = "tls-graviola")]
+fn get_crypto_provider() -> Arc<rustls::crypto::CryptoProvider> {
+    Arc::new(rustls_graviola::default_provider())
+}


Missing a tls-openssl, you can use the rustls-openssl crate for that

Sytten · 2026-01-01T17:21:18Z

modules/llrt_crypto/src/sha_hash.rs

        let bytes = bytes.as_bytes(&ctx)?;
-        this.0.borrow_mut().context.update(bytes);
-
+        this.0.borrow_mut().data.extend_from_slice(bytes);


This is not ideal since it will keep the whole data in memory until digest.
hmac and hash are streaming encoding so you only keep buffer the size of the output + one block.
I think you can use the trick <crate::provider::DefaultProvider as CryptoProvider>::Hashmac.
Otherwise I would box the trait like Box<dyn HmacProvider>, the indirection is worth the space save.

Sytten · 2026-01-01T17:22:05Z

modules/llrt_crypto/src/sha_hash.rs

    fn hash_digest<'js>(&self, ctx: Ctx<'js>, encoding: Opt<String>) -> Result<Value<'js>> {
-        let digest = self.context.clone().finish();
-        let bytes: &[u8] = digest.as_ref();
+        let mut digest_hasher = CRYPTO_PROVIDER.digest(self.algorithm);


richarddavison added 6 commits December 15, 2025 10:21

WIP

c54bb81

Refactor crypto and HTTP modules to support multiple TLS backends

95c613f

Added support for rustls, graviola and OpenSSL TLS backends This makes it easier to choose different TLS implementations depending on deployment needs.

CI

c29dd0e

Allow all features

d94eee3

Fix fixtures

00ae1b4

pkg-config

a642718

richarddavison changed the title ~~feat: Mdular crypto~~ feat: Modular crypto Dec 16, 2025

richarddavison added 7 commits December 16, 2025 16:08

Vendored openssl

18d810b

Fix

0b44c08

Cleanup features

dd7330a

Tweak features

241e108

Do not use macos-14

9c8f534

Adjust features

43e4e58

Fix flags

cb01384

nabetti1720 reviewed Dec 17, 2025

View reviewed changes

Cleanup CI

a59d2ab

github-advanced-security bot found potential problems Dec 17, 2025

View reviewed changes

.github/workflows/build-modules.yml Fixed Show fixed Hide fixed

richarddavison added 2 commits December 18, 2025 15:18

Cleanups

7a3b6fa

Fix check

0cdb19c

richarddavison marked this pull request as draft December 18, 2025 15:26

richarddavison added 7 commits December 18, 2025 16:43

Features

5aa5473

Allow deadcode for providers with missing algos

1246c11

AES CPU feature detection

7656725

Format

003563f

Clippy

476ace9

Disable test

5eef3b6

Disable some tests

db9db46

github-advanced-security bot found potential problems Dec 19, 2025

View reviewed changes

richarddavison added 2 commits December 19, 2025 23:07

Disable tests

1602691

Gates

ce0d72a

nabetti1720 reviewed Dec 20, 2025

View reviewed changes

richarddavison and others added 3 commits December 21, 2025 21:59

Ignore if kill fails due to process already killed

80850f5

Merge branch 'main' into feat/modular-crypto

322f76d

Fix CI

b5cf8f1

Sytten suggested changes Jan 1, 2026

View reviewed changes

Sytten mentioned this pull request Jan 1, 2026

Hash and Hmac should return Buffer not TypedArray #1313

Open

@@ -1,4 +1,6 @@
             name: Setup, Build & Test modules
+            permissions:
+              contents: read
             on:
               workflow_call:
                 inputs:

Feature	Description
`crypto-rust` (default)	Pure Rust crypto using RustCrypto crates
`crypto-ring`	Ring for hashing/HMAC, RustCrypto for everything else
`crypto-graviola`	Graviola for hashing/HMAC/AES-GCM, RustCrypto for everything else
`crypto-openssl`	OpenSSL-based crypto

feat: Modular crypto #1292

Are you sure you want to change the base?

feat: Modular crypto #1292

Uh oh!

Conversation

richarddavison commented Dec 15, 2025

Issue # (if available)

Description of changes

Checklist

Uh oh!

nabetti1720 Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Check warning

Copilot Autofix

nabetti1720 Dec 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sytten left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

nabetti1720 Dec 17, 2025 •

edited

Loading

nabetti1720 Dec 20, 2025 •

edited

Loading