(I am a cypto amatuer ) So in Openssl there is the "-rand" option for taking a file containing randomness for the RNG . So I thought taking a pretty big file would make it more secure . So if you use a lets say 2048 bit random binary file form "https://www.random.org" made from cosmic noise you would be pretty safe right ? But the problem is that the if I used the file multiple times it is alway the same "random" input so i would have to make the file secret . So It would be better to change like one 0 or 1 in the 2048 bit every time using it right ? But here comes the Question : How much does changing a single character in 2048 bit affect the randomeness of the Output in the end ? Is it like hashing where the output is completely different after changing only one bit or will the output be pretty much the same ?
-
1$\begingroup$ It will look like hashing but of course if an attacker somehow gets hold of the source data, the minimal modifications can be re-done and all your keys are basically broken. Also note that random.org may not be the best source of cryptographic entropy, as you have to be sure that a) their server's haven't been breached b) your connection to them cannot be breached c) they are actually a friendly service and don't keep logs of given-out randomness. $\endgroup$– SEJPMCommented May 13, 2017 at 16:49
-
$\begingroup$ You realise that there is no evidence that hotbits is anything more than a pseudo random number generator? It is almost certainly not using cosmic noise (what is that anyway?) It's very difficult to use a consumer radio for quality entropy generation - the very design of them works against you. $\endgroup$– Paul UszakCommented May 13, 2017 at 19:55
2 Answers
OpenSSL will take the file and feed it into its internal PRNG(pseudo-random number generator). That PRNG has an internal state consisting of a 1023 byte buffer and a working hash value (20 byte sha1 hash)
The algorithm used to seed the PRNG goes around the buffer, modifying the buffer in 20 byte blocks while also updating the working hash value.
Q:Should I make the file bigger?
Anything much larger than the state size of the PRNG (1043 bytes) is wasteful. Feeding in more than that many bytes of random data will not improve security (by making the final PRNG state harder to guess).
Q:Where should I put a counter value If I plan to reuse data?
Putting it at the beginning of the file might be slightly better.
Supposing you put a small integer at the end of your file. That integer would be fed into the PRNG last. That means most of the large buffer would be unaffected by its value. Only the working hash is guaranteed to be affected.
This isn't a real problem. All output is dependent on the working hash and 160 bits is more than enough entropy to foil real world attackers (even ones with quantum computers).
Should I be doing this?
No. This is a brittle approach. If an attacker gets the seed file (which you plan on re-using) they can generate all the secret keys you produced. That makes it a massive liability. If the service providing you with random data is not trustworthy they could already be doing this.
If you plan on using such a file, you must also include additional randomness from another source. You could get it from the operating system (EG: reading /dev/urandom on linux) or just bang on the keyboard for 30 seconds. More entropy sources can't hurt and will prevent this sort of failure.
Also, consider, if you trust your OS not to steal the keys why don't you trust it to supply randomness? Most operating systems do a good job of capturing and supplying randomness (as long as you wait till a few minutes after booting).
That's a pretty poor idea. Every time that you reuse the initial seed file with a single flipped bit, you're only adding one bit of entropy. Probably a lot less than one bit as humans are very bad at trying purposefully to be random.
Having started out with (ostensibly - but see my comment regarding the veracity of hotbits) 2048 bits of true entropy, you then descend into creating a de facto pseudo random number generator of your own. The safest way to use your SSL is to ensure sufficient system entropy via other means.
