[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Cryptokit.Random unsuitable in cooperative multithreaded systems
There are two distinct scenarios for key generation - generating a long lived key (say, an SSH host key that's persisted to disk and "never" changes) for which /dev/random is the right choice, and generating immediate keys for an automated process (e.g. SSL session keys), for which /dev/urandom is probably better. It's the same RNG that /dev/random uses, and it's not significantly more reversible than whatever crypto you're generating keys for. The trivial DoS from opening lots of connections and handshaking until the entropy pool runs dry is a much bigger security risk than using /dev/urandom for key generation.
On Wed, Apr 24, 2013 at 8:29 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote: Mirage is just a collection of libraries, so we need to split up random number usage into a few scenarios:
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |