-12

I have put much thought into this very simple algorithm and I have no clue if it was thought before... But I think it should have.
I also know nothing about other encryption algorithms so I can't tell whether this was already invented or not.

It is all sketched on this paper:
enter image description here

And this is a little C# function for this algorithm.

public static void Encrypt(Stream source, Stream target, byte[] key)
{
    int current;
    long pos = 0;

    int res;

    if (source.CanSeek) source.Seek(0, SeekOrigin.Begin);
    if (target.CanSeek) target.Seek(0, SeekOrigin.Begin);

    while ((current = source.ReadByte()) != -1)
    {
        byte b = (byte)current;

        res = b + key[pos++ % key.Length];
        if (res > byte.MaxValue) res -= byte.MaxValue;

        target.WriteByte((byte)res);
    }
}

All I know about encryption is that it (i-)reversibly changes data to protect it.
From all I know, there is no way to crack the key without knowing the original data.
And to check whether the key is right (in an attempt to decrypt), the data's integrity must be checked. Thus a hash must be known...

So will this almost retarded algorithm keep my data secure?
If not, why?

Edit: Please attempt to crack this!
The encrypted bytes are 169 131 181 215 152 43 55 126 235 88 46 150 17 45 185 122 180 203 34 67 109 54 127 234 87 45 57 222 125 152 142 133...
The MD5 hash is 116 249 25 168 168 255 211 143 122 60 216 192 37 167 178 112!
Go ahead!

AviD
  • 72,138
  • 22
  • 136
  • 218
Vercas
  • 111
  • 5
  • This was a bit discussed at the same-named question on [Stack overflow](http://stackoverflow.com/questions/6509317/would-this-kind-of-encryption-be-good-at-anything). (I requested migrating it here, now we will have a duplicate, it seems.) – Paŭlo Ebermann Jun 28 '11 at 16:50
  • 13
    `"I also know nothing about other encryption algorithms"` then you shouldnt even be discussing a new one, until you learn the existing algorithms - what they tried, what works, what doesnt, what is important in a cipher - etc. Just like you wouldnt perform heart surgery because you "have put much thought into this very simple... " procedure. – AviD Jun 29 '11 at 08:30
  • It's still a good question and shows some deep thought/research, if not an incredible broad amount/level. –  Jun 29 '11 at 15:51
  • 4
    ARGH PAPER!! D: – NULLZ May 28 '13 at 05:42

3 Answers3

19

Just don't: http://xkcd.com/153/

Bruce Schneier likes to say, "Anyone can invent an encryption algorithm they themselves can't break; it's much harder to invent one that no one else can break"

The current algorithms RSA, AES etc has been through rigorous scrutiny over years by tens of thousands. Why not just use of these?

Also: Lessons learned and misconceptions regarding encryption and cryptology

Community
  • 1
Rakkhi
  • 5,783
  • 1
  • 23
  • 47
14

Isn't this a Vigenère cipher ? Lookup the article, I'm pretty sure it talks about cryptanalysis of this code (find the ley length, frequency analysis etc)

And if the key is of the same length that the plaintext, you have a One-time pad that is virtually unbreakable without the key (provided this key has good random properties and is never reused).

M'vy
  • 13,033
  • 3
  • 47
  • 69
  • 7
    Yes, it is the Vigenère cipher (on a alphabet of size 256 instead of 26). – Paŭlo Ebermann Jun 28 '11 at 16:52
  • Securing a one-time pad is incredibly difficult, not to mention the difficulty of keeping the (incredibly long) key safe. – AviD Jun 29 '11 at 08:27
  • 1
    It's not hard at all to make a one-time pad.. I could just write one out in-front of me right now.. the difficulty comes in keeping that away from other people while simultaneously getting it to the people I want to be able to read my messages! –  Jun 29 '11 at 15:50
0

The first you need to consider when requesting someone to test your algorithm code or anything of that sort is MAKE IT UNDERSTANDABLE. If you can understand what you mean it doesn't mean everyone can. Anyway there are two problems in your cipher: It is insecure under Semantic Security (with a key shorter than the message) and it is insecure under CPA (Chosen Plaintext Attack) and any such cipher is not even considered. Let me explain in a little more detail. As you can see from the general construction of your cipher it is something slightly resembling the OTP (One-time pad) though much less secure. However even if your encryption system would have been as secure as the OTP the moment you use the same key to encrypted multiple messages your encryption is quickly broken and more than that the key is deduced. And even if your encryption algorithm would have been resistant to deducing the key from the ciphertext-plaintext pair the encryption algorithm is definitely not a randomized function nor a nonce-based encryption algorithm and therefore is not resistant to CPA. To make a last point your encryption algorithm is even worse than the OTP encryption algorithm because what you are doing is simply creating a Stream Cipher with a completely predictable PRG (Pseudo Random Generator) which does nothing random looking instead it just repeats the key when ever the space is finished. The only secure case with your cipher is when the key is as long as the message and then there is no point to encrypt it because if you have a way to communicate the key to the recipient securely why waste time and not use the method for communicating the whole message? Anyway the key point is you made a try at making a stream cipher but you used a completely insecure Pseudo Random Generator and let this be a lesson to you not to try and reinvent the wheel.

Samuel Allan
  • 123
  • 5