4

There's a couple of programs that I've been using recently that ask you to type random keys as a source of randomness to seed an RNG for key generation.

Is this considered a good practice still, or is it better to rely on /dev/urandom and company as an entropy source?

Anders
  • 65,582
  • 24
  • 185
  • 221
Stack Tracer
  • 544
  • 2
  • 5
  • 16
  • 2
    These applications usually ask you to do this to provide additional entropy, in combination with the CSPRNG offered by your OS. – Polynomial Feb 26 '19 at 23:39
  • By the time your operating system has gotten far enough in the boot process that you would be prompted to perform such a task, there's already more entropy in /dev/urandom than will ever be needed. At best, it does nothing. At worst, they mix that input with /dev/urandom themselves in a way that reduces the overally quality of the entropy. – Stephen Touset Feb 26 '19 at 23:48
  • @StephenTouset Case #2 is more what I'm worried about (what if they're not using /dev/urandom at all, and this is the only source of entropy?) – Stack Tracer Feb 27 '19 at 02:20
  • If they're not using /dev/urandom at all (everyone should use the getrandom syscall with flags = 0 if they can) then chances are good that they messed up their user space RNG implementation. I would assume they're not qualified to write cryptography related code. (Using just the output from getrandom/urandom is sufficient.) – Future Security Feb 27 '19 at 03:46
  • I'm not convinced my keystrokes and my mouse movements add a noticeable amount of entropy compared to what my system finds on its own just from background processing happening on my system. And I try to keep my system as idle as feasible. – Ed Grimm Feb 27 '19 at 03:56
  • @EdGrimm They absolutely do. Each keystroke adds at least a bit, which should be obvious. Since we only need about a hundred bits, you don't need many keystrokes to seed a random number generator. Keystrokes and the like are actually the primary source of entropy. Embedded systems that lack a HID (Human Interface Device) like a mouse or keyboard can become very entropy starved when they boot. – forest Feb 27 '19 at 04:03
  • @forest I'm not saying they don't add to it. But it feels like my computer gets a lot more of its entropy from other sources. I can understand a computer that's not fully booted may not have much in the way of entropy generation if the system has an archaic init. In that case, if you have a process that needs entropy, it's probably all that's active. A lot of people may dislike systemd in that space, but they really could use some of its concepts. – Ed Grimm Feb 27 '19 at 04:19
  • @EdGrimm Well where do you think it does get it? For Linux, the primary source is interrupts via keystrokes and the mouse or from the input subsystem directly. It also gets some from hard drive timing and network packet timing, but far less. Also, the init system has nothing to do with whether or not it gets seeded properly. It doesn't matter if it's plain sysv or systemd. See https://security.stackexchange.com/q/183506/165253 – forest Feb 27 '19 at 04:22
  • @forest from your link: The Linux kernel uses only the arrival times of events to estimate their entropy. It does that by interpolating polynomials of those arrival times, to calculate “how surprising” the actual arrival time was, according to the model. Those events can be any events that the kernel as some expectation for how quickly they should happen, not just keyboard and mouse. It's a nebulous answer, because I don't even know half the stuff that goes on in my computer. The harddrive is acting much less chaotically if the init is serialized. – Ed Grimm Feb 27 '19 at 04:27
  • @EdGrimm The events are primarily interrupts, specifically from the hard drive, network interface, and keystrokes. The vast majority of injections into the pool come from keystrokes. See the comments in the source, titled Exported interfaces ---- input. Note also that calculating "how surprising" is only done via the input subsystem and for disk reads, not for interrupts which don't affect the entropy estimate. – forest Feb 27 '19 at 04:30
  • Let us continue this discussion in chat. – forest Feb 27 '19 at 04:34
  • @FutureSecurity That may be true, but unfortunately, there's plenty of open source projects that have really sketchy crypto. – Stack Tracer Apr 05 '19 at 23:36

1 Answers1

2

Yes, but that's how you're getting randomness anyway. In Linux and most other operating systems, the exact time in nanoseconds that a key is pressed is recorded and injected into the entropy pool. This pool is used to seed the CSPRNG that powers /dev/urandom and other cryptographic random APIs.

The similar /dev/random character device is what we describe as blocking. It assumes that all used cryptographic functions are broken (a worst-case scenario) and so will only output randomness when it thinks it has "collected" enough entropy. When you type keys, the operating system uses that as a source of entropy and increases the entropy estimate, causing /dev/random to unblock. This speeds up the entropy collection by programs using that device. Now that doesn't mean that the program sare doing the right thing. They should have just used /dev/urandom which does not block and is still quite cryptographically secure. You should take a look at https://www.2uo.de/myths-about-urandom.

A related document on best practices for randomness generation is BCP 106.

forest
  • 66,706
  • 20
  • 212
  • 270
  • Which thing are you answering "yes" to? Using keypresses for randomness is good enough, or it's not good enough? – Stack Tracer Apr 05 '19 at 23:35
  • @StackTracer Yes to both. Generating random keys based on keystroke timing is proper, but that's how your OS does it already, so you can safely rely on /dev/urandom. So it is good enough, but you should use the built-in operating system API to do so. – forest Apr 05 '19 at 23:45