3

I'm trying to learn more about cryptography and have devised an algorithm below for symmetric encryption. I know that we shouldn't use self devised algorithms but this one seems incredibly simple and based on SHA-256.

1) Take an input and a numeric key, k.
2) Pad i with 0s until its length has 256 as a factor.
3) Generate pseudo random bits using SHA-256(k), incrementing k each time.
4) XOR the input with the pseudo random bits.

Why I think this is as unbreakable as SHA-256:

  • XOR encryption with truly random numbers that aren't re-used at all is perfectly secure
  • The SHA-256 algorithm hasn't been broken yet but there's no mathematical proof that it's unbreakable, therefore my algorithm is at least as strong as SHA-256

Are there any issues at all with this algorithm and encrypting things like this?

  • 2
    "I know that we shouldn't use self devised algorithms", but you describe a self devised algorithm... No, don't do that, unless you know enough of crypto to be answering questions, not asking them. I know enough to answer questions here, but I don't dare to devise a crypto algo, I let it to @ThomasPornin. – ThoriumBR Sep 3 '18 at 19:21
  • @ThoriumBR well this is just based on what I know so far (which is very little) and is why I'm asking about it on here- also edit: I'd never use a self devised algorithm like this – Lolums Sep 3 '18 at 19:22
  • Aside from all the issues ThoriumBR pointed out, how do you plan to remove the padding when decrypting? You have multiple plaintexts that generate the same ciphertext. – AndrolGenhald Sep 3 '18 at 21:10
  • Implement it, publish the source code, and let us cryptoanalyse. – Konrad Gajewski Sep 4 '18 at 20:27
  • @ThoriumBR: I got the impression that he was just asking in an academic spirit. He literally said "I know I shouldn't do this, but..." – loneboat Sep 7 '18 at 17:09
3

I see a couple problems here.

There's no IV

That means that if you encrypt two identical messages with the same key, the cyphertext is the same. If even part of the message is the same, it's possible to determine the content of the other messages, and even the key. Read about crib-dragging and you will see why.

As strong as SHA-256

Not really. It's as strong as the key. You are using a numeric key, but how long? It's 4 bytes long, 16 bytes long, 512 bytes long? That makes all the difference.

Numeric key and SHA-256

A numeric, auto-incrementing key is bad. SHA-256 bruteforcing rigs are plentiful, usually they are sold as Bitcoin Miners. They are cheap, they are efficient, and very, very powerful. Use one to generate Terahashes per second, apply your very, very fast XOR calculation, calculate the entropy of the message, and an attacker can bruteforce your secret message in minutes, maybe less.

XOR encryption with truly random numbers

They are not random, they are deterministic. Bruteforce the first block, and all your data is broken. If the first bytes of the message are deterministic (like a request header, or file type header, or Greetings dear user kind of message), and attacker can use the crib-dragging attack to infer part of the hash and feed it to the bruteforcer.

Vulnerable to Know Plaintext Attack

If any attacker knows the plaintext-cyphertext pair, he knows the XOR-key, because plaintext XOR cyphertext = KEY. That information goes to the bruteforcer and you know what happens.

Vulnerable to frequency analysis

256 bytes of data is enough to reconstruct part of the message using frequency analysis. Reconstructing the rest of the first 256 bytes is trivial, and results on a pair plaintext-cyphertext. This enables the know plaintext attack on the first 256 bytes, allowing the XOR-key to be discovered and bruteforced.

I know you are trying to learn, but trying to learn crypto by doing it is like making a gun by trial and error. You will shot yourself in the foot, or head. Wikipedia have a nice article on symmetric encryption, with a list of algorithms, the principles behind them, and the shortcomings.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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