Self Generating key encryption based

Question

I was wondering someting :

Doing a XOR with a fixed length key on txt files is not secure.

Basically : My key is "abc"

         abc|abc|abc|abc|abc|abc
         Thi s i s s ome dat a

THIS, is not safe.

BUT ! I was asking myself : why can't I just make a self generating infinite length key ? The user gives me a password, and I just hasing it to create a key, and whenever the length of the file is bigger then the key, i just re-hash the key itself to create a new one !

Example : Let's take a 192 Bytes message. Use SHA256 hashing algo create 48 Bytes keys.

This solution resolve the ciphere vineger problem.

SO MY QUESTION ( here it is :p ) : Is this one safe ?

Thanks ! ~Amperclock

Answer 1

Is this one safe

That's always a relative term. One can say for certain that breaking this encryption will be no harder than bruteforcing the first block of 48 bytes, which is more than doable with a few thousand dollars worth of servers.

Worst case, your first block is made up of a bunch of zeroes, and XOR-ing the key into that will make the first bytes of the ciphertext the key in plaintext, because x ⊕ 0 = x. Hashing those bytes to find the key for the rest of the message is trivial. Likewise, if the format is predictable (most filetypes start with a pre-determined header), recovering the key will be trivial. If any part of the plaintext is known, al subsequent bytes can be recovered this way.

Also, it might be identifiable; Here's a nice paper on stacking hash functions It basically states that your scheme is also distinguishable. That is, given an output of the length of SHA265, it is computationally cheap to figure out if it's the hash of the previous hash.

But why roll your own? There are multiple cryptographically secure psuedorandom number generators that have stood years of attack and are probably much faster in performance.