TLS ISAAC never reseeds #4709
Milestone
Comments
This was referenced Feb 11, 2013
bors
added a commit
that referenced
this issue
Feb 15, 2013
For Issue #4709: **c531506 rt: rand.rs expects `rust_next()` to return `uint32_t`, not `size_t`** rand.rs expects `rustrt::rand_next()` to return `u32`, but the `rand_next()` C function returns `size_t`: https://github.com/mozilla/rust/blob/ca71c6ec5bb8106121cbe33eec5a6a9ca7786039/src/libcore/rand.rs#L34 **f4320b6 move isaac RNG utility functions to new rust_rng.cpp file** **665e900 encapsulate isaac RNG in `rust_rng` struct** Move isaac's `randctx` into a `rust_rng` struct to make names similar to `rand::Rng` function names and prepare for auto-reseeding in the next commit. **9a78dc9 reseed `rust_rng` after generating 32KB** Precedents from other languages: * Haskell's `GenAutoReseed` generator reseeds itself after generating 32KB: http://hackage.haskell.org/packages/archive/DRBG/0.1.2/doc/html/Crypto-Random-DRBG.html#t:GenAutoReseed * Go's RNG reseeds itself after generating 1MB: https://code.google.com/p/go/source/browse/src/pkg/crypto/rand/rand_unix.go?name=go1.0.3#94 **9a76d71 don't deplete RNG entropy when there is only one runnable task** `rust_sched_loop::schedule_task()` unnecessarily calls `isaac_rand()` for the common case when there is only 1 runnable task, thus depleting RNG entropy and incurring unnecessary overhead.
|
closed by 0a1fcad |
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In #4687 we redirected our hashtables to draw their randomization from the TLS ISAAC instance. This instance is not reseeded at all as
/dev/urandomis, not even best-effort (eg. when the scheduler is idle or such). It should. As it stands, the mere existence of the TLS ISAAC instance is a security risk to users.The text was updated successfully, but these errors were encountered: