-
Notifications
You must be signed in to change notification settings - Fork 699
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
provide a mechanism to mark a custom getrandom
implementation as being SecureRandom
#1734
Comments
As part of the FIPS project we'll likely implement a CSPRNG within ring that then only requires an entropy source. Then we'll likely provide a pluggable API for the entropy source. Not too different from |
Also, please see #1406 (review) where I describe a mechanism to use |
We can do something just like |
this is more or less what I had in mind. I'll prepare a PR |
submitted PR #1754 |
Context: I'm working on adding no-std support to rustls and as part of that I'm building a small no-std demo that uses libc (instead of libstd) to perform networking. I'm using the "OS agnostic"
x86_64-unknown-none
target, which lacks a std implementation, to ensure libstd doesn't get sneakily used by a dependency but the demo will run on x86_64 Linux (for simplicity of testing it on CI but the demo should run on any (RT)OS that has a POSIX layer but lacks a libstd port).I'm trying to use ring as the cryptographic backend of rustls in no-std mode and I'm able to build rustls with the ring Cargo feature enabled and the "std" feature disabled (WIP PR: rustls/rustls#1502) for the
x86_64-unknown-linux-gnu
target but the build fails for thex86_64-unknown-none
target. I have tracked down the issue to thisSecureRandom
implementation:ring/src/rand.rs
Lines 127 to 149 in 2e8363b
The
x86_64-unknown-none
target has its "target_os" set to "none" so it doesn't match any of those conditionals. That means theSystemRandom
type cannot be used with API likeRsaKeyPair::sign
andEphemeralPrivateKey::generate
, which rustls uses when configured to use ring as its default crypto provider.Would it be possible for ring to provide a mechanism to mark a custom
SystemRandom
as beingSecureRandom
? As of ring v0.17.0, one can enablegetrandom
's "custom" feature to provide a customgetrandom
implementation which is whatSystemRandom
uses. My demo will run on Linux so my customgetrandom
implementation is the same as thex86_64-unknown-linux-gnu
implementation so it's also a "secure"getrandom
implementation.Perhaps a Cargo feature can be used as the mechanism? Similar to rustls' "dangerous" Cargo feature. Let's say "secure-custom-getrandom":
I think adding the
feature =
at theany
level is fine becausegetrandom
's documentation states that custom implementations only have an effect on unsupported targets so you cannot, for example, override the Linuxgetrandom
implementation.The text was updated successfully, but these errors were encountered: