You were wrong then and you could have easily known you were wrong then. This new disclosure doesn't make you righter or wronger in retrospect.
https://news.ycombinator.com/item?id=6195707
It wasn't days, but I can't say for sure that it was minutes... my vote would be for hours! :)
And I'm saying that as a prominent Bitcoin user and not-so-prominent developer. We undervalue redundancy.
That will pass all tests and work fine for all purposes right until hilarity ensues in whatever real world circumstances deplete the entropy pool. Note that after attackers realize that depleting the entropy pool is a victory condition, they can actively work to cause that.
What's the problem?
If both generators have the same underlying source then they're also likely to share any security vulnerability so XORing them is unlikely to improve the randomness and can introduce potential weaknesses.
This 'decrement pool entropy estimate and stop returning numbers' idea is the longest running mistake in crypto.
> and can introduce potential weaknesses.
This isn't true. XORing numbers can never decrease entropy. It can only increase it. So your security would stay at the strongest generator, plus some extra entropy from the weaker ones.
Let Generator A(x) equal "For any x, a perfect random number picked by the hand of God Almighty." Let Generator B equal "For any x, A(x+1) unless 'ars is asking in which case A(x)".
If ars chooses Generator A, ars is fine.
If ars chooses Generator B, ars is fine.
If ars chooses Generator C = A(x) ^ B(x), ars will very quickly see that ars' intuitions about math are in some circumstances incorrect. Ars might then think "Phew, good thing they weren't subtly correlated, or it would have looked great right until it didn't."
(Alternatively it could mean that you can only generator a single cryptographic random number, since all the rest are just functions of the previous one, and then again you are not fine. Either way Generator B is not fine.)
And in any case neither A nor B is a generator - only x is. Neither A nor B are adding any entropy whatsoever.
A CSPRNG is a function that takes as input a small set of random bits and generates as output a large set of unpredictable bits. So "Generator B" can be a "cryptographic RNG" and be a function of, or at least correlated with, "Generator A".
In cases where they might be non-independent, a simple hash function like even the otherwise broken MD5 would be better at combining them than XOR. But of course, we're now three steps down the path of constructing our own replacement for what the kernel and/or OpenSSL should be doing for us already.
dd if=/dev/urandom bs=32 count=1 | xxd
If you get the same output twice, see a doctor.
You don't gain anything, and if your random numbers are correlated with something you're making it worse.
I guess it makes testing easier. Correlations will be easier to see.
The point is
`dd if=/dev/urandom bs=32 count=1` XOR `dd if=/dev/urandom bs=32 count=1`
In the real world, our computers are limited by physics. It seems that in crypto, the least controversial assumption we can make is that given enough secret bits (i.e., entropy) we can be safe from brute force attacks.