1
$\begingroup$

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. enter image description here

This solution resolve the ciphere vineger problem.

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

Thanks ! ~Amperclock

Improve this question
$\endgroup$
2
  • $\begingroup$ Using user input as key is bad (easy to guess), hashing it once doesn't help much (you need a KDF for that). The rest is actually just a stream cipher based on a hash function. And that has been asked here quite often: here, here, here, ... $\endgroup$
    – tylo
    Jan 18, 2017 at 12:33
  • $\begingroup$ ... and this answer has even more links, which address the same idea (sometimes calling them different things). $\endgroup$
    – tylo
    Jan 18, 2017 at 12:34

1 Answer 1

Reset to default
1
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Thx for the message. I'm currently trying my own algorithm, so that's why :). And yhea, it still sensitive to the brutefoce, like a lot of things ;) $\endgroup$
    – Amperclock
    Jan 18, 2017 at 10:33
  • $\begingroup$ I have edited my answer to include a known plaintext vulnerability $\endgroup$
    – J.A.K.
    Jan 18, 2017 at 10:47
  • $\begingroup$ I'm ok, you can recognize the header of a text file. What is you do the same trick, but as a bit level ? I understand for the full-of-zero hashing result $\endgroup$
    – Amperclock
    Jan 18, 2017 at 11:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.