Encrypting Windows Phone Resources at the Bit Level... am I doing this right?

Question

I have a question concerning encryption, more specifically encryption that requires no internet connection (opposed to private / public key or OAuth methods).

The problem arose when I discovered that the WP7 app store is not secure. I won't post a link, but a basic search will yield a desktop application that allows you to download any free WP7 in the marketplace. Then it's a matter of renaming .xap to .zip, and using reflector to look at the code.

I believe that Dotfuscator will solve my problem, but as a learning experience I decided to come up with my own solution.

I decided to have a program that in prebuild gathers the files I want to encrypt, puts them in one file, encrypts that file, and adds it to the project for compilation. Code in the phone app only needs to decrypt the data.

The data I'm encrypting / decrypting is several API Keys (for ~10 web services), meant to be readable as plain text when decrypted.

This is the encryption algorithm (roughly, and with a few alterations) that I came up with:

public static byte[] SuffleData(byte[] data)
{
    // Create a bit array to deal with the data on the bit level
    BitArray bits = new BitArray(data);

    // Generate a random GUID, and store it in a bit array as well
    Guid guid = Guid.NewGuid();
    BitArray guidBits = new BitArray(guid.ToByteArray());

    int guidBitsIndex = 0;

    // Iterate over all the data bit by bit
    for (int i = 0; i < bits.Count / 2; i++)
    {
        // if the current GUID bit is true (1), then swap
        // the current bit with it's mirror
        if (guidBits[guidBitsIndex])
        {
            bool temp = bits[i];
            bits[i] = bits[bits.Length - i];
            bits[bits.Length - i] = temp;
        }

        // Because the data being shuffled is expected to
        // contain more bits than the GUID, this index 
        // needs to be reset
        if (guidBitsIndex == guidBits.Count)
            guidBitsIndex = 0;
        else
            guidBitsIndex++;
    }

    // HideGuidInData hides the bits for the GUID in a hard
    // coded location inside the data being encrypted.
    HideGuidInData(ref bits, guidBits);

    // Convert the shuffled data bits (now containing the 
    // GUID needed to decrypt the bits) into a byte array
    byte[] shuffled = new byte[bits.Length / 8];
    bits.CopyTo(shuffled, 0);

    // return the data, now shuffled. (this array should
    // be the length of the original data, plus 16 bytes,
    // since 16 bytes are needed to store the GUID).
    return shuffled;
}

I may be shooting myself in the foot posting this, but if it's not known that the data is encrypted using this method, brute force breaking of this takes n! time, where n is the total number of bits in the file. (basically, much, much higher than the probability of randomly guessing a GUID).

Assuming the GUID is well hidden within the file, a brute force attack would take a very long time to figure out.

I spent a lot of time learning about encryption on my way to this solution, and everything I read seemed to be WAY more complicated than this (and, obviously all the things I read dealt with two parties, where encryption can involve a key being passed between them).

What I learned is this:

1. If the key to encrypting the data is stored with the data, it's only a matter of time for someone to crack it, and get the data
2. There is no such thing as "perfectly secure". There are varying degrees of success in encryption, and generally speaking, when picking a method of encryption you will want to weigh the importance of the data being secure with the ease with which (considering processor and memory limitations) the data can be decrypted by your program.

I'm thinking that this is too simple to be a good solution. Can anyone prove that suspicion, and explain to me why this isn't as secure as some other methods of encryption? (or make me very happy and tell me this is pretty secure?)

These are the downsides to this algorithm that I can see right now:

1. The algorithm requires all of the data to be in memory (not TOO worried about this, since I'm encrypting a very small file that's ~500 bytes)
2. The algorithm requires changing the position of the stream reading the data in order to extract the GUID (basically you can't stream the file from the beginning to the end to decrypt it).

As a note, my application is not really of high importance, realistically it's not likely that anyone malicious will every use reflector to look at my code (realistically it's just people like me who want to know how something works, not do any harm).

Answer 1

This algorithm isn't going to buy you much. Someone who goes to the trouble of downloading your app and using Reflector will have your encrypted data and the code of the decryption process. They could just find your method for decrypting the data, and then use it.

The problem is that you're storing the "encryption key" in the cypher text. There is no way to make that secure when the attacker also has access to the algorithm used. Doesn't matter what crypto system you use.

The basic problem you have is that the phone application itself has to have all the information needed to decrypt and use the data, so anyone looking at the code will be able to see that.

It's the same reason that DRM schemes on DVDs, etc are routinely broken so quickly. Any device, or application, that is able to play DRM protected material has to have the means to decrypt it. Do enough poking arond in memory while the device or app is playing the content and you'll find the decryption key, and then you can crack any similiarly protected media any time you like.