1

I read over and over about how /dev/random gets its entropy from "hardware events." What exactly are these hardware events and how can we be sure that it is random enough?

  • 4
    I recommend reading random.c, it has more code comments than actual code. Second-hand information will be less informative than just looking at the source. – rook Oct 28 '14 at 16:33
3

As @Rook says, a good starting point is the kernel source code itself, precisely the drivers/char/random.c file. It begins with a long description (as comments), including this passage:

Sources of randomness from the environment include inter-keyboard timings, inter-interrupt timings from some interrupts, and other events which are both (a) non-deterministic and (b) hard for an outside observer to measure.

The principal workhorse for the entropy gatherer is the add_interrupt_randomness() function, that is meant to be invoked for each (or at least most) interrupts. An interrupt is the main method by which a piece of hardware makes it known to the CPU that it has changed state, e.g. that some new data is available, or, similarly, that the hardware is ready to process new data from the CPU. E.g. you will get an interrupt every time you press or release a key, or move the mouse, or receive a network packet. You will also get interrupts from the timer, and from a lot of other sources. "Entropy" is obtained mostly by measuring the exact time at which the interrupt is received: modern CPU have a cycle counter that can be used to get a notion of time down to the nanosecond precision (precision, not accuracy, but that's good enough here). The type of interrupts are also included in the mix, but most of the entropy comes from these cycle counts.

Remember that "entropy" can be defined as "that which the attacker does not know". Through external measures and simulation, the attacker can get some notions of what occurs and when in the kernel, but within some limits. For instance, the attacker may measure the time of arrival of a network packet down to the microsecond; he will still miss 10 bits of entropy if the kernel measures that time down to the nanosecond.

Apart from interrupts, other kernel parts (e.g. device drivers) can push extra data into the pool by calling add_input_randomness(), in case such drivers have access to data that is considered "random" in some way (precisely, in a way that attackers cannot guess).

From userland, you can also push data manually by writing into /dev/random. One good source would be pictures from a webcam: that's a lot of data with a lot of thermal noise. Linux distributions use this "external entropy push" possibility to maintain entropy across reboots: when the machine boots, it injects a "seed file" that it then immediately recreates from /dev/urandom. Therefore, one big source of entropy for /dev/random is entropy obtained from previous incarnations of /dev/random (before the last boot).

  • is there any known malware that takes advantage of pushing data to /dev/random from userland to reduce entropy in the eyes of the malware? Could this even be a valid concern? – Anthony Kraft Oct 28 '14 at 17:50
  • @AnthonyKraft from what I understand, "pool compromise" is so difficult that there are much easier ways to compromise the OS directly. Basically don't worry about it. – Andrew Hoffman Oct 28 '14 at 18:01
  • 2
    By pushing data into the pool, you don't actually reduce the entropy; it does not evict old entropy or anything like that. What such pushing could do is somehow convince /dev/random that it has more entropy than it dreamt of, leading to it producing more bytes without blocking -- which is fine. It would just, at "worst", make /dev/random behave like /dev/urandom. /dev/urandom is cryptographically strong. (In fact /dev/random is useless and everybody should be using /dev/urandom, despite widespread myths.) – Tom Leek Oct 28 '14 at 18:08
  • Pushing from an unprivileged user never increases the available entropy. Writing to /dev/random doesn't call credit_entropy_bits, and the ioctl for mixing entropy requires CAP_SYS_ADMIN (root). – David Oct 28 '14 at 19:39
  • he will still miss 10 bits of entropy if the kernel measures that time down to the nanosecond. This isn't necessarily true. NICs often use interrupt coalescing which makes their timing more predictable. Even without that though, the APIC itself ticks at a far lower rate than the cycle counter, so the precision of measuring an interrupt may be significantly lower. – forest Apr 5 '18 at 1:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.