# Tag Info

2

Like fkraiem's answer points out, passing a statistical test does not prove a PRNG is cryptographically random, or even statistically random with regard to other tests. In the case of RC4 the biases are most prominent in the beginning of the keystream. To borrow a useful illustration from Vanhoef and Piessens' "All Your Biases Belong To Us: Breaking RC4 in ...

1

Statistical tests have no value to evaluate randomness in a cryptographic sense, because an attacker is not required to use any specific test. The fact that a stream passes some set of predetermined tests tells you nothing about how it fares against tests which are not in the set.

2

From a practical point of view, what matters is not the entropy but the time an attack would take. A brute force attack would be dependent on the entropy of the input, since it works by guessing the seed. This is true regardless of the number of outputs observed. Typically a key/state recovery attack on DRBGs should not become easier with more outputs, ...

1

A Deterministic Random Bit Generator (DRBG) would typically be used, when you have entropy input that is either biased, inefficiently generated, or both of the above. If you have a True Random Bit Generator that outputs unbiased bits efficiently, there is no apparent reason to use a DRBG in the first place. This is particularly true in case you require ...

4

You are correct. The $Update$ function is called after each invocation of the $Generate$ function, and this does mean that chunking affects the output. Changing both the key and the nonce of an $AES-CTR$ key stream generator to uniformly selected (pseudo) random values will, of course, make the resulting key stream uniformly independent from what it would ...

1

I'm going to attempt to summarize everything I learned about this subject, thanks to the information and references provided by previous answers, as well as the research they spawned. Ultimately, the logic behind the warning is twofold (and mostly specific to Linux -- see "Another NOTE" below): The main crux of the issue stems from the way the Linux ...

2

$L$ is not necessarily a pseudorandom generator, but it may be. Hence, there is no hope of proving that $L$ is not a pseudorandom generator from what you are given. Rather, you must exhibit a pseudorandom generator $G$ such that $L$ is not a pseudorandom generator. Here is the canonical example with expansion factor $n+1$. Let $f$ be a one-way permutation ...

3

What you want to do depends on your objective. If you only want to make a good RNG from the values you have, so that it passes a Diehard test (passing the test being the objective), that's fine and easy. You do not need to know, or care, about how the values are obtained; essentially, you can take whatever form the "floating numbers" reach you (be it ...

1

As others have stated, the problem is the entropy pool. The operating system maintains a count of entropy in the pool that it decreases every time random numbers are generated from it and increases when it adds some timing or other information that is assumed to have entropy. Requesting numbers does not actually remove randomness from the pool in practice, ...

2

Others have described the difficulty in harvesting entropy, and how little entropy there really is available inside a computer, so I won't cover that. What you might want to be aware of is the existence of a sponge function. A sponge is a way of soaking up just a few bits of random entropy from a limited source, then squeezing out many "pseudo-random" ...

2

This is a really hard question to answer. The definitive answer can only be found in the source code of gpg. However I can still answer your question using a mail I found (from 2013, details may have changed). Is 2 "better" (i.e. more random) than 0? Yes, 2 is "better" than 0 and 1. As per the linked mail the quality level determines the number of ...

1

Your system accumulates a certain amount of entropy over time (in Unix systems, this randomness can be accessed at /dev/random). You, the user, is one source of randomness, but there are others too. It generally takes a while for considerable amount of entropy to accumulate. From the Linux man page of random: The random number generator gathers ...

0

You can read about this at Wikipedia: Entropy. Basically, computers are not capable of true randomness, the best they can do is to start with a seed value and roll it around a bunch of equations to get an output that looks random, but if an attacker knows your starting seed then it's not random at all. The problem then is in collecting sufficiently ...

Top 50 recent answers are included