RDRAND backend about getrandom HOT 12 CLOSED

So you don't think we should support Linux older than 3.17 (and I don't know what Solaris version)?

In near-mid term future for getrandom crate I think we should use the version will fallback. But when (and if) we will get a language-level support for getrandom, I believe we should consider the minimum supported Linux kernel version which will be supported by Rust out-of-box. It's part of a broader discussion, as I believe there were some issues with non-compatible OS versions (Fedora IIRC) for which we don't have any way to differentiate at compile time. Also if I am not mistaken Rust explicitly has dropped support for Windows XP.

With Solaris there are two issues:

• Syscall was introduced in 11.3 while Solaris 10 will be supported until 2021 (and Solaris 11 will be supported until 2034, dunno if support is extended to older minor version)
• There are OpenSolaris derivatives which may not have syscalls and again we don't have any way to differentiate between them at compile time.

So again until we will get an ability to overwrite getrandom by applciations, I think we should keep the current code.

from getrandom.

ISC is legally equivalent to MIT, yes.

from getrandom.

For SGX target I think we can use rdrand intrinsic directly, as code is quite simple. But there is a question about whether we should use RDRAND or RDSEED here. Here is a blog post from Intel regarding the difference between them. Even though getrandom will be often used for seeding I think we should still stick with the RDRAND.

from getrandom.

RDRAND is absolutely the right place to start. The arguments for RDSEED are generally in conjunction with using it to seed a userspace CSPRNG “For Speed”, which is more or less what RDRAND provides but as a CPU intrinsic.

Using RDRAND directly has a very tiny code surface comparatively, along with well-understood properties. If people want to experiment with building higher performance RNGs on top of RDSEED, I think that should be done separately (i.e. both approaches have merit but different tradeoffs aroynd security vs performance)

from getrandom.

The the linked blog, it sounds (vaguely) similar to the /dev/random and /dev/urandom distinction on Linux. In theory we could have two "grades" of quality for our getrandom, but it sounds completely unnecessary (from what I understand, most crypto experts recommend using /dev/urandom in all cases, aside from early boot (not applicable here) and information-theoretical security).

from getrandom.

From here:

I still plan to discuss using RDRAND as a backup option.

Personally I am strongly against it. As I've wrote earlier I believe that we should keep getrandom as thin as possible, especially considering potential inclusion into std. Plus making it overwritable in future will allow users to use any fallback strategy they would like.

from getrandom.

I would personally prefer this crate be kept as simple as possible with no built-in fallbacks. I think fallbacks should be pushed up a level into crates like rand_os.

If I do wind up using this crate directly directly in lieu of rand_os, I can manage RDRAND fallback on my own (I expect I wouldn't actually implement fallback, but instead just use RDRAND for SGX targets).

If this crate were to implement RDRAND exclusively for SGX targets (since no other options make sense), that'd be fine by me though.

from getrandom.

This paper is worth a view on the topic on RDRAND and RDSEED security: Shrimpton T., Terashima R.S. (2015) A Provable-Security Analysis of Intel’s Secure Key RNG.

At this point we already have a minimal RDRAND implementation for SGX. Interestingly, @jethrogb disagrees that SGX implies RDRAND.

@newpavlov mentions that this lib should be a very thin wrapper, however we already have some level of abstraction: probing for getrandom sys-call support on Linux and Solaris, otherwise using the old interface. There is little difference there.

In terms of extra code, the addition would not be very heavy. @nagisa's lib is 472 lines, including a lot of doc and support for next_u* functions plus RDSEED which we don't need. Run-time overhead would be negligible, compile-time and code-size overhead low.

In terms of trust, one must already have some trust in the CPU, and as @tarcieri has noted this only has any implication on certain three-letter-agencies, who are often sensibly excluded from threat models.

This is something applicable to many users and a small addition. I have nothing against making it a separate function (e.g. getrandom_with_fallback), but think it would be a very nice thing to include?

from getrandom.

Interestingly, @jethrogb disagrees that SGX implies RDRAND.

It's true. RDRAND won't necessarily be available, and the Intel SDK tests for it at runtime. If it's not available though, there aren't other practical options to fall back to.

from getrandom.

we already have some level of abstraction: probing for getrandom sys-call support on Linux and Solaris, otherwise using the old interface. There is little difference there.

And as you can judge by #5 I dislike it. Depending on OS support policy I hope we will be able to remove it on inclusion into std.

I guess I wouldn't mind including RDRAND fallback for x86 Windows targets, and only if it will be confirmed that the problem which originally caused the introduction of fallback is still present on supported Windows versions (meaning XP will not count). But I don't see any sensible reasons for adding such arch-specific fallback for all targets.

from getrandom.

Regarding the need for a fallback: see here (and also the last post, where it is suggested this is no longer a significant issue).

So I guess we could drop the idea.

Secondarily, in support of that, @nagisa's crate is established and optimised for the various RngCore methods, thus it would make more sense to have the fallback at the RNG-level than here.

Depending on OS support policy I hope we will be able to remove it on inclusion into std.

So you don't think we should support Linux older than 3.17 (and I don't know what Solaris version)?

from getrandom.

I think this issue is concluded: we won't implement fall-back sources in this lib.

from getrandom.