1
$\begingroup$

I was just thinking about this and couldn't seem to find anything on it online.

So the idea I had was this:

Generating a random key of some length. Then hashing this key with SHA256 (or something of similar security), then looping through each byte of the hash and each byte of the text and doing an XOR operation with both of these bytes, generating a new byte. Then stringing these new bytes together to create a cipher text. This can be easily reversed if you know the key.

My questions:

How secure would this potentially be? Other considerations? Advice on improvements to the system?

Thanks!

Improve this question
$\endgroup$
1
  • 2
    $\begingroup$ You are on the way to finding the standard CTR mode 1979. CTR mode is originally designed for PRF. Let $H$ be a secure hash function, then $$H(k||counter_0) || F(k||counter_1) || \ldots || F(k||counter_m)$$ creates a secure stream so that one can x-or the message to encrypt. These provide lots of advantages and some disadvantages, too $\endgroup$
    – kelalaka
    Commented Apr 12, 2022 at 9:58

2 Answers 2

Reset to default
0
$\begingroup$

Yes, this essentially works (up to fixing small issues). One notable issue is that your hash will be the same each time, so you can recover it using a known plaintext attack, then forge messages freely.

Another small issue is that you can only encrypt messages as long as the output length of your hash.

Both of these can be fixed by sampling a random IV, and then hashing IV||key rather than the key. If you want to encrypt multiple blocks, either hash using an extendible output function, or hash IV||key, (IV+1)||key, etc.

This construction is just (randomized) counter mode, where we are using a hash function as a PRG. As our hash needs pseudorandomness properties, this is only secure in the random oracle model, and our hash must be good as a random oracle.

Improve this answer
$\endgroup$
2
  • $\begingroup$ What do you mean by sample a random IV? If it's random doesn't that mean another person can't decrypt it? $\endgroup$
    – theflamingtiger
    Commented Apr 12, 2022 at 8:39
  • 1
    $\begingroup$ IVs are usually not required to be secret, so one would simply transmit it along with the ciphertext. $\endgroup$
    – Morrolan
    Commented Apr 12, 2022 at 11:20
0
$\begingroup$

This is completely equivalent to Vigenere with size of key $256$ (and the Vigenere Key will the hash of your key). Then it's not secure at all.

For example let suppose I know the first 256 bits of your message. Then I can deduce the full $h(k)$.

And even I don't know $k$, I can retrieve the full message.

Of course, if you message is exactly $256$ bits, you have perfect security (it's a one-time pad).

Improve this answer
$\endgroup$
6
  • $\begingroup$ This would also apply if the message is less than 256 bits right? $\endgroup$
    – theflamingtiger
    Commented Apr 12, 2022 at 8:33
  • $\begingroup$ Yes, but then the question is about of the size of the key. If it's more than 256, it's less efficient than a one-time-pad, then you have to be sure that your key has enough entropy. Else, it can be brute-forced. $\endgroup$
    – Ievgeni
    Commented Apr 12, 2022 at 8:36
  • $\begingroup$ This is a completely theoretical situation: what would happen if you put the plaintext in something like a QR code, and then you perform the original process on those bytes instead. Would this be considered more secure since now each byte doesn't necessarily represent one in the original plaintext? $\endgroup$
    – theflamingtiger
    Commented Apr 12, 2022 at 8:47
  • $\begingroup$ I'm not too familiar with QR code. But if an adversary has some leak about the distribution of your QR code, they can deduce a lot of thinks. For example by xoring two parts of 256 bits $c_1$, $c_2$, it completely deletes the key, and then you deduce $m_1 \oplus m_2$. I don't know if it is sensitive data in your case , but in general such schemes are considered insecure. $\endgroup$
    – Ievgeni
    Commented Apr 12, 2022 at 8:54
  • $\begingroup$ That does make a lot of sense. Ok last thing, what if there was a way to scramble this QR code in a way determined by the key/hash so that without they key/hash someone trying to decrypt it wouldn't know which bytes correspond to what? $\endgroup$
    – theflamingtiger
    Commented Apr 12, 2022 at 8:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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