On Tue, Feb 28, 2017 at 7:57 AM, Niels Möller <[email protected]> wrote: > Nikos Mavrogiannopoulos <[email protected]> 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 _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
