GNOME Bugzilla – Bug 710736
Provide API to get non-PRNG random bytes
Last modified: 2018-05-24 15:45:30 UTC
Currently GRand seeds a private amount from /dev/urandom on Unix, and thereafter uses a PRNG. Some applications really want the equivalent of /dev/urandom or /dev/random directly, suitable for cryptographic or security domains. See: https://mail.gnome.org/archives/gdm-list/2007-November/msg00055.html I propose an API like: GBytes *g_random_from_system (gboolean blocking, guint bytes);
Also, we should clearly document that GRand should only be used for e.g. games which are shuffling card decks, not key generation and the like.
I think it would make more sense to have something like g_cryptographically_random(), i.e. 1) be explicit about the expected properties of the output (as opposed to "what the system gives us" which doesn't promise anything, especially for portable programs), and 2) thus give GLib the freedom to, in some future, change the underlying implementation from reading /dev/*random to something else that may be more suitable for generating such output. When glib provides HMAC, a crypto functionality, I think it can't avoid also giving applications a secure way to create the required keys. (One could also be fancy and have an API that distinguishes between short-term keys and long-term keys, but that's probably not worth worrying about.)
Why not a GInputStream?
(In reply to comment #2) > I think it would make more sense to have something like > g_cryptographically_random(), i.e. > 1) be explicit about the expected properties of the output (as opposed to "what > the system gives us" which doesn't promise anything, especially for portable > programs), and > 2) thus give GLib the freedom to, in some future, change the underlying > implementation from reading /dev/*random to something else that may be more > suitable for generating such output. GLib doesn't want to be in the business of trying to generate crytographically random data itself. So if the system can't provide it, then we don't have it. (It doesn't necessarily have to literally come from /dev/random, but it has to come from somewhere outside glib.) > When glib provides HMAC, a crypto functionality, I think it can't avoid also > giving applications a secure way to create the required keys. GHmac implements a specific set of algorithms that can be verified to be correct by testing their outputs against other implementations. A cryptographically-secure RNG is a much more complicated problem, and is to some extent even an unsolved problem.
(In reply to comment #4) > (In reply to comment #2) > > I think it would make more sense to have something like > > g_cryptographically_random(), i.e. > > 1) be explicit about the expected properties of the output (as opposed to "what > > the system gives us" which doesn't promise anything, especially for portable > > programs), and > > 2) thus give GLib the freedom to, in some future, change the underlying > > implementation from reading /dev/*random to something else that may be more > > suitable for generating such output. > > GLib doesn't want to be in the business of trying to generate crytographically > random dat itself. That's an implementation detail, not an API design issue. I'm not saying glib can't read /dev/*random, it just should not make that an API promise. > > When glib provides HMAC, a crypto functionality, I think it can't avoid also > > giving applications a secure way to create the required keys. > > GHmac implements a specific set of algorithms that can be verified to be > correct by testing their outputs against other implementations. That's fine for the GLib implementors, but it leaves applications in a difficult position of having to get the keys elsewhere. (Overall this may be read as a suggestion that GLib shouldn't be implementing anything, and should instead wrap an established and well-maintained crypto library; I do think along those lines, but all I want to achieve here is for the API to be useful; the implementation discussion is not currently interesting to me.)
(In reply to comment #5) > > (Overall this may be read as a suggestion that GLib shouldn't be implementing > anything, and should instead wrap an established and well-maintained crypto > library; I do think along those lines, but all I want to achieve here is for > the API to be useful; the implementation discussion is not currently > interesting to me.) But what would a crypto library do other than read /dev/{u,}random? Practically speaking for the purposes of GLib there are only two platforms that matter: the Unix families and Windows. http://en.wikipedia.org/wiki/Urandom is telling me that every Unix platform GLib could care about implements it. So I don't see a problem with explicitly saying in the API that's what it does. The nice thing about having it in GLib would just be: 1) We can have nicer error handling than the raw open("/dev/urandom") read() 2) We can use GBytes 3) It's an abstraction that makes it easier to move code to Windows, which is a substantial reason why GLib exists
As far as crypto libraries and GLib, you'll note that when Stef was proposing GHMac I raised that exact concern: https://bugzilla.gnome.org/show_bug.cgi?id=652480#c6 It's quite clear to me that we're never going to add anything approaching public/private crypto APIs to GLib. But a clean wrapper for the CSPRNG the OS itself already provides seems quite within scope.
(In reply to comment #6) > (In reply to comment #5) > > > > (Overall this may be read as a suggestion that GLib shouldn't be implementing > > anything, and should instead wrap an established and well-maintained crypto > > library; I do think along those lines, but all I want to achieve here is for > > the API to be useful; the implementation discussion is not currently > > interesting to me.) > > But what would a crypto library do other than read /dev/{u,}random? Typically, a crypto library reads a limited amount of data from /dev/{u,}random (perhaps as little as 256/512 bits, some read about 64 bytes and that's considered very excessive), and uses that to seed an internal cryptographic RNG that can produce a very large amount of data. AFAIK none of the major libraries just wrap a read() from /dev/{u,}random. > The nice thing about having it in GLib would just be: > > 1) We can have nicer error handling than the raw open("/dev/urandom") read() > 2) We can use GBytes > 3) It's an abstraction that makes it easier to move code to Windows, which is a > substantial reason why GLib exists These are all valid, and I really would like a "generate cryptographically random data" in GLib. Let's just not make the vague connection to "system" in there, please, and tell the applications exactly what they can expect to use the data for.
(In reply to comment #8) > (In reply to comment #6) > > But what would a crypto library do other than read /dev/{u,}random? > > Typically, a crypto library reads a limited amount of data from /dev/{u,}random > (perhaps as little as 256/512 bits, some read about 64 bytes and that's > considered very excessive), and uses that to seed an internal cryptographic RNG > that can produce a very large amount of data. AFAIK none of the major > libraries just wrap a read() from /dev/{u,}random. ... and to clarify, the above is not meant as an implementation advice or as an objection to GLib "just wrapping a read() from /dev/urandom"; only as a reason why the API should not describe it in those implementation-specific terms.
(In reply to comment #9) > ... and to clarify, the above is not meant as an implementation advice or as an > objection to GLib "just wrapping a read() from /dev/urandom"; only as a reason > why the API should not describe it in those implementation-specific terms. I see what you're saying, OK. "man urandom" is pretty clear about this. It would certainly significantly raise the complexity of a proposed patch to include a CSPRNG in GLib. But this is unfortunate because it seems to me the kernel is in an excellent position to provide large amounts of entropy on a per-process basis without each process having its own variants of a CSPRNG. It could easily have per-process state. But since it doesn't make sense to attempt to rearchitect everything here, I think the first thing we should do is just clearly document that GRand is not a CSPRNG, and point consumers at alternative (external) APIs.
Created attachment 257966 [details] [review] grand: Document this is not for cryptographic purposes While this is obvious to seasoned experts upon inspection, it is really worth documenting explicitly.
Review of attachment 257966 [details] [review]: sure, makes sense.
Comment on attachment 257966 [details] [review] grand: Document this is not for cryptographic purposes Attachment 257966 [details] pushed as 1e1e2d1 - grand: Document this is not for cryptographic purposes
(In reply to comment #10) > I see what you're saying, OK. "man urandom" is pretty clear about this. It > would certainly significantly raise the complexity of a proposed patch to > include a CSPRNG in GLib. ... (In reply to comment #3) > Why not a GInputStream? hm... GInputStream *g_tls_backend_get_random_stream (GTlsBackend *tls); ? (Or maybe the public API wouldn't reference GTlsBackend, but that's where it would come from eventually. And then glib-networking would implement it using gnutls's CSPRNG.)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/766.