Using hash for one time pad key Recently I've been delving into security algorithms, I already knew some of the (easy) math behind AES and RSA and how to and not to implement it. But well, i got a bit bored so i thought I'd just do something fun and i wrote a small bit of code for the OTP (not so difficult)

then i thought, and this concerns my question: If you give someone a OTP key and you tell him that the (say SHA 256) hash of the previous plaintext will be the new key, how secure is this? Obviously you start with a perfectly random key an will never make your plain text longer than your key. (so a proper one time pad function)

So you have a key, you decrypt the cyphertext you get, then you hash the retrieved plaintext and this has will be the key for your next message. In my mind this would be as secure as the OTP when starting with a proper key. But then again my mind isn't really suited for simulating real applications, haha.

So does anyone have an idea on how secure this would be?

EDIT i might want to clarify your next plain text will of course be as long as the generated  hash, if you need to write a longer message you will use the hash of your newly typed plain text, and so on.
Not as secure as a one time pad. A key concept with one time pads is that no part of them is ever reused. It is a common pitfall of people attempting to implement cryptography to assume that an obscure relationship is necessarily a secure one: it is not. You are create a chain of SHA hashes that can be observed, and potentially decoded. 

Therefore what you have described is not an effective one time pad. The one time pad depends on the idea of a pre-compiled book of codes that have no relationship to one another, and that are used exactly once. If any sort of iteration is observed between the ciphertexts, this ruins the pad. 

From the outside this seems like a hard code to cryptoanalyze, but I don't think it is massively difficult. Differences between your ciphertext will be analyzed, and when is found that you are not using a standard encryption scheme, the various pitfalls of self implemented crypto will be explored. 

The security of your entire system can be no better than the original secret in that case, and the additional secrets generated from original secret actually worsen the security of the system, because they give some clue as to the original secret, however obscure that clue might be. To be as secure as a one time pide, the keys should bear absolutely no observable relationship to one another. 

If I were to cryptoanalyze your system, I would first figure out the nature of the cipher text, and the nature of the keys. If I had access to a single key (say by brute forcing, or a flaw in the encryption) then I would be able to detect fairly quickly via automated methods that the key was a SHA hash. 

At that point, I would try to guess the plaintext of the hash. If I had access to multiple keys I would notice that key size might correlate to message size in some way. From there it would be obvious that key was related to the message somehow. I will admit that brute forcing an entire message against a SHA hash is unreasonable, but all it takes is one leaked message to start pulling things apart. 

If I ever decoded the plaintext from any one of the hashes it would be game over. System cracked. This was a quick analysis, others might be able to go deeper into the math side of this.