# Physical entropy source: How many bits entropy per byte is sufficent?

8 bit / byte would be perfect obviously.

head -c 1M /dev/urandom | ent

gives ~ 7.9998 bits per byte.

Now, if I have a physical entropy source, how much entropy is sufficent. E.g. my sound card produces 7.8 to 7.9 bits per byte for 1M raw data generated via randomsound.

My main question: Is this amount of entropy sufficient to inject it into the kernels entropy pool?

Clearly, the data from the sound card is internally scrambled again before it is used to produce random numbers. In the end, the resulting entropy is similar to 7.999 bits per byte.

• Any entropy is good entropy. The more the better. Quality doesn't matter only the overall entropy does. – SEJPM Jun 7 '15 at 15:42

First, take note of my answer to the question Estimating bits of entropy. A key phrase therein:

You'll never be able to look at a bitstream without knowing the distribution and say "there are X bits of entropy here."

The ent program doesn't know the distribution of the data it's looking at; instead it performs some statistical tests that any sufficiently-long random bitstream will pass with overwhelming probability. Here, I mean "pass" in the sense of having an "estimated entropy" near 8 bits per byte, which is exactly what truly random data has.

So, $$\text{bitstream is random} \implies \text{bitstream passes ent}$$ is about all we can say. Thus the (hidden) premise of your post - namely that because ent claims your soundcard's data looks random, it actually is random - is faulty. ent cannot be used to determine whether data is actually random. As an example, if a program has a fixed output, that output's entropy is 0 bits; but ent will declare otherwise since it does not have this external knowledge.

This is probably unnecessarily pedantic, but cryptography is a subtle science, and I think we need to acknowledge the particulars.

With all of that out of the way, can you feed your soundcard data into the kernel's random pool? So long as you trust that the soundcard hasn't been tampered with and actually is reporting random data, sure! For multiple reasons:

1. The soundcard isn't the only source of random data, so even if it is somewhat predictable, oh well - as long as it's not a malicious privileged device
2. If you feed random data into the Linux kernel as non-root, it doesn't use that source to increase the "entropy counter" at all: so it may be that your soundcard will act as a random source anyways, but not necessarily be counted as "random" by the kernel (n.b.: the entropy counter is of dubious value, but I am mentioning this for completeness)
3. The Linux kernel mixes and stirs "random" sources before presentation; it already doesn't much trust the sources to be uniformly random, etc

So with these reasons in mind, throwing any data you'd like into the kernel's random pool should be safe, even if the data isn't great. The exception is data that is carefully crafted with potential knowledge of the other random sources, as explained in the above link, but such a malicious source is a non-issue for most folks.

• Passing ent is at least some evidence, isn't it, that the entropy source is random? Clearly, ent cannot check empirically if the sequence is "normal" so that hidden structure cannot be detected. But ent also gives additional information, e.g., the percentage of compressibility. For instance a 1M sequence with 7.999 bit entropy per byte could not be compressed, however, a 2M sequence from the same source could be compressed by 50%. In such a case on should be careful, right? – curiosity Jun 8 '15 at 6:34
• @curiosity: Passing ent is a necessary but not sufficient condition for a random stream. If your stream fails ent, it (with overwhelming probability) isn't truly random. If your stream passes ent, it may or may not be truly random - but ent cannot determine which. It is a tool that is only useful as a negative indicator. – Reid Jun 8 '15 at 23:53
• @curiosity: For example, I just ran ent on a JPEG photo of me at a party. Result was Entropy = 7.970617 bits per byte but I can assure you that the picture is a far from being near truly random. – Reid Jun 9 '15 at 0:04
• So that means, I can never be sure, if my entropy source is truly random since there always might be some hidden structure for which I cannot test. Therefore, mixing as many different entropy sources as possible makes random number generation more secure and harder for an attacker to analyze. As a result, the only true entropy source would be something like a Geigercounter under the assumption that quantumphysics is correct, which I suppose it is (see Bell's theorem). – curiosity Jun 10 '15 at 5:32
• @curiosity: That's correct! As I linked above, there is a case where a malicious, privileged data source can actually decrease the security of a RNG when mixed into it, but this is essentially an edge case. – Reid Jun 11 '15 at 0:32

A simple analogy is prospecting. Consider entropy as being gold. Gold comes in veins of ore. The amount of gold in a kg of ore can vary. A higher percentage of gold means higher quality ore and thus higher rate of entropy. It's still entropy though and all gold is gold.

As to "sufficient", only you can answer that depending on your intentions. If you're playing with a Geiger tube, your rate of entropy will be low if you try to use it as a true random number generator, unless you get a lorry load of low salt salt and 100 smoke detectors. If you use it to generate a random seed for a pseudo random number generator then you can have an infinite amount of random numbers. These will of course be susceptible to analysis and possibly prediction dependant on your algorithms.