# Does hashing a compromised rng and a secure rng give cryptographically secure random output?

If I have a compromised random source and a cryptographically secure one, is hashing them together makes a cryptographically secure random output?

Example:

The compromised random output: ABC

The cryptographically secure random output: DEF

Hashing them together:

printf 'ABCDEF' | sha512sum


Is this hash a cryptographically secure random output?

If I am not clear enough, please ask and I will update the question.

• Maybe, you could XOR your compromised RN and TRN together and you would be OK as long as the TRN is kept secret before XORing. What you are asking is if a CSPRNG could be made with a half random seed by hashing, I'm not sure hashing a TRN gives a CSPRN all the time, you enter the worlds of maybe. I don't know what gives the CS in CSRNG, but your example needs some extra bits, 440 bits i think is reccomended for SHA-256, and then, I dont think non random bits would count towards the 440. csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf Commented Jun 22, 2017 at 11:01
• No. It is NOT a cryptographically secure random output as the input isn't 100% random and therefore not even close to a cryptographically secure input. I lack the time to write up a full answer, but to get an idea what I'm talking about, check one of the many examples out there – like, for example, the "Bitcoin Brainwallets" fiasko. Summa summarum: a cryptographically secure hash is not some magic sauce you simply put on top of something flawed to make it secure. That's not how it works! (Besides, that compromised random source you mention represents a pretty good attack vector.) Commented Jun 22, 2017 at 12:51
• Related: Why does a Hashing Function produce good Random Numbers if Input is random? – which also asks about combining two inputs. Besides that, there's also Understanding hash entropy and Estimating random number entropy for input into 256 bit hash which might be interesting for you to read. Commented Jun 22, 2017 at 13:10
• Here's one way to handle this situation: Throw away the compromised output and just go on with the output of the proper CSPRNG. Robust combiners is a keyord that might be interesting for you - simply hashing the inputs is definately not enough.
– tylo
Commented Jun 22, 2017 at 13:41

Absolutely secure.

SHA-512("ABC..." | "DEF...")

but I have to caveat with the reasonable expectation that the cryptographic source is more that just three letters. You would expect at least 128 bits of entropy, or 28 A-Z characters.

The important aspect here is that you concatenate rather than xor. An xor operation would /could allow the compromised source to nullify the entropy from the cryptographic source. By using a secure cryptographic source, you're continuously adding entropy to the hash function irrespective of the compromise. A SHA function is one way, therefore an attacker cannot feed in anything that will generate predictable hash output.

Rather topically, the Fortuna RNG uses this very similar technique to aid recovery from a compromise with it's entropy aggregation function:-

Pi ← Pi | s | length(e) | e

where new input entropy (e) is concatenated to a previously contaminated entropy pool.

• "rather than xor", isn't random data xor anydata = random data? Unless you have information about the random data while creating anydata. (If you do know the random data you can change anydata to be the inverse for example) Commented Jun 23, 2017 at 9:36
• @daniel Absolutely. That's what I took compromised to mean - knowing the secure stream he can inject the inverse to nullify. Commented Jun 23, 2017 at 11:30
• I was thinking more like Dual_EC_DRBG Commented Jun 23, 2017 at 11:51

If you have a cryptographically secure hash function and you use as much input from each of the sources as there is output i.e.

for $H: \{0,1\}^* \rightarrow \{0,1\}^n$ you use $n$-bits of input from each RNG it will work.

However, in your specific example if you only use 3 letters to generate 512 bits of output, when the DEF repeats the entire 512 bits of output will repeat and this will happen with pretty high probability and after detecting it the rest of the 512 bit are known to an attacker.