-
-
Notifications
You must be signed in to change notification settings - Fork 450
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
Fallback to super basic RNG in weak_rng if OsRng fails #180
Comments
We already have a rough suggestion to use the system clock as a fallback (see end of this comment). |
Some backstory: in Firefox bug 1409444, we are hitting weak_rng panics because OsRng fails for a few hundred Windows 7 users. This problem seems to be related to "corrupted DLLs" or anti-virus software. weak_rng should probably fall back to a weak seed on all platforms, not just Windows [7]. We've hit other OS RNG problems (not Rust or weak_rng specific) such as Firefox for Android failing to open("/dev/urandom") because the OS temporarily ran out of fds on some CI test machines (Firefox bug 1409444). |
At that point, should we just move entirely off of OsRng and on to the system clock or whatever? |
No, it's worth using But what's Firefox using random numbers for — presumably cryptography? In this case using a low-entropy source like the system clock is really not ideal. |
At this time, Firefox just uses Also, @Manishearth changed Firefox's HashMap seed to use an RNG other than |
To be clear, I changed the hashmaps used by Stylo to not use an RNG/cryptographically secure hasher and instead use FNV hash since hashmap DOS is not a problem for browsers. |
Right, well this is definitely something we want to fix with the rand refactor, but I suspect any changes coming through that will take a while (waiting for at least two RFCs to get merged, first 2152 which is still getting worked out, then |
Manishearth is pointing to a Firefox test failure where weak_rng panicked because StdRng::new() failed to read /dev/urandom on Linux. |
rust-lang/rust#44911 is a thing. Rayon uses weak_rng (for something? idk), and weak_rng will crash if the OsRng fails. Perhaps we should do something like take the system time and run it through some mixer in that case?
The text was updated successfully, but these errors were encountered: