On Sun, Aug 18, 2013 at 10:14 AM, Ben Laurie <b...@links.org> wrote: > ... my advice is that you probably should not run Linux if you need > strong randomness.
i am surprised this has not surfaced more often in this thread: if you need good entropy: use a hardware entropy generator! also use a userspace entropy collector like dakarand or haveged, use a userspace entropy daemon for seeding system entropy pool (/dev/random) from hardware sources (like /dev/hw[_-]?random, unless you trust RDRAND ;) this is true no matter what operating system you use, where on a clean boot in a headless system you must choose between denial of service or silent insecurity. not to mention being under served in unexpected high usage situations, like initializing full disk crypto volumes with /dev/random or extremely high volume web server endpoints with high entropy utilization requirements. if you are running virtual machines this implies virtio random devices or VM safe instructions (if you trust RDRAND ;) to provide strong entropy within the guest systems as well. not to mention proper administration to ensure you're saving seeds and not sharing pool state between instances, etc. over ten years ago i wrote a threaded entropy daemon for the C5XL XSTORE instruction that provided megabits of entropy from /dev/random after configuring the MSR for XSTORE, sanity checks in the mtrngd, and writing to /dev/random when poll indicated users had consumed entropy from the system, thus ensuring /dev/random never went dry. ten years later and still the state of the consumer, embedded, and enterprise markets is totally inadequate, with the one recent ray of hope (RDRAND) intentionally obfuscated in a way that threatens trust. WTF in short, if you are not doing one or more of the following: - hardware rng with userspace daemon for hw rng - userspace entropy collector (haveged, dakarand, others) - securely seeded and re-seeded CSRNG (for VMs with boot and runtime entropy passing) you are doing it wrong. it is just a matter of risk/cost to exploit your use of "randomness"! (and the above does not mitigate your risk, it merely makes other risks your new weakest link, of course ;) _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
