On Tue, Feb 28, 2017 at 7:57 AM, Niels Möller nisse@lysator.liu.se wrote:
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
And to answer myself, I do not think we need something complex as yarrow in gnutls. Older systems may have needed it, but today we can rely on /dev/urandom and getentropy() interfaces, and as such I no longer it is necessary to bring that complexity to gnutls.
Makes sense to me too. But do you plan any fallback for other systems? I guess one could require the use of some separate randomness gathering daemon.
No. Few releases ago I've dropped support for EGD (entropy gathering daemon). No-one has complained so I guess such special systems most likely use specialized libraries rather than "OS" libraries like gnutls.
What about MacOS and Microsoft Windows, do they have something comparable to /dev/random these days?
Both are supported via their native interfaces. Newer versions of MacOS have getentropy() and older ones have /dev/urandom. Windows has CryptGenRandom() for quite some time.
Then I'd expect that there are quite some systems out there, where getting adequate randomness isn't easy. Like small embedded systems, and it's also unclear to me how /dev/random works on virtual machines. But just using a mixer like yarrow or fortuna isn't enough, since the tricky problem is the sourcing of the mixer.
In such small systems, even something like the (now-legacy) EGD would be insufficient. Each of them would require some custom code, which could be abstracted as a system call like getentropy() - especially if that gets into posix. I don't think it makes sense to add code for such systems without ensuring that it handles a large class of it, or that at least it is a very common system to ignore.
regards, Nikos