Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API for providing Rng #41

Closed
Tracked by #51
pinkforest opened this issue Mar 15, 2024 · 5 comments
Closed
Tracked by #51

API for providing Rng #41

pinkforest opened this issue Mar 15, 2024 · 5 comments

Comments

@pinkforest
Copy link
Contributor

pinkforest commented Mar 15, 2024

Currently there is GenericRandomSigner that plugs to rand_core::OsRng that requires getrandom

We'll need idiomatic API here to plug into provided Rng vs supplying one from here

@pinkforest pinkforest mentioned this issue Mar 16, 2024
12 tasks
@pinkforest
Copy link
Contributor Author

pinkforest commented Mar 17, 2024

I looked into this and Send + Sync being required everywhere makes things interesting with self-mutable csprng.

In addition interface via rustls::CryptoProvider doesn't get the the provided impl for rustls::SecureRandom by design -

but this is not included in the interface with rustls: it is assumed that the cryptography library provides for this itself.

e.g. src/kx/x25519#L19 uses x25519_dalek::EphemeralSecret::random_from_rng(rand_core::OsRng);

Question is how do we relay / get the csprng impl to e.g. kx x25519 as above without creating other trouble.

Effectively we need it to be x25519_dalek::EphemeralSecret::random_from_rng(relay_csprng);

Now we cannot relay directly that relay_csprng here since rustls is the one that calls the relevant implementation within the implemented CryptoProvider here and where the relayed mutable csprng would have to come from a stored state given we are not relaying the call from the user of this crate who would hold states etc.

Using self-mutable impl would require creating a holder-struct somewhere leading to all sorts of complications navigating the Arc<RwLock|Mutex<_>> landscape and spinlock/lock-free stuff given both the RngCore and the provided SecureRandom are self-mutable

Or hardcoding the used RngCore impl (OsRng) into CryptoProvider as is done now everywhere.

What kind of interface if any would be possible that doesn't involve keeping state in the middle given the integration ?

Given dalek expects Rng to be supplied to itself - cannot supply this to it without keeping state in the middle.

Doing this via features would lead to same trouble as was with dalek backend selection and rng is mutually-exclusive cfg.

@pinkforest
Copy link
Contributor Author

pinkforest commented Mar 18, 2024

So the dilemma here is:

The crypto primitives have started to adopt - e.g. x25519-dalek - construction with random_from_rng(&mut rng) e.g. x25519-dalek::EphemeralSecret

This is different to rustls which expects cryptography primitive to supply it's own rng from within itself unlike the above.

This leads to dependency to std /permutations of having to handle the randomness source at the primitive which may be different from each other and inflexibility for chosen randomness source.

I'm wondering if rustls be open to either support rand_core::CryptoRng or at least the ability to pass rustls::SecureRandom to lower level primitives which expect / favor something like it ?

Otherwise people would need to effectively write their own providers with their given provider of randomness separately leading to endless permutations of CryptoProvider which may not be always maintained etc.

Or a CryptoProvider needs to handle all the different permutations of randomness leading to all sorts of dependencies.

I see downstream need for wasm, embedded and host rand which would pass their own implemented CryptoRng.

Note CryptoRng offers several methods over SecureRandom so preference would be rustls to adopt CryptoRng ?

@pinkforest
Copy link
Contributor Author

Raised a feature request in rustls to support rand_core::CryptoRng

@pinkforest
Copy link
Contributor Author

We can't really do anything here given rustls doesn't want to support it so closing this issue.

However we can document the mechanism how to override getrandom with custom instead to describe no_std compatbility.

Superceded by

@pinkforest pinkforest closed this as not planned Won't fix, can't repro, duplicate, stale Mar 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants