No! You call a blocking rand function bound by available entropy.
If your random source is compromised, adding two numbers from the same broken source does nothing. What you can do though, is XOR numbers from independent random sources to improve the entropy of the final output. (not sure if that's what you meant by adding random numbers together)
You can prove to yourself that XOR-ing independent sources of entropy works:
Just remember that XOR is commutative, so you can rearrange the terms. Then realize that a XOR is how you implement a one-time pad.
So if you xor together 5 sources of "entropy", #1 is super broken and outputs all zeros, #2 is secure and independent, #3 is an NSA program, and #4 and #5 are weak, broken RNG's....then it doesn't matter, because the XOR's can be rearranged in your mind so that it's clear that #2 is still acting as an OTP on the rest (comes last). As long as it is uniform and independent (key really does get thrown away) you are good to go -- by the definition of OTP. If it had less than full entropy, then that means an OTP would leave some recoverable information.
Meanwhile, of course, the sources DO need to be independent. If #3 knows the stream that #2 is outputing, by coming later in the chain and producing its output after #2 has produced it, it can undo it by simply copying the output of #2.
This is why independence is important.
So in summary each XOR independently implements a one-time pad on all the rest of the xor results, whilst throwing away the key. If even one out of one hundred sources is actually random, doesn't matter which one, then the result is just as good as if that were the source yuo were using directly. As long as they are independent sources.
Really? I would have expected better from you for your reputation. :-)
Read carefully what I said. Explained more clearly, XORing is at worst a ceiling function of the entropy of two random sources. If it weren't, that would imply one-time pad is insecure.
If you care about having good random bytes, you should call a blocking random function (i.e it doesn't return random data until enough entropy is collected)(e.g./dev/urandom).
If you don't care about security, you can certainly call one that always returns using a PRNG (/dev/random). However, with it being based on a much smaller random seed, using it to generate keys is massively reducing the key space an attacker would need to search for discovery.
In summary, reading from /dev/random is a blocking function bound by available entropy and it's more secure than it's /dev/urandom counterpart that is not bound by entropy.
I'm not sure what your problem is there. Care to elaborate?
Doing nothing but an XOR is usually fine but one thing to keep in mind is that an attacker that can see one stream and control the other could completely eliminate any entropy yet make the data look completely random.
This sounds like some unlikely scenario but for instance the Linux kernel uses a method like this for /dev/random. Entropy is collected and mixed in an entropy pool from many sources but at the end it is XORed with the output of Rdrand on processors that support it. The NSA could force Intel to sign a malicious microcode update that changes Rdrand to AES_encrypt(i++, NSA_KEY) ^ entropy_pool and then any random data coming from the kernel is completely predictable and without NSA_KEY it wouldn't be discernible from truly random data.
That's not really right. The other requirement for that scheme to work is to leak the entropy_pool as well. That's why the linux kernel random source IS safe from bad hardware. Even if the hardware source is completely known by a third party, they can't discern the output from random data because it has been XORed with random data.
If it helps to think about, imagine that the evil hardware always output 00000000 for a byte of randomness. The kernel then XORs that with a byte from the entropy_pool, which is unknown to the adversary. The output byte is still completely unknown to the adversary even though it knows one of the inputs.
I believe that chops was being sarcastic in ascribing a typical naive and useless attempt at "improving" randomness to "experts". Come on, "super random numbers"??
If your random source is compromised, adding two numbers from the same broken source does nothing. What you can do though, is XOR numbers from independent random sources to improve the entropy of the final output. (not sure if that's what you meant by adding random numbers together)