Expose cryptography backends via CryptoProvider #452

arckoor · 2025-10-17T14:55:48Z

Adds a CryptoProvider struct that allows replacing the built-in providers with something custom.
All the details from this implementation that could be considered "interesting" are stolen straight from rustls's CryptoProvider.

I've marked the new_signer, new_verifier and JWK functions from the two built in backends as pub, so you can do stuff like this:

fn new_signer(algorithm: &Algorithm, key: &EncodingKey) -> Result<Box<dyn JwtSigner>, Error> {
    let jwt_signer = match algorithm {
        Algorithm::EdDSA => Box::new(CustomEdDSASigner::new(key)?) as Box<dyn JwtSigner>,
        _ => jsonwebtoken::crypto::aws_lc::new_signer(algorithm, key)?,
    };

    Ok(jwt_signer)
}

i.e. overwrite just specific algorithms.

One area I'm a little unsure about is JwkUtils, 1) about the name and 2) about the Default implementation. The CryptoProvider::signer_ and CryptoProvider::verifier_factory functions are obviously mandatory for a custom provider, but not everyone uses JWK, so the default just uses dummy functions with unimplemented!().

arckoor · 2025-11-25T18:23:33Z

@Keats any chance of a review on this?

drusellers · 2025-12-02T16:30:59Z

Would this allow applications to use rustls rather than openssl?

arckoor · 2025-12-02T18:03:11Z

@drusellers As far as I know rustls doesn't implement the cryptography directly, rather it relies on other crates like ring, aws-lc-rs, rustcrypto, ...
So you can't really use rustls with this, but you can implement the cryptography with whatever backend you choose, be it openssl, botan, or something else entirely (this crate has aws-lc-rs and rustcrypto built in, using these doesn't require this PR)

Keats

I think this can be simplified

Keats · 2025-12-08T13:47:30Z

examples/custom_provider.rs

+    };
+
+    assert_eq!(my_claims, claims);
+}


Could we use a real crypto lib as an example?

Keats · 2025-12-08T13:58:24Z

src/crypto/rust_crypto/mod.rs

+}
+
+/// Given some data and a name of a hash function, compute hash_function(data)
+pub fn compute_digest(data: &[u8], hash_function: ThumbprintHash) -> Vec<u8> {


can those functions be pub(crate) rather than pub? For both files

Well if they are pub(crate) it would mean you can't use them externally, so the intent with making them pub was that you can overwrite e.g. the ES256 signing with a crypto lib of your choosing, but keep the utility functions from either of the built in crypto libs, but your choice.

Keats · 2025-12-08T14:00:21Z

src/crypto/macros.rs

+                Algorithm::PS384 => Box::new(rsa::RsaPss384Signer::new(key)?) as Box<dyn JwtSigner>,
+                Algorithm::PS512 => Box::new(rsa::RsaPss512Signer::new(key)?) as Box<dyn JwtSigner>,
+                Algorithm::EdDSA => Box::new(eddsa::EdDSASigner::new(key)?) as Box<dyn JwtSigner>,
+            };


that will get more complex if we start supporting some alg in some backend like #461

Keats · 2025-12-08T14:02:43Z

src/crypto/mod.rs

+    pub(crate) fn get_default() -> Option<&'static Arc<CryptoProvider>> {
+        PROCESS_DEFAULT_PROVIDER.get()
+    }
+}


Do we need that? We should be able to define a DEFAULT_PROVIDER using cargo features I think without needing the dance around that?

IIUC you mean that it automatically sets PROCESS_DEFAULT_PROVIDER to aws_lc::CryptoProvider if the aws feature is enabled? Yes that could be done, but similar to the JWK utility functions, that would mean you have to replace everything when you implement a custom provider, because otherwise if you select one of the built in features, you'd be locked into that provider.
This way you can implement whatever you want to, enable both aws and custom-provider, and fallback to aws for everything you haven't implemented.

My understanding of custom providers is that you do not want to add the rust-crypto/aws-lc dependencies? That feels a bit awkward otherwise

I feel that way, yes, others may not, I do not know. I did it this way because rustls did it this way, but I can change it if you want me to.

All that said while it could be assigned automatically for the rust_crypto and aws_lc_rs features, it still needs to provide a set method for outside crypto providers, and I'm honestly not sure how to do it any other way.

Unless you want a

#[cfg(feature = "custom-provider")] static PROCESS_DEFAULT_PROVIDER: OnceLock<Arc<CryptoProvider>> = OnceLock::new(); #[cfg(not(feature = "custom-provider")] # assign from crate features

which I personally think is pretty ugly.

Keats · 2025-12-08T14:04:24Z

src/decoding.rs

+pub enum DecodingKeyKind {
+    SecretOrDer(Vec<u8>),
+    RsaModulusExponent { n: Vec<u8>, e: Vec<u8> },
+}


Just make it pub for everyone no? Easier to keep track for breaking changes

Keats · 2025-12-08T14:06:02Z

src/decoding.rs

    pub(crate) kind: DecodingKeyKind,
+    #[cfg(feature = "custom-provider")]
+    #[cfg_attr(feature = "custom-provider", allow(missing_docs))]
+    pub kind: DecodingKeyKind,


Same as above, or we should expose some getters/setters rather than having sometimes private sometimes public fields

Expose cryptography backends via CryptoProvider

370f904

arckoor force-pushed the custom-provider branch from 4483fd7 to 370f904 Compare October 17, 2025 15:57

Keats mentioned this pull request Oct 19, 2025

Notable increase in transitive dependencies and of binary size between 9.3.1 and 10.1.0 #455

Closed

Keats requested changes Dec 8, 2025

View reviewed changes

Expose cryptography backends via CryptoProvider #452

Are you sure you want to change the base?

Expose cryptography backends via CryptoProvider #452

Conversation

arckoor commented Oct 17, 2025

Uh oh!

arckoor commented Nov 25, 2025

Uh oh!

drusellers commented Dec 2, 2025

Uh oh!

arckoor commented Dec 2, 2025

Uh oh!

Keats 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants