I do not recommend trying to roll your own crypto. This is just a for-fun PoC, which won't be used in any public or private scenario.
I am creating a PoC nearly-true random number generator, but this won't be used in real applications. I know the rule of "Don't roll your own crypto", but this is just a fun PoC for nearly-true random numbers. Also, time and convenience do not matter in this case. Also also, I did use the web cryptography API combined with a lot of other CSPRNGs for entropy. Read below...
How it works
Of course, if an attacker can break a (CS)PRNG, they can break SSL. (TLS)
The mitigation would be to generate billions of bits of entropy locally, while mixing that with several "randomness beacons"
The (CS/T)PRNG works like this: generate as much local entropy, (into arrays), then get a bunch of numbers from randomness beacons, then hash them together. This is where things get baaaaadddd.
First, if the values aren't uniform, the values can be somewhat predictable.
Second, the hash function can make the random number lose entropy. A primitive caveman mitigation would be to just add a lot more entropy, but I want to fix this correctly.
So my solution for now is to take the hash (which is several thousand bits long; shake256 is used), re-hash it with sha512, and remove all the letters, and pass that massive number through a library which manages large integers, and then pass it through a uniformity function. This is a modified version of another function I found on SO here:
- That is my best mitigation against entropy loss and skewing, but it probably is skewed and has many holes. How can I fix this while keeping uniformity and entropy?
- Is there anything else that could be a problem?