Sign up ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Best ways to estimate average bits of entropy in a byte stream.

I know there are different statistical tests out there (NIST, Dieharder, etc), which all do different ways of analyzing entropy.

What I'm having a hard time finding is any particular literature which describes how to go from those tests to actual bits of entropy in the byte stream.

How do you go from p value of a byte stream (say a 100 MB long) to bits of entropy? And as an aside and very related — what are the "top 3" best ways?


As mentioned below, you can't estimate entropy of the output (not possible), but only by understanding the physics of the underlying process that generates the entropy.

share|improve this question
The common notion of entropy is the notion of Shannon entropy. The Shannon entropy H(x) of a value x that occurs with probability Pr[x] is H(x) = -log_2(Pr[x]). Related questions: and –  e-sushi Sep 18 '13 at 3:32
There are two issues with Shannon entropy: 1) It's only defined for a probability distribution, not for an individual string 2) Shannon entropy and average key-strength aren't exactly the same thing if the probability distribution isn't uniform. –  CodesInChaos Sep 18 '13 at 11:32
I've made some progress here. When I have a full answer, I will post it (especially given all the great help I've got it). I'm currently investigating Ping Li's work here: Ideally though I'd do something based off of NIST's work here: –  Blaze Sep 23 '13 at 22:16
Can you tell us more? Why do you want to measure the amount of entropy? What do you know about the source of the byte stream? The answer is going to depend heavily on the answers to these questions and on other details, so if you can give us more details, we might be more likely to be able to give you a good answer. This is not a simple subject with a simple one-line answer... –  D.W. Oct 1 '13 at 22:49
No, I can't. I really want to simply estimate entropy. –  Blaze Oct 3 '13 at 17:25

3 Answers 3

up vote 10 down vote accepted

Entropy is a function of the distribution. That is, the process used to generate a byte stream is what has entropy, not the byte stream itself. If I give you the bits 1011, that could have anywhere from 0 to 4 bits of entropy; you have no way of knowing that value.

Here is the definition of Shannon entropy. Let $X$ be a random variable that takes on the values $x_1,x_2,x_3,\dots,x_n$. Then the Shannon entropy is defined as

$$H(X) = -\sum_{i=1}^{n} \operatorname{Pr}[x_i] \cdot \log_2\left(\operatorname{Pr}[x_i]\right)$$

where $\operatorname{Pr}[\cdot]$ represents probability. Note that the definition is a function of a random variable (i.e., a distribution), not a particular value!

So what is the entropy in a single flip of a coin? Let $F$ be a random variable representing such. There are two events, heads and tails, each with probability $0.5$. So, the Shannon entropy of $F$ is:

$$H(F) = -(0.5\cdot\log_2 0.5 + 0.5\cdot\log_2 0.5) = -(-0.5 + -0.5) = 1.$$

Thus, $F$ has exactly one bit of entropy, what we expected.

So, to find how much entropy is present in a byte stream, you need to know how the byte stream is generated and the entropy of any inputs (in the case of PRNGs). Recall that a deterministic algorithm cannot add entropy to an input, only take it away, so the entropy of all inputs to a deterministic algorithm is the maximum entropy possible in the output.

If you're using a hardware RNG, then you need to know the probabilities associated with the data it gives you, else you cannot formally find the Shannon entropy (though you could give it a lower bound if you know the probabilities of some, but not all, events).

But note that in any case, you are dependent on the knowledge of the distribution associated with the byte stream. You can do statistical tests, like you mention, to verify that the output "looks random" (from a certain perspective). But you'll never be able to say any more than "it looks pretty uniformly distributed to me!". You'll never be able to look at a bitstream without knowing the distribution and say "there are X bits of entropy here."

share|improve this answer
Hmm, that doesn't seem to jive with what I've been asked unfortunately. I think if you have enough data and enough tests, you should be able to come up with a reasonable estimate of entropy. –  Blaze Sep 18 '13 at 0:33
I think what people are looking for is heuristic analysis + statistical analysis. For example, if I flip a coin, I can theoretically say 1 bit of entropy. Now, let's flip that coin 10 thousand times and do a statistical analysis to see if that measures up. If I get all heads, then so much for my heuristical analysis... I'm pretty sure this is the motivation. The part I'm missing is how to go from statistical analysis to 'bits per byte' of entropy. Note this request comes from experts. –  Blaze Sep 18 '13 at 2:53
@Blaze: My whole point is that you can't go from a statistical analysis to a measurement of entropy. If you happen to know how the bitstream is generated, then you can calculate the entropy directly (via the above formula) --- but if you don't know how it's calculated, then it simply can't be done. –  Reid Sep 18 '13 at 3:45
I would think we could pragmatically estimate entropy via a combination of statistics and good analysis. Empirically measure a statistical distribution on the lowest level of the entropy source that you can. Calculate $H$ where $Pr[x_i]$ is calculated from that distribution. How good an estimate of entropy this produces will rely on how good of a choice was made for "lowest level". Eg, if you chose the output of a PRG seeded by 0 you will have a false high entropy due to a poor decision. But if you choose a level the attacker won't have deeper insight to, the estimate should be good. –  B-Con Sep 18 '13 at 4:58
Do we have anything better than that for practical entropy estimates in real life? We don't (well, rarely) deal with truly random events, just events where we have a distribution and very little additional insight beyond that distribution. (Top of my head examples: hard drive seek times, mouse coordinates, etc. They aren't truly random, but at some level of detail you're stuck with a distribution of behavior and no way to analyze the source any more finely.) –  B-Con Sep 18 '13 at 5:03

There are some tests out there: Draft Special Publication 800-90B - National Institute of Standards

In particular the min-entropy, partial collections, Markov (useful for non-IID sources), collisions, and compression tests.

The issue with the Markov test is the constraint on bit size of the sample.


These tests only measure output. They don't measure the underlying entropy that was used to generate the data. You can take completely non random data and make it look perfectly random according to these tests (or any tests).

share|improve this answer
It's a fair point. I'll change the accepted answer. The standards were (are?) messed up. –  Blaze Jun 8 at 17:22
@Blaze: no, the standards are not messed up. Instead, they take a problem which (as Neil mentioned) is insolvable as defined, and try to come up with a good as an answer as they can practically come up with. What the tools do is come up with a ceiling on the entropy (we're pretty sure that there's no more than N bits of entropy there); that leaves open the question of a lower bound, but we don't know how to solve that problem. Anyone using the tool should realize its limitations. –  poncho Jun 8 at 18:53

I think if you have enough data and enough tests, you should be able to come up with a reasonable estimate of entropy

is an excellent comment that still seems not to have been resolved in practical terms. I've asked similar in How to practically measure entropy of a file?

There seems to be a great deal of smoke & mirrors regarding "entropy". Most people conflate entropy and random numbers to the point that they can't tell the difference between them.

Since he invented Entropy, let's go to the horse's mouth and see what Shannon actually said:

Can we define a quantity which will measure, in some sense, how much information is “produced” by such a process, or better, at what rate information is produced?

That's it. Simples. It's the amount of information, which makes total sense since he was interested in transmitting it though a communication channel. He wanted to know how much to transmit in the most efficient manner. It has nothing what so ever to do with underlying physics of the information source.

Shakespeare's total works are 5 MB long, and contain 2 bits /byte of entropy estimated by sophisticated binary tree analysis. It's also verified by just compressing the text. So Shakespeare's lifetime output as entropy was about 1 MB. But it isn't random. Don't try to use Shannon's log formula as it can't realistically be applied. ENT is absolutely rubbish for entropy estimation of general sources.

Random numbers are a somewhat philosophical concept. They do require some understanding of the underlying mechanism. For details, look at another question - Why is there no standard test for random number generators? So all random numbers are entropy, but not all entropy is random. However, this too can be debated vis a vis Kolmogorov complexity, but that's another question.

To date, I've only found the "top 1" best ways of practically estimating entropy. Compression. I now use a PAQ8 variant called fp8. Just compress the file and hey presto, your entropy estimate. To get random numbers though, you'll need to do some more work on the entropy.

share|improve this answer
Compression is a good way to put an upper bound on an entropy estimate, but in the end that's all it is. As compression methods improve, you need to adjust the estimate. So in some cases it's a good idea to reduce the compression estimate by e.g. a factor of two to be safe. –  otus Sep 5 at 13:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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