https://bugzilla.redhat.com/show_bug.cgi?id=970009 --- Comment #38 from Kevin Cernekee <cernekee@xxxxxxxxx> --- (In reply to David Woodhouse from comment #23) > For an application the question is a bit simpler. If the app needs to > generate random numbers often and fast, then using rdrand directly is the > way to go. Otherwise, just use the library and don't worry about it. > > However, it's a bit harder for the library. I suppose it wants to be > optional, and the distribution packager needs to do the right thing. Or > perhaps this is just another case of Debian and Ubuntu being a bit behind > the curve. We update the libraries to assume that rngd is doing it, and when > we finally have current software in .deb form it'll all work out OK. Well, this bothered me enough to try fixing the Debian rng-tools package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692450 > Getting back vaguely on-topic... it occurs to me that stoken could probably > just open /dev/random and read from it to get a random number. You don't do > this often, right? It's only for 'stoken import --random'? And thus it is > /dev/random not /dev/urandom that you need? /dev/random is really slow if there's not a lot of entropy saved up - to the point where "stoken-gui --random" lags for a minute or two unless I ask the user to furiously move his mouse around. Either way makes for a substandard user experience. The RNG is used for two purposes in stoken: 1) Generating random tokens - per the man page this is for novelty purposes only. We can't convert our ctf seeds back into sdtid seeds yet, and even if we could, we can't generate the RSA signature needed to make the official SecurID server believe they are authentic. Maybe someday libstoken will be able to help perform service-side authentication, but we're not there yet so the random tokens are fairly useless except for testing. 2) Creating a random IV to encrypt the PIN, if the user elects to encrypt his seed + PIN in ~/.stokenrc. At this point /dev/urandom is probably good enough for both use cases, and that is what libtomcrypt uses (at least on Debian). > In fact, I'd much rather see pkgconfig(gtk+-3.0) and it doesn't look > particularly hard, but neither of those observations make it a review failure. Will revisit this in the next few months - also planning to switch over to GtkBuilder and add a basic "import token" dialog to the GUI. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=GDdqLEDIxU&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review