On Wed, Mar 13, 2019 at 11:35:33AM -0700, Richard Henderson wrote: > On 3/13/19 10:57 AM, Daniel P. Berrangé wrote: > > We already have an internal API for providing strong random bytes in > > QEMU qcrypto_random_bytes. It is preferentially backed by gnutls or > > gcrypt, but if those aren't built-in it falls back to a platform > > native API like /dev/random. I've got a todo item to make that use > > getrandom on Linux/BSD when available. > > > > I don't think we should be adding a new APIs for getting random > > numbers that aren't backed by the qcrypto_random_bytes. > > That's all very well and good for one particular use case, when we really want > random numbers. But with -seed, we want to be able to replicate one > particular > execution, with fully deterministic numbers. > > But certainly I can look into making the non-deterministic execution use your > existing interface. I simply wasn't aware of it.
The random interfact is pluggable with different impls though they are chosen at build time currently. I guess we could provide an impl that is backed by a deterministic source and require a special CLI option or env var to switch to this insecure mode at runtime. > Do you happen to know off-hand the maximum latency of the gnutls/gcrypt > interfaces? I do want the interface to be able to return "timed-out" in > certain cases. With getrandom(2) there is a handy GRND_NONBLOCK parameter > that > pretty much matches exactly what I want. With /dev/{u,}random, one would have > to use O_NONBLOCK. With BSD getentropy, I think you'd need an alarm to time > out the operation (unless EIO covers all sorts of failures like empty entropy > pool; the manual isn't clear)? I don't think there's any documented latency rules for the library interfaces. Most of the time I think they should have deterministic execution time as they'll just be running a cryptographic hash algorithm of some kind, but they might periodically re-seed entropy from the host OS. They're really supposed to be considered a black box from the application user POV. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|