# Using raw encrypted network data for randomness

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.

• "not only would the attacker have to know I used this system", I'm the attacker, and I know it now. It's useless if you disregard the Kerckhoff's 2nd principle. Better combine them with a secret value. – DannyNiu Jan 15 at 3:07
• /dev/urandom or Windows equivalent any good? – Paul Uszak Jan 15 at 3:44
• My OG idea was to combine /dev/urandom from different systems to increase the system noise you could draw from, because each system noise has slight patterns. Ideally, you could do this openly over a network. But if you live in a regime that takes all this data, they would know that the randomness came from that particular network once they discovered it's purpose. My idea is, if those in said regime hooked up to a randomly chosen encrypted network instead it would not reveal their intent of getting random data and therefore the regime wouldn't know which network to check. (theoretically) – Matt Jan 15 at 4:43
• Ah! "because each system noise has slight patterns" is worth exploring because I believe that you're underestimating the cryptographic quality of /dev/urandom. Unless you're looking to create one time pads... – Paul Uszak Jan 15 at 17:52
• I'm creating all the basic cryptography components and putting them together in my little experiments. This is just a general purpose RNG to go with the set. i am aware that /dev/urandom is currently sufficient. This is just an experimental "what if it wasn't". – Matt Jan 16 at 3:16

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.

• I'm simply trying to design a basic RNG as part of a training exercise, I actually do use /dev/urandom. The core of my idea is that, presuming you lived in a major city, there are many encrypted networks to draw from quickly and, very crucially, the code breaker wouldn't know which network you did this on and at what time. That's the actual core to this theoretical strategy, but it would all fall apart if there were inherit patterns in modern encrypted data. – Matt Jan 15 at 11:40
• If you assume he attacker can see the same network traffic which is a reasonable assumption you are only relying on a secret method to select which network to take data from, which isn't much security. – Meir Maor Jan 15 at 11:47
• The assumption is that if I were to take a data for even a few minutes, there would be no way to know which few minutes were taken from or which network. So as the networks kept running while you weren't taking data from them that would passively add to the potential time-frames you could have possibly taken from. And there's no guarantee that this would only be done over the course of a few minutes or in one instance. – Matt Jan 16 at 3:10
• How do you select the network? how do you select the timing? are you using a random source to produce random source? It's not bad if you started with a random source it's similar to a book cipher. – Meir Maor Jan 16 at 5:38
• The justification for my beginner ideas is that this could work with the upmost of basic equipment. You could you an ultra basic method such as rolling dice to get local physical coordinates and the index of which network to choose. Using a PRNG to select the stream indexes would effectively allow a PRNG to eliminate any reliance on specific numbers it tends to produce. So if you had a very basic WiFi device with an insufficient PRNG, you could still get numbers that are sufficiently random. I myself don't need to do this. I'm just justifying a usage for my system. – Matt Jan 16 at 22:52

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.