-8

I created my own very simple encryption algorithm in C#, and I was wondering just how secure it really is. I call the algorithm "SBC" which stands for "Simple Byte Cipher". Essentially, it works like a Caesar Cipher, except I increment integers(the value of the associated bytes) instead of letters.

There was a few reasons why I decided to do this. First, I wanted an algorithm that offered an exact 1:1 size ratio. In other words, I wanted the output encryption length to equal the input text's length without any growth. I also wanted to be able to use any letter, number, character, etc that I wanted, without the cipher making everything capital letters, which a native Caesar Cipher cannot do. I wanted the output to also be mostly a mess of unprintable characters, kind of like a binary file. I also wanted it to be fast. Very fast. My current algorithm was able to fully encrypt Huckleberry Finn in less time than I care to even express(yes, it was fractions of a second).

But the real question is on the table now...how secure is my algorithm? Is there a way to possibly test it? Are there any glaring flaws with it? Allow me first to explain how it works, and then I will show you the code.

The algorithm is actually very simple, almost too simple. We start by taking any arbitrary string that we desire, let's say that for this situation we choose "Stackoverflow". We then choose a password, which will be "Cats Rule The Internet", and finally, a single seed/salt value. Let's do 31 because it is my favorite number.

My algorithm starts by looping through the string, taking each letter and using its byte value + the current letter index of the password's byte value + seed integer value.

As a mockup it would look something like:

Input Byte | Password Byte | Seed Value|
    45     +       18      +     31    =  94(this number rolls around for byte if it exceeds 255)

And then, we have our new byte value, which can litterally be anything from a number, a letter(both capital or not), a symbol, or even unprintable characters. When printed to a file the message "This is but a test." looks like:

enter image description here

Here is the code as it currently stands:

    /**
     * Simple Byte Cipher "SBC"
     * Created by Gordon Kyle Wallace, "Krythic".
     */
    public static class SimpleByteCipher
    {

        public static byte[] EncryptStringToByteArray( string data , string password , uint seed)
        {
            byte[] bytes = Encoding.ASCII.GetBytes( data );
            byte[] passwordBytes = Encoding.ASCII.GetBytes( password );
            int passwordShiftIndex = 0;
            for( int i = 0; i < bytes.Length; i++ )
            {
                bytes[ i ] = ( byte )( bytes[ i ] + passwordBytes[ passwordShiftIndex ] + seed );
                passwordShiftIndex = ( passwordShiftIndex + 1 ) % passwordBytes.Length;
            }
            return bytes;
        }

        public static string DecryptByteArrayToString( byte[] data , string password , uint seed)
        {
            byte[] bytes = data;
            byte[] passwordBytes = Encoding.ASCII.GetBytes( password );
            int passwordShiftIndex = 0;
            for( int i = 0; i < bytes.Length; i++ )
            {
                bytes[ i ] = ( byte )( bytes[ i ] - passwordBytes[ passwordShiftIndex ] - seed );
                passwordShiftIndex = ( passwordShiftIndex + 1 ) % passwordBytes.Length;
            }
            return Encoding.ASCII.GetString( bytes );
        }
    }

I personally feel as though it is pretty secure. Not only do you need the algorithm, but you will need the exact password, and the seed/salt that was used to be able to decrypt the encrypted message. I just need to know what you guys think, am I missing anything here?

Want to test your kung fu? Try to crack this: Crack me if you can

Krythic
  • 4,184
  • 5
  • 26
  • 67
  • 17
    You're missing about 300 years of cryptographic research. – Maarten Bodewes Jul 29 '15 at 20:39
  • 2
    Why would you implement a custom encryption scheme when there are many well tested algorithm implementations available to you? – HashPsi Jul 29 '15 at 20:39
  • @HashPsi Because I can? – Krythic Jul 29 '15 at 20:40
  • 10
    So the answer is: most likely not secure at all. It is very easy to crack given enough encrypted text. – HashPsi Jul 29 '15 at 20:42
  • 5
    ... given enough ciphertext this is very easy to crack. Basically it's still a [simple substitution cipher](https://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher)... – Maarten Bodewes Jul 29 '15 at 20:46
  • 1
    The real question is: What do you want to do with it? Encryping a few dozen passwords (read: less than 1k in total) or large or even basically unlimited, growing quantities of text? Making a safe enough encrytion for the former is trivial, for the latter next to impossible, at least without an professional approach.. - I wonder: Is there a cracking service that one could use to test home-made encryption? Anybody? – TaW Jul 29 '15 at 20:53
  • Your "Crack me if you can" example can't be cracked, but not because of the reasons you want. You saved arbitrary binary data as text, when you try to go back to a `byte[]` via `GetBytes` you are not going to get the same `byte[]` you sent to `GetString`. Resubmit your text as a base64 encoded string. – Scott Chamberlain Jul 29 '15 at 20:54
  • @ScottChamberlain Top right hand corner of Mediafire, hit download. It will give you the proper text file version. – Krythic Jul 29 '15 at 20:56
  • Once again, your file is invalid. You can't do `GetString` on "random" data. You lost information in the process. – Scott Chamberlain Jul 29 '15 at 20:57
  • The .NET Framework has everything you need. See [Cryptographic Services](https://msdn.microsoft.com/en-us/library/92f9ye3s(v=vs.110).aspx) – Olivier Jacot-Descombes Jul 29 '15 at 20:58
  • @ScottChamberlain File.ReadAllBytes(), dude. – Krythic Jul 29 '15 at 20:58
  • 3
    @Krythic [`ASCIIEncoding.GetString()`](https://msdn.microsoft.com/en-us/library/38b953c8(v=vs.110).aspx): _"Any byte greater than hexadecimal 0x7F is decoded as the Unicode question mark ("?")"_. You will not get the same string back from an encryption-decryption roundtrip if any input character's code point is > 127. – CodeCaster Jul 29 '15 at 20:59
  • @CodeCaster Just downloaded and decrypted it myself. Your comments are invalid. – Krythic Jul 29 '15 at 21:04
  • 1
    I said "if any input character's code point is > 127". – CodeCaster Jul 29 '15 at 21:11
  • 2
    @ScottChamberlain "Resubmit your text as a base64 encoded string". Oh no, double encryption! Then it really will be impossible to break. ;) – MvdD Jul 29 '15 at 21:18
  • See: [one](http://stackoverflow.com/q/29553102), [two](http://stackoverflow.com/q/14076753), [three](http://stackoverflow.com/q/10672656) and a couple more. – Artjom B. Jul 29 '15 at 21:25
  • @Krythic "Crack me if you can" is a very funny approach but why should I spend -say a few hours- of my private time, just to show you are wrong? You know now all the responses. Just use it in commercial/military etc. applications and see the result. – EZI Jul 29 '15 at 21:46
  • If you want to learn about cryptography and how to write code to break the insecure ciphers, check out http://cryptopals.com/ – CoderDennis Jul 29 '15 at 23:08
  • @MvdD It's not like i'm going to be keeping military launch codes on my desktop, dude. In fact, I would say the opposite is probably true about what algorithm to use. People will be expecting me to use the new stuff, or what .NET offers. Using a proprietary algorithm is, in a weird way, more powerful, because any would-be hacker wouldn't see it coming. Maybe i'm just being delusional though, but I think securing game data would be ideal in my self-created cipher. – Krythic Jul 30 '15 at 01:06
  • @Krythic Look man, you encrypt something because it's worth protecting. If it is worth protecting, don't use your own encryption algorithms. Say your game is going to be widely popular. You hire many more developers to maintain it. Every one of these guys knows how to break your encryption. You are not just protecting against the unknown hacker from the internet. Use standard protocols and libraries. Use operational security where even your devs don't have access to secrets used in production. – MvdD Jul 30 '15 at 02:10

1 Answers1

5

Shift ciphers (of which the Caesar cipher is a variant) are among the least-secure types of ciphers.

Let's assume that someone were to realize that you were using some form of shift cipher. Classic shift ciphers only have 26 possible keys (corresponding to the 26 letters in the latin alphabet). Your key set is larger, because your domain of potential result characters is the entire character set (ASCII, UTF-8, Unicode, or whatever). Even if you're using unicode, there are only around one million possible keys. An integer you use to shift could be larger than this - say one million and one - but then you get the same effect as if your key was simply one. If someone were to brute force your encrypted text, this would take no time at all to decrypt.

Furthermore, if the decrypter reasoned that the decrypted text formed coherent, readable words, this would drastically reduce the size of the result character set; the decryption algorithm wouldn't have to consider all possible unicode (or whatever character set you use) values, just the ones comprehensible to humans.

You could argue that someone approaching this problem may not realize you're using a shift cipher and waste time trying to figure out what you're using, but hundreds of years of cryptography research has labeled shift ciphers as one of the most commonplace algorithms which exist. Any decrypter worth his/her/its salt would try that approach straightaway.

Brian Gradin
  • 2,165
  • 1
  • 21
  • 42
  • "the decryption algorithm wouldn't have to consider all possible unicode (or whatever character set you use) values, just the ones comprehensible to humans." I can see that being a weakness, yes, you would be correct. My key set would be 56 + all other symbols like exclamation, comma, etc. – Krythic Jul 29 '15 at 21:10