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!

There is the problem, it is not enough if the set of all passwords allows any bit to appear anywhere. You would need to make sure that for a single password the bits are shuffled around enough that they can be anywhere, but as can be seen from your pictures thats not happening. I would think that is because of an inherent flaw of your pinwheel thing, that moves the bits in a very predictable way that mostly depends on the source data and not much on the password.

And you know, xor obfuscation is the first thing everyone tries, but cause of its property of revealing a source bit by double xor-ing it with the same bit it will never make a good encryption in that way you use it, even if your method is a bit more elaborate than usually seen.

(a xor x) xor x == a

encrypting identical datas returns identical results.

Well, i know you asked not to point it out, buuut... i think that's the biggest flaw in your algorithm. Encrypting identical data should NOT return identical value...

Anyway, i guess that code is just for your personal usage so, who care. No one is probably gonna try to break your code, unless you ask them to.

Imo that's good enough for personal use.

My first encryptor was showing a similar flaw (you could see parts of a bitmap image in the noisy background), then i just created another algorithm, which isn't perfect, but at least give no clue as in your image, everything always look 100% noisy, but even then, ppl started pointing flaws about it. (You definitely should read this post)

For me, i guess that just good enough for my need, althrough i never used it yet for anything, it was more for learning than anything else.

For the fun of it, i encrypted your image using my algo. discussed above, and it gave me this. That's what you should aim.

PS: dont take me too seriously, im no encryption expert...

What I'm trying to say is that for a set of inputs - the passcode being X and the 256 byte block being Y - the algorithm should satisfy the requirements of a "function" : for a given set of inputs the function should return a specific output

F(x, y) == z always

If two blocks are identical, Y1 == Y2, and they are being encrypted with the same pass code, then F(X, Y1) == F(X, Y2) == some value z

Our ability to decrypt the data, given the correct passcode, relies on this fact.

Now if I wanted two identical blocks encrypted using the same passcode to not return equivalent values, I would need to add another "variable" to the function.

So If I added the block's number as variable W so,

F(w, x, y) == z

then two identical blocks, being encrypted with the same pass code would not give identical results.

I tried this and the results were promising :

However, I decided that the algorithm shouldn't care or know which block it was dealing with, as an "attacker" could easily later determine this "variable" and use it to weaken the integrity of the system

I'd rather have only two inputs X and Y that can't be determined by looking at the encrypted data, than

three variable W, X and Y, where one of the variables could be determined.

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!

There is the problem, it is not enough if the set of all passwords allows any bit to appear anywhere. You would need to make sure that for a single password the bits are shuffled around enough that they can be anywhere, but as can be seen from your pictures thats not happening. I would think that is because of an inherent flaw of your pinwheel thing, that moves the bits in a very predictable way that mostly depends on the source data and not much on the password.

And you know, xor obfuscation is the first thing everyone tries, but cause of its property of revealing a source bit by double xor-ing it with the same bit it will never make a good encryption in that way you use it, even if your method is a bit more elaborate than usually seen.

A bit can take multiple paths to end up in the same spot. By taking these alternative paths though, the other 2047 bits also take alternative paths.

The movement, or spinning if you will, is determined only by the passcode, and there is only one combination of spins, only one passcode, that will decrypt all of the blocks.

Even if you know that the data was "spun", you don't know which path it took.

I imagine this path on a massive tree where each branch has 256 child branches, and each of those child branches has 256 child branches and so on.

The number of unique combination for a given password length n is 256n where hopefully n is some large number like 24

Also, there is more than XOR'ing going on, there is twisting, turning, and in the newer version, turbulence ( noise ) being added to the mix.

To decrypt, each byte must not only be XOR'd with every byte it had been, which would have to determined some how, but it must do so in the correct order as other operations such as rolling and the turbulence take place. In other words, you must follow your exact path up the tree to retrieve the original data.

Yes, this is only a pet-project, so it's not likely anyone other than myself will ever use it.

Still, I'm happy to see other people's ideas.

If a is a point in the above picture with the triangles, then there is a high chance its rotated and xored twice (or any multiple of 2 times) with the same color from one of the big same colored areas, then you have a as "encrypted" data although its actually not. (There are a few other things happening and then it results in those stripes.)

If a is a point in the above picture with the triangles, then there is a high chance its rotated and xored twice (or any multiple of 2 times) with the same color from one of the big same colored areas, then you have a as "encrypted" data although its actually not. (There are a few other things happening and then it results in those stripes.)

Impossible, each block is processed independently.

I think I wasn't clear in my description of what a block is.

A block is 256 bytes; the picture divided into 9 areas, does not show 9 blocks, but rather 768.

Maybe this will help with my explanation of what a "block" is

*Pretend I was able to draw 768 lines ( which each represent a block )

Sorry if I've been a bit hard to understand, my mind is focused on Thanksgiving

But, in the case where data is divided as such, and each block is independently encrypted, does this make sense?

(a xor x) xor x == a

Yeah but you don't have "a", you only have the encrypted data...

This situation is not so far fetched, if you just XOR password with data:

Source data:            010203040506000000000000000001020304050
Password: (XOR)         70617373776f726470617373776f72647061737  (password repeated over and over)
Result: (XOR-encrypted) 71637077726a726470617373776f73667365727
Similarities:           7 6 7 7 7 6 726470617373776f7 6 7 6 7 7
Oops, password in clear text:       r d p a s s w o

So if you are going to use an encryption algorithm based on XOR, you need proper "random" data to XOR with. Anything else will be exposed.

EDIT: (But I probably misunderstood your question, as I saw you already got your answer.)