First of all, let me be very clear that I would never use my own pRNG for cryptography purposes. I am not skilled enough to properly audit existing generators, which means trying to audit my own where there would be bias would be, well, even dumber than voting to re-elect Trump. Well, okay, maybe not that dumb, but still pretty dumb.
First I need to explain what an XOR is. XOR is a binary logic function that outputs a byte True (1) or False (0) based upon two bits fed to it. If both bits are false, it return false. If both bits are true, it returns false. But if one bit is true and the other bit is false, it return true.
So this is how my pRNG would work. It would start with an initial salt (which could initially be empty for all I care) and a 16 byte nonce. Why 16 byte? Who cares.
To generate random data it would listen to encrypted traffic on the Internet. The generator would take a 256 bit hash of the salt plus the nonce, and use the hash to XOR with the encrypted traffic to result 256 bits of “random” data. The nonce is incremented and it repeats for another 256 bits of random data. Every so often (say every 16 MB worth of “random” data) the salt is replaced by 256 bits of data generated in this way.
Now if you know the salt *and* you know the nonce *and* you know the 256 bits of encrypted data that was listened to, you could predict the 256 bits of “random” data that was produced, and that is probably enough to make it not very useful for cryptography since the encrypted data being listened to could be influenced, leaving only the nonce and salt as unknown, but since the nonce is incremented rather than random generated each pass, if the salt were to be discovered then it possible that influencing the encrypted network traffic could be used with a rainbow table to figure out the nonce. Though with a 16 byte nonce that would still be pretty difficult.
I don’t think this idea would be secure enough to rely upon itself for random data, but the random data could be used to XOR another output – such as what it produced by HAVEGE algorithm – as a second line of defense against a flaw in that algorithm.
Even if an attacker did know the salt and the nonce and could completely 100% influence the network traffic being listened to allowing them to completely predict the “random” stream produced, if the random stream produced was only used to XOR the HAVEGE algorithm then I do not see how they would gain anything unless HAVEGE was flawed. But if HAVEGE was flawed and they don’t have the ability to predict what this “random” stream produces, it would obfuscate the random data produced by HAVEGE enough that the flaw in HAVEGE may not be exploitable.
Obviously whatever the source that is XORed against this stream, if a flaw was discovered, would need to be changed to something else. But I’m just thinking it may be one possible line of defense against a 0 day making it harder for an attacker to take advantage of a 0 day.
If the random number produced by Debian’s flawed OpenSSL was XORed against this stream before being output, I do not think private keys would have ever repeated.
I’m fascinated by cryptography, but I am not a cryptographer, so it’s quite possible there’s a flaw in my thinking. And of course this also falls apart if you can prevent listening to encrypted network traffic.