How much more secure is encryption if the program requires random input from the user?

Question

I know there are existing questions about how Truecrypt uses mouse input to increase entropy. My question is, how much of a difference does it make? I don't know of any other encryption utilities that do this, so does this mean the rest of them (like 7-zip) are unsafe? To my knowledge the typical way of doing this is to use the computer time as the seed to the random number generator, which in a sense is the same as user input as an attack doesn't know (to the millisecond) when the user presses the button. How much more secure is encryption if it uses user input like moving the mouse or random keyboard strokes?

Answer 1

TL;DR:

None, really. Modern computers generate high-quality entropy ("randomness", essentially) fast enough that you wiggling your mouse is irrelevant.

More detail:

Programs like Truecrypt (and possibly older versions of things like ssh-keygen, gpg, and so on) that tell you to do stuff during key generation are operating on the assumption that the OS may not have very fast entropy sources other than user interaction and/or a very small entropy pool for its cryptographically secure pseudo-random number generator (CSPRNG). On old computers, especially without Internet connections or enough resources to run a lot of background processes, this was probably true at least some of the time.

Modern computers are pretty good at entropy generation and have relatively large entropy pools that can easily cough up enough pits to generate a key. Additionally, these days it is common to use CSPRNGs that support stretching entropy (on *nix OSes, this would be the difference between /dev/random, which pulls from the entropy pool directly, and /dev/urandom which can take a small amount of entropy from the pool and use it to generate a large number of slightly-less-random bits; /dev/urandom is, on modern OSes, still generally good enough for key generation). It's still theoretically possible to end up with machines that have predictable kernel entropy pools (a bunch of identical VMs running on identical headless machines running identical software versions started at the same time, etc. may sometimes have the same kernel entropy initially), but it's not easy. This kind of thing is why modern VM hosts have ways to feed some entropy to the VM guests based on the hardware states, etc. that are usually used in kernel entropy generation these days.

Most modern CPUs even have what amount to hardware RNGs based on things like the thermal state of the different parts of the CPU chip, which vary rapidly depending on things like exactly what instructions have been run recently and whether they caused cache misses or not, miniscule variations in voltage from the power supply, air movement in the room, and other stuff like that; the differences are slight, but taken together there's a lot of entropy there and the CPU has dedicated hardware for harvesting it and new opcodes for providing it to the OS. Many OSes mix this into their kernel entropy pool, along with other inputs, making it very hard to exhaust entropy under normal "user" workloads on a modern PC.

IMPORTANT:

There is no CSRPNG in the world that is seeded to any significant degree off of the system clock! The reason why is simple. You seem to think that "to the millisecond" timing is sufficiently random for crypto, but you're quite wrong about that. Let's take something like generating a GPG key pair as an example. Those generally have a validity period on their public keys, which tells me (I have your public key, it is after all public) when the key was generated, to the day. There are 86400000 ms in a day (ignoring the fact that I can probably narrow that down a lot by considering hours when a person is likely to be awake). Log2(86400000) is 26.36 bits. Your supposedly super-secure 4096-bit RSA key pair actually has less entropy than a decent-quality password! Brute-forcing 86400000 different possible key pairs to find the corresponding private key will take a while, but a hell of a lot less time than trying to factor a 4096-bit RSA public key. In fact, there aren't enough milliseconds since the dawn of electronic computing to produce a fully-random DES key (56 bits) by choosing from among them, and we can brute-force DES in under a day using off-the-shelf hardware (yes, RSA key generation takes a lot more work than just taking 56 bits and computing their parity for DES key generation, but it's still fast enough for this purpose).

Instead, any crypto program that isn't purely worthless garbage (and quite a few that are) use a CSPRNG (such as /dev/urandom on Unix-like systems, or CryptGenRandom() on Windows) for key generation. Similarly, most programming language standard libraries include at least two PRNGs: a fast but insecure one for stuff where it doesn't actually matter if somebody could theoretically predict the output (in Java, this is java.util.Random), and a cryptographically-secure one, usually either seeded by or directly just returning the output of the OS CSPRNG, for stuff like crypto (in Java, this is java.security.SecureRandom). No PRNG seeded by the current time, regardless of algorithm it uses, could ever be considered cryptographically secure; the search space is just too small.

Answer 2

Basically zero.

Operating systems already integrate every source of potential randomness that they can get their hands on in order to seed their randomness APIs (examples being CryptGenRandom() on Windows, /dev/urandom on POSIX variants, getrandom(2) on Linux, and getentropy(2) on FreeBSD). These sources include mouse movements, disk timings, and other unpredictable events.

The thing is, once you reach a certain point — say 256 bits of collected entropy, which takes less than a few seconds in practice — the operating system can generate an effectively unlimited stream of unpredictably random numbers for the remaining lifetime of the system. Many operating systems even save this internal state upon reboots, preventing the need to reinitialize the system random number generator from scratch ever again. More entropy at that point doesn't really get you more unpredictability, and collecting mouse movements is already done as part of this process anyway.

Additional entropy does allow for the operating system to recover from theoretical exposure or tainting of its internal random state, but this is very unlikely to occur in practice on a non-compromised machine.

To my knowledge the typical way of doing this is to use the computer time as the seed to the random number generator…

No cryptographically-secure RNG uses the system clock for this purpose. As @CBHacking points out, this is an exceedingly weak source of random numbers, since "what time is it" is highly predictable (and sometimes easily influenced by outside sources). Microsecond-level timings of human input can also be semi-predictable, but collecting and mixing this data repeatedly can very quickly yield a good source of entropy. Modern RNG mixing functions are very good at extracting and combining even small amounts of entropy.