How secure is my custom encryption algorithm? [clo

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:

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

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.