Using raw encrypted network data for randomness

Question

I've read that encrypted data should be, theoretically, indistinguishable from random data. Using this principle of encryption, could I combine encrypted network traffic streams to generate either a seed for a randomness algorithm or simply combine them for the random number itself?

For example: I could take data from a Tails or other Tor connected device and simply specify which incoming node to listen to and for how long, not only would the attacker have to know I used this system but they'd have to know the index and duration of the nodes I choose.

For context: I only need a few MB of extremely random data at very infrequent intervals. So time and memory efficiency doesn't matter all that much.

To address a comment by DannyNiu: Obviously they now know this system exists but if it can run on any encrypted network then, as opposed to using a random number generator website, you do not know which computer is collecting network traffic for this purpose since any encrypted data could be used.

Answer 1

When we look for a source of randomness, we want something high entropy and hard to predict or control. Encrypted network traffic only matches the first criteria. An attacker may see the same network data and may control it. As such, it is not the best source of a random seed.

There are better sources available. Usually we don't want to rely on any one source but cryptographically mix several sources. So even if an attacker learns or controls one source, he will still not be able to predict our random data.

If you insist on using encrypted network traffic, you can mix it in with other sources, and mixing it in won't hurt and might even protect against some attackers not privy to the traffic, but you don't really need it. Use /dev/urandom. It's pretty good.

Answer 2

For Linux at least, the randomness that goes into /dev/urandom is already taken from the network. The difference between its scheme and yours is that it takes timing data instead of raw encrypted data. The reason for this is that timing data becomes harder to predict as you get farther away from the target, whereas raw traffic contents can be recorded trivially at any point in the path. This timing data comes from nanosecond timestamps of interrupts sent by the network interface device (NIC).

Taken from another answer I posted on another Stack Exchange site:

In modern hardware, an interrupt is a signal emitted by hardware to alert the CPU to a status change. It allows the CPU to avoid rapidly polling every hardware device for updates and instead trust that the device will asynchronously alert it when the time comes. When an interrupt occurs, an interrupt handler is called to process the signal. It turns out this handler is the perfect place to get randomness! When you measure the nanosecond-level timing of interrupts, you can quickly get a fair bit of randomness. This is because interrupts are triggered for all sorts of things, from packets arriving on the NIC to data being read from a hard drive. Some of these interrupt sources are highly non-deterministic, like a hard drive which relies on the physical motion of an actuator.

One caveat is interrupt coalescing, a feature supported by many modern NICs that batch interrupts to reduce per-packet overhead, rather than sending a separate interrupt for each received or transmitted packet. Depending on how it is implemented (count-based or timeout-based), it can potentially reduce the amount of entropy that can be gathered by the NIC. However, most NICs let you disable it.