Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
If I have 256 bits of handwavium "perfectly random data" and I hash these 256 bits of data with a secure hash function (possibly SHA-256).
Could the resulting hash be considered "perfectly random data" as well? I am assuming the answer is "no", but don't know why.
What information / keywords would I use to find out more information about this?
Interesting seemingly related topics:
Suppose you take your 256 bits of handwavium "perfectly random data" and use it to seed a handwavium "perfect cryptographic seed expansion algorithm", such as the SHAKE XOF -- but it really makes no difference which algorithm you choose. You then generate 257 (or in general any $n > 256$) bits of "random data". In principle, if this was really random data, you'd have $2^n$, for $n > 256$, different bit strings.
However, suppose you cycled through all $2^{256}$ bit strings of "only" 256 bits. Evidently one of these would match the 256 bits of handwavium "perfectly random data" mentioned at the beginning, and having found it, then you'd be able to generate exactly the same $n$ supposedly random bits.
Thus, by brute-forcing "only" 256 bits (a computational effort of $2^{256}$ operations), you can find all $n$ bits, while if they were actually random, you'd need an actual computational effort of $2^n$ (for, again, $n > 256$), which is general is much greater than $2^{256}$.
So don't fool yourself: you only have 256 bits of randomness. Any bit coming after that is a 100% deterministic function of those 256 bits, and thus adds no randomness at all.
Why cant you use randomness to seed more randomness?
Obviously you can, that's what any (Cryptographically Secure) Pseudo Random Number Generator or (CS)PRNG does after all.
Could the resulting hash be considered "perfectly random data" as well? I am assuming the answer is "no", but don't know why.
"Perfect random data" does not really have a formal definition. However, let's assume that we want to use this data as a key stream in an OTP, a use case that is more or less implied by using "perfect" in the term. In that case an attacker should not be able to find out any information about the values of the plaintext (bits) nor by extension of the key stream.
It is easy to see that the random data created by the hash function doesn't have this property: only specific messages (say of the same size as the hash output) are possible as the set of ciphertexts are limited by the amount of hash values available - 256 in this case. So no, in that sense the hash output certainly is not perfectly random.
The above assumes that every bit within the hash result should be considered random, and this assumption would generally be true for most use cases. However, the hashes are still perfectly random within the group created by the 256 unique hash values. There is a known 1:1 mapping between "seed" and hash output in this case.
This won't hold for any seed size due to overlapping hash output values (the pigeonhole principle). It should not be possible to generate a hash collision so this is of no practical concern. However, for perfect security we're not limited to practical concerns.
So the answer relies on the output domain; the answer is no-but-maybe-yes. This shows that it is impossible to have a rigorous answer without a well defined question.
I was looking into one-time-pads and am trying to figure out what would prevent you from generating an inf one-time-pad from a random seed.
One time pads.
Let me respond to a quote with another quote:-
It seems natural to call a chain random if it cannot be written down in a more condensed form, i.e., if the shortest program for generating it is as long as the chain itself.
-Andrey N. Kolmogorov.
Seeds have no place in OTPs. None. You suggest iterating $s' \leftarrow H(s)$. I just wrote that down yet that's in total opposition to the quote above. So no. Read about Kolmogorov complexity and how to encode the nice piccy on that web page. And these two .SE tags 1 & 2.
