RNG dependency injection into signature operations

[jnicholls]

I think it would be useful for certain operations (encode, sign, etc.) to have an alternative method that accepts a ring::rand::SecureRandom RNG provider as an argument, or some other means to inject that dependency. Internally where an RNG is used, the crate currently creates a SystemRandom on demand. For cases where a different CSRNG (e.g. a different source of entropy) is deisred, or in mock testing scenarios where deterministic signature output is desired, this feature would be very useful.

I don't have an opinion on the surface-level API. Perhaps encode_with_rng and sign_with_rng. For the RNG itself, it would make the most sense to create a trait owned by this crate e.g. jsonwebtoken::crypto::Rng w/ the same sort of interface as ring::rand::SecureRandom, and do a blanket impl<R> Rng for R where R: ring::rand::SecureRandom { ... }.

[Keats]

I'm not sure it makes sense. Where would this be needed except from WASM? If you want reproducible JWTs for tests, don't use RSA or EcDSA

[jnicholls]

WASI and Node.js WASM, since you mentioned it.

[jnicholls]

Buuuut, since you mentioned that I'll check in with Brian and see if we can just add those targets to ring directly.

[aweis89]

Would love to be able to use this crate with WASI as well

[Keats]

@jnicholls any update from the ring side?

[jnicholls]

Unfortunately no, the only WASM target that is supported are browser environments with crypto.getRandomValues() available. WASI's random_get method is still not yet supported.