Can I generate OTP secrets by using a hash?

Question

Since I learned about one time pads in last security lecture, I'm quite fascinated how easy the concept is, but how it still is absolutely safe.

Learning from implementing a multi time pad attack, an OTP is not safe if the key is reused. I understand why this is the case. Also encoding large messages requires a large secret, so I tried to think about, how to solve this.

This is what I came up with:

Consider we have a Hash Function $H:= A^k \rightarrow A^l$ were $A$ is an alphabet, and $k$ and $l$ are arbitrary lengths. For example we can use md5 for my purpose. Next we have an secret $s_0$ with a length that is not sufficient to encode our message $m$. What if when I run out of characters/bytes of my secret to encrypt my message, I'll take the next characters/bytes from $s_1 = H(s_0)$. I could then repeat that process until I have a sufficient length of the secret $s_0 + s_1 + ...$.

Also a possible variant would be to generate $s_{i+1}$ by taking the concatenation of the hashed characters of $s_i$.

Example: $m = thistextistoolongforthesecret$ , $s_0=short$. I can encrypt t with s, h with h, and so on until I have no more characters left for the e. I would calculate $s_1=4f09daa9d95bcb166a302407a0e0babe$ (md5). Then I could use the 4 of $s1$ for encryption of the e.

What are the security implications of this? I have the feeling that this has some serious downside, that eventually will lead to a possible multi time pad attack, but I can't show any reason for that. My knowledge is only superficial, since I only heard about OTP 2 days ago.

Answer 1

Say the adversary is giving you $m_0$ and $m_1$, two arbitrary messages. You draw a random $sk$ and a random $b\gets\{0,1\}$ and output $E_{sk}(m_b)$.

So the adversary takes $ct=E_{sk}(m_b)$ and computes the XOR between the first $n$ bits of $ct$ and the $n$ first bits of $m_0$ (where $n$ is the original key length). Then, he does the same thing for $m_1$, so now he has two options for the secret key, $sk_0$ or $sk_1$. So far everything is good, because they are both equally possible, but now the problems begin: the adversary computes $md5(sk_1)$ and $md5(sk_2)$ and XOR the results with the bits $ct[n+1:n+\texttt{md5-length}]$. With a very high probability, only one of the options will make sense, meaning it would be the bits $m_i[n+1:n+\texttt{md5-length}]$ of some message, so he will know what you encrypted.

Answer 2

Welcome to the one time pad. Unfortunately and respectfully, all your scheming is wrong /insecure.

The problem is your equations. Recursive Hash(Hash(Hash...))) is simply a pseudo random number generator. Java's SecureRandom() is very similar, albeit there's a counter involved.

One basic non mathematical definition of a PRNG is that it involves an algorithm and equations. The OTP cannot have any equations whatsoever involved in generating it's original entropy. This is absolutely fundamental. If you have an equation, you can theoretically invert it and predict the key from what ever starting point (seed) you used. You are conflating complexity with entropy.

The key material for a OTP must be generated via a physical piece of hardware you can hold in your hand. It must be a physical process from the natural world, not the mathematical one. It can be levers in a double pendulum, thermionic valves or semiconductor junction breakdown. Everyone's favourite is radio active decay (although the only known instance of this is HotBits). It might actually be the hand itself. OTPs during WW2 were generated by ladies randomly typing at typewriters. But there has to be a hand involved somewhere. Oh, there's dice and dimes too, but you also use your hand.

Another way to look at it, is that entropy is handed to you. It comes in a physical piece of equipment, and all you do is measure it. You cannot make it yourself (not absolutely strictly true - but that's a more complex discussion). It has to look something like this:-

or this:-

It cannot look like: f'(blah) -> f(blah)

We get this type of question from time to time. Actually, surprisingly often. Clicking the OTP tag will highlight other attempts at improving the venerable OPT. All fail. Also look towards entropy discussions.