Return to Answer

Unfortunately, randomness is never optimal. It wouldn't be random then.

You don't normally consider the chi value itself. You transform it to a probability p based on the chi distribution and the number of degrees of freedom (255 in a byte's case). The p is then expected to be uniformly distributed between 0 and 1. Herein lies the problem. So one value doesn't really mean anything. A p of 0.01 is perfectly acceptable with a single run. If it's 0.01 over many runs, then your data isn't as expected. You should get all sorts of values up to 1. It's common then to perform a Kolmogorov–Smirnov (KS) test on the ps. You can use R, Python or code it yourself. I use Java's commons.math.

A note. If your chi = 0, your generator is broken as you never ever get a uniform distribution of bytes. Never. Interestingly, the chi for 2.5 billion decimal $ \pi $ digits is 12 which gives a p of ~0.2. Similarly, there is no such thing as an optimal chi value for IID bytes. That would be too easy. But also consider that it would be too easy for an attacker too if they knew exactly the distribution of bytes in a cipher. So what makes it hard for you to confirm randomness, is exactly the same thing that keeps a cipher secure. That's why they say that you can't mathematically prove randomness. You have to use the "duck" test.

The best way to visualise randomness is with the following random walk over 22 trillion $ \pi $ digits. Consider what the bias and chi values might be for the contents of the two boxes. They'd be wildly different, but both are perfectly correct as $ \pi $ is perfectly random. Your 254.3 value simple means that, meh, it's exactly 50/50 that your particular sequence is random. One value like that has little statistical significance.

Normal distributions or those based on a larger range are exactly the same method, with different numbers of degrees of freedom, but. Have a look here. But of course a TRNG doesn't output different distributions natively. All randomness extraction techniques output uniformly distributed bytes. And you can't have a normal distribution for discrete data like quantisized RNG bytes anyway. That would be a Binomial distribution with p $ \neq $ 0.5.

Unfortunately, randomness is never optimal. It wouldn't be random then.

You don't normally consider the chi value itself. You transform it to a probability p based on the chi distribution and the number of degrees of freedom (255 in a byte's case). The p is then expected to be uniformly distributed between 0 and 1. Herein lies the problem. So one value doesn't really mean anything. A p of 0.01 is perfectly acceptable with a single run. If it's 0.01 over many runs, then your data isn't as expected. You should get all sorts of values up to 1. It's common then to perform a Kolmogorov–Smirnov (KS) test on the ps. You can use R, Python or code it yourself. I use Java's commons.math.

A note. If your chi = 0, your generator is broken as you never ever get a uniform distribution of bytes. Never. Interestingly, the chi for 2.5 billion decimal $ \pi $ digits is 12 which gives a p of ~0.2. Similarly, there is no such thing as an optimal chi value for IID bytes. That would be too easy. But also consider that it would be too easy for an attacker too if they knew exactly the distribution of bytes in a cipher. So what makes it hard for you to confirm randomness, is exactly the same thing that keeps a cipher secure. That's why they say that you can't mathematically prove randomness. You have to use the "duck" test.

The best way to visualise randomness is with the following random walk over 22 trillion $ \pi $ digits. Consider what the bias and chi values might be for the contents of the two boxes. They'd be wildly different, but both are perfectly correct as $ \pi $ is perfectly random. Your 254.3 value simple means that, meh, it's exactly 50/50 that your particular sequence is random. One value like that has little statistical significance.

Normal distributions or those based on a larger range are exactly the same method, with different numbers of degrees of freedom, but. Have a look here. But of course a TRNG doesn't output different distributions natively. All randomness extraction techniques output uniformly distributed bytes. And you can't have a normal distribution for discrete data like quantisized RNG bytes anyway. That would be a Binomial distribution with p $ \neq $ 0.5.

Unfortunately, randomness is never optimal. It wouldn't be random then.

You don't normally consider the chi value itself. You transform it to a probability p based on the chi distribution and the number of degrees of freedom (255 in a byte's case). The p is then expected to be uniformly distributed between 0 and 1. Herein lies the problem. So one value doesn't really mean anything. A p of 0.01 is perfectly acceptable with a single run. If it's 0.01 over many runs, then your data isn't as expected. You should get all sorts of values up to 1. It's common then to perform a Kolmogorov–Smirnov (KS) test on the ps. You can use R, Python or code it yourself. I use Java's commons.math.

A note. If your chi = 0, your generator is broken as you never ever get a uniform distribution of bytes. Never. Interestingly, the chi for 2.5 billion decimal $ \pi $ digits is 12 which gives a p of ~0.2. Similarly, there is no such thing as an optimal chi value for IID bytes. That would be too easy. But also consider that it would be too easy for an attacker too if they knew exactly the distribution of bytes in a cipher. So what makes it hard for you to confirm randomness, is exactly the same thing that keeps a cipher secure. That's why they say that you can't mathematically prove randomness. You have to use the "duck" test.

The best way to visualise randomness is with the following random walk over 22 trillion $ \pi $ digits. Consider what the bias and chi values might be for the contents of the two boxes. They'd be wildly different, but both are perfectly correct as $ \pi $ is perfectly random. Your 254.3 value simple means that, meh, it's exactly 50/50 that your particular sequence is random. One value like that has little statistical significance.

Normal distributions or those based on a larger range are exactly the same method, with different numbers of degrees of freedom. Have a look here. But of course a TRNG doesn't output different distributions natively.

Unfortunately, randomness is never optimal. It wouldn't be random then.

You don't normally consider the chi value itself. You transform it to a probability p based on the chi distribution and the number of degrees of freedom (255 in a byte's case). The p is then expected to be uniformly distributed between 0 and 1. Herein lies the problem. So one value doesn't really mean anything. A p of 0.01 is perfectly acceptable with a single run. If it's 0.01 over many runs, then your data isn't as expected. You should get all sorts of values up to 1. It's common then to perform a Kolmogorov–Smirnov (KS) test on the ps. You can use R, Python or code it yourself. I use Java's commons.math.

A note. If your chi = 0, your generator is broken as you never ever get a uniform distribution of bytes. Never. Interestingly, the chi for 2.5 billion decimal $ \pi $ digits is 12 which gives a p of ~0.2. Similarly, there is no such thing as an optimal chi value for IID bytes. That would be too easy. But also consider that it would be too easy for an attacker too if they knew exactly the distribution of bytes in a cipher. So what makes it hard for you to confirm randomness, is exactly the same thing that keeps a cipher secure. That's why they say that you can't mathematically prove randomness. You have to use the "duck" test.

The best way to visualise randomness is with the following random walk over 22 trillion $ \pi $ digits. Consider what the bias and chi values might be for the contents of the two boxes. They'd be wildly different, but both are perfectly correct as $ \pi $ is perfectly random. Your 254.3 value simple means that, meh, it's exactly 50/50 that your particular sequence is random. One value like that has little statistical significance.

Normal distributions or those based on a larger range are exactly the same method, with different numbers of degrees of freedom, but. Have a look here. But of course a TRNG doesn't output different distributions natively. All randomness extraction techniques output uniformly distributed bytes. And you can't have a normal distribution for discrete data like quantisized RNG bytes anyway. That would be a Binomial distribution with p $ \neq $ 0.5.

Unfortunately, randomness is never optimal. It wouldn't be random then.

You don't normally consider the chi value itself. You transform it to a probability p based on the chi distribution and the number of degrees of freedom (255 in a byte's case). The p is then expected to be uniformly distributed between 0 and 1. Herein lies the problem. So one value doesn't really mean anything. A p of 0.01 is perfectly acceptable with a single run. If it's 0.01 over many runs, then your data isn't as expected. You should get all sorts of values up to 1. It's common then to perform a Kolmogorov–Smirnov (KS) test on the ps. You can use R, Python or code it yourself. I use Java's commons.math.

A note. If your chi = 0, your generator is broken as you never ever get a uniform distribution of bytes. Never. Interestingly, the chi for 2.5 billion decimal $ \pi $ digits is 12. Similarly, there is no such thing as an optimal chi value for IID bytes. That would be too easy. But also consider that it would be too easy for an attacker too if they knew exactly the distribution of bytes in a cipher. So what makes it hard for you to confirm randomness, is exactly the same thing that keeps a cipher secure. That's why they say that you can't mathematically prove randomness. You have to use the "duck" test.

The best way to visualise randomness is with the following random walk over 22 trillion $ \pi $ digits. Consider what the bias and chi values might be for the contents of the two boxes. They'd be wildly different, but both are perfectly correct as $ \pi $ is perfectly random.

Normal distributions or those based on a larger range are exactly the same method, with different numbers of degrees of freedom. Have a look here. But of course a TRNG doesn't output different distributions natively.

Unfortunately, randomness is never optimal. It wouldn't be random then.

You don't normally consider the chi value itself. You transform it to a probability p based on the chi distribution and the number of degrees of freedom (255 in a byte's case). The p is then expected to be uniformly distributed between 0 and 1. Herein lies the problem. So one value doesn't really mean anything. A p of 0.01 is perfectly acceptable with a single run. If it's 0.01 over many runs, then your data isn't as expected. You should get all sorts of values up to 1. It's common then to perform a Kolmogorov–Smirnov (KS) test on the ps. You can use R, Python or code it yourself. I use Java's commons.math.

A note. If your chi = 0, your generator is broken as you never ever get a uniform distribution of bytes. Never. Interestingly, the chi for 2.5 billion decimal $ \pi $ digits is 12 which gives a p of ~0.2. Similarly, there is no such thing as an optimal chi value for IID bytes. That would be too easy. But also consider that it would be too easy for an attacker too if they knew exactly the distribution of bytes in a cipher. So what makes it hard for you to confirm randomness, is exactly the same thing that keeps a cipher secure. That's why they say that you can't mathematically prove randomness. You have to use the "duck" test.

The best way to visualise randomness is with the following random walk over 22 trillion $ \pi $ digits. Consider what the bias and chi values might be for the contents of the two boxes. They'd be wildly different, but both are perfectly correct as $ \pi $ is perfectly random. Your 254.3 value simple means that, meh, it's exactly 50/50 that your particular sequence is random. One value like that has little statistical significance.

Normal distributions or those based on a larger range are exactly the same method, with different numbers of degrees of freedom. Have a look here. But of course a TRNG doesn't output different distributions natively.