-
Notifications
You must be signed in to change notification settings - Fork 5
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
Comments
I looked into this and In addition interface via rustls::CryptoProvider doesn't get the the provided impl for rustls::SecureRandom by design -
e.g. src/kx/x25519#L19 uses 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 Now we cannot relay directly that 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 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. |
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 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 ? |
Raised a feature request in rustls to support |
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 |
Currently there is
GenericRandomSigner
that plugs torand_core::OsRng
that requiresgetrandom
We'll need idiomatic API here to plug into provided Rng vs supplying one from here
The text was updated successfully, but these errors were encountered: