This was an interesting discussion for me to follow and I learned some new things. I did my own research and found this https://www.2uo.de/myths-about-urandom/ which was a fairly thorough interpretation of how things work and parrots in more detail what Ted said.
Tl;dr: Just use /dev/urandom!
" The man page for /dev/random and /dev/urandom is pretty effective when it comes to instilling fear into the gullible programmer's mind:"
Thanks Eric
-----Original Message----- From: Venegas Munoz, Jose Carlos [mailto:jose.carlos.venegas.munoz@intel.com] Sent: Tuesday, September 25, 2018 3:33 PM To: Boeuf, Sebastien sebastien.boeuf@intel.com; Theodore Y. Ts'o tytso@mit.edu; Jon Olson jonolson@google.com Cc: kata-dev@lists.katacontainers.io Subject: Re: [kata-dev] /dev/urandom or /dev/random
Thanks for the feedback!
-----Original Message----- From: Boeuf, Sebastien [mailto:sebastien.boeuf@intel.com] Sent: Tuesday, September 25, 2018 5:26 PM To: Theodore Y. Ts'o tytso@mit.edu; Jon Olson jonolson@google.com Cc: kata-dev@lists.katacontainers.io Subject: Re: [kata-dev] /dev/urandom or /dev/random
Thanks for the feedback Ted.
I am glad I've asked as it feels safer to go with /dev/urandom solution now :)
Thanks, Sebastien ________________________________________ From: Theodore Y. Ts'o [tytso@mit.edu] Sent: Tuesday, September 25, 2018 3:15 PM To: Jon Olson Cc: Boeuf, Sebastien; kata-dev@lists.katacontainers.io Subject: Re: [kata-dev] /dev/urandom or /dev/random
On Mon, Sep 24, 2018 at 04:40:13PM -0700, Jon Olson wrote:
+tytso@mit.edu -- Ted, I know you had some thoughts on seeding +virtio-rng from /dev/urandom (not sure the listserv will let you post, but it should catch at least Sebastien and I).
My recommendation is to just seed virtio-rng from /dev/urandom. Here's why. /dev/urandom provides a cryptographic random number generator, and assuming it is adequately initialized, that should be *fine* for pretty much all practical purposes. And on the sort of systems you would be using as a Host, there are enough hardware devices that /dev/urandom will be initialized very quickly --- in practice, well before any VM's will be started.
Furthermore, all modern x86 systems have RDRAND by now, and on those systems, the host kernel will mix RDRAND output with CRNG before sending the random numbers out via getrandom(2) or /dev/urandom.
From a guest perspective, you have to trust the Host system anyway. The host as the ability to read or modify arbitrary guest memory, including that used by the kernel. The host can mess with the guest kernel before it's booted, or change the contents of the emulated hard drive. So trusting that the host CPU has implemented RDRAND correctly isn't a stretch. So even if the customer running the VM is a tin-foil-hatter who believes the NSA may have backdoored RDRAND and not have it be discovered or leaked out, in most cases, they aren't the sort of people who would want to use a cloud infrastructure. They're much more likely to want to use hardware which always stays under their personal control.
And even if you *do* believe the NSA has somehow managed to sneak a backdoor into Intel CPU designs without it become public, that still means that you have to break the CRNG. And practically speaking, assuming it's been initialized correctly, if you can break the CRNG, we've got much bigger problems, since that implies you can't trust the basic crypto primitives we use to secure our entire internet.
Cheers,
- Ted
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev