Excellent, I wasn't expecting this much of a response. This is great

OK, so the way I see it, here are the main concerns:

- Hash The password!
- Why bother spinning the data?
- What are these patterns I see?
- Black and white!
- Correlation between password strength and quality.

So, in relative order:

**1 :** Yes! hashing the password would be a good idea. I could generate a large number ( lets call it X) of bytes from a password and then use this as the "key".

The question is how large should the hash be? It clearly should be larger than 12 bytes, 24 bytes maybe?

The number of possible combinations from spinning the data appears to be 256^{n} where n is the number of characters in the key. Thus 256^{24} yeilds 6.27 x 10^{57} possible combinations. If we assume that a computer can evaluate 1 billion combinations per second, an attempt to try every single combination of 24 bytes, or brute force a password, could still take up to 10^{41} years.

**2 :** You guessed correctly when you said "to obfuscate the data." By performing these spins, a byte, or a variant there of, can end up literately anywhere within the block! On a smaller scale, a bit can end up anywhere within the block as-well, because remember we're rolling too! With 256 bytes, there are 2048 bits. There are, by definition, 2048! ways to organize 2048 bits, and by spinning and rolling we can achieve any of these combinations. In other-words, by spinning and rolling we set the maximum number of possibilities to 2048! or around 10^{5895 }possibilities.

The other reason to spin the blocks is to create multiple solutions, which sounds counter intuitive!

Just because you find a solution to a block, doesn't mean that it'll work for any other block.

So for example lets say that we have 256 bytes, where the first byte is 0 and the rest are 1. Next we have another 256 bytes where the last byte is 1 and the rest are 0. Finally we encrypt both of the data with the same password, say "boat", Now because we spun the data, there is a massive number of ways to spin the data in reverse to get the byte '1' back into the first slot, one of these ways is, obviously, to follow the pattern generated by the password "boat", however other pass-codes may work like say "hamburger" The trick is that even though the pass-code "hamburger" successfully decrypts the first set of 256 bytes, it WILL not decrypt the second set! Only the passcode "boat" will do that.

Furthermore, even if you had the original as well as the encrypted version of a file, you would still need to try MANY ( up to 256^{24 })^{ }combinations of passcodes to find the one that works for every block and crack the password.

**3 : **Ah yes the patterns in the triangles... maybe I should have been more specific in my captions.

Of course there will be patterns, this is a worse case scenario test. The data in that image is LARGELY repetitive, in fact each row of 256 pixels, the width of the image, is usually close to identical to the row above it. Encrypting blocks that only have a 1 byte difference between one and another will unfortunately yield somewhat similar results. This effect is compounded by the fact that the change between rows is fairly regular. If I reduce the size of the image to 246 x 246 pixels and then encrypt with an 8 char password, we get this:

Which while not perfect, you can still somewhat see the triangles, looks more like noise.

To spice things up, and prevent these types of patterns, the amount of roll could be varied. Part of the issue is that most ASCII pass-codes limit the amount of roll as the high bit is usually 0.

**4 : **This one is kind of silly. It's black and white because it's a black and white bitmap! - Remember I only encrypted the image/data portion of each bitmap. No amount of encryption is going to change the fact that in a grayscale bitmap, each pixel is determined by one and only byte and must be somewhere between black and white.

Here's what it would have looked like, had it not been grayscale, but 24bpp (COLOR) with an 8 char password :

**5 : **The correlation between password length and quality was *actually* intentional. I figured that longer passwords yielding better encryption was ideal. After reading some of the feedback I've gotten, I now know this to be false. By hashing the passcodes ( See # 1 ) we can remove this correlation.

Sorry if my explanations haven't been the best.

Again, thank you everybody who has spoken thus far. Any other ideas and comments would be appreciated.