Spinning bits in three dimensions

[czardas]

I had this idea a while ago while I was working on entropi. The concept is to treat a text file as if it was a multidimensional object. The first two dimensions are easy enough to visualize: the line length multiplied by the number of lines makes a 2D object. The third dimension is introduced by thinking of each character as being made of eight bits. So for example, consider a text file with 8 lines, each containing 8 characters of 8 bits: this can be represented as an 8x8x8 cube full of ones and zeros.

Now I spin the bits in every direction, similar to a rubix cube, only much bigger. I'm not sure if there are any standard proceedures for 3D bitwise shift functions, so I'll stick to using binary strings, which make me feel more at ease.

17 September 2011 Thie earlier version can still be found in reply no.11
Added Error checking and detailed comments.
Either a string or an integer array may now be passed as the password parameter. String passwords are transformed into a unique array of integers not associated with any other password. The numbers are difficult to predict and it will probably be impossible to detect any kind of telltale pattern in the binary. Passwords can be as long as 2500 characters or 4000 array elements: you decide the strength.

New version 26 September 2011
Added one more level of complexity. New functions include :
_EncryptFormat => Func to change layout after spinning the bits
_DecryptFormat => Func to reconstruct layout before unspinning the bits

The changes effectively detroy a vast portion of most original templates. The original layout is needed to spin the bits back into position. The effect of the changes is most dramatic when the line lengths vary a lot. If all the lines are of equal length, then the lengths of the lines will not change, although the encrypted hex values will almost certainly end up out of alignment with the line breaks.

I have also added four new examples to the rar file.

LINK REMOVED BY THE AUTHOR

Edited November 11, 2013 by czardas

[MvGulik]

Mmm. ... ...

Org data: [A,B,C,D] (org data, in 1Dim(minimal) data-line.)

normal shift+carry: (+1:->)[D,A,B,C] or (-1:<-)[b,C,D,A]

[D,A,B,C] can also be seen as picking up 'D' from the 'data line' [A,B,C,D] where the line is cut between 'C' and 'D' (uncut [A,B,C,D] would be a infinite(looping) line.) ... -4(4:position,-:direction)

[b,C,D,A] would be picking up 'B' from [A,B,C,D] with the cut between 'A' and 'B' ... +2

Figure you can do the same visual trick for 2 or more dimensions. For both pulling and putting the data(seen initially as 1D-data line) in-to or out-off a 'array'->'multi-dimensional space'

- code wise using a multi-dimensional array is probably not really needed. Just a 1D-array(or equivalent structure) and a number of loops ... this is where my brain start to draw blanks though.

Anyway, not sure if it makes sense, but was fun to think about it for a moment.

Edited September 10, 2011 by iEvKI3gv9Wrkd41u

[czardas]

Anyway, not sure if it makes sense, but was fun to think about it for a moment.

I'm trying to figure out what you mean here. I decide to go with the two dimensional array to represent each byte because having a three dimensional array with an element for every bit would quickly exceed autoit limits. I haven't yet added error checks to avoid exceeding limits. What you call 'normal shift+carry' seems to be shifting 4 bits in one hit. The code I wrote shifts individual bits all over the (3D) map. When there are gaps, such as empty lines, each bit jumps to the next available slot. The new arrangement maintains the same shape as the original text.

If I spin one bit to the left from:

A,B,C,D = 1010101111001101b

I get

5,7,9,B = 0101011110011011b

But that's just part of the story as there are three dimensions involved.

Another interesting fact is that it took 30 years for computer scientists to solve the Rubix cube: Link

From this fact alone, I speculate that the number of millenium required to solve a much bigger cube will be (in some way) exponentially proportional to the size of the text file data used to create it.

Edited September 10, 2011 by czardas

[MvGulik]

Gabs ?

Gabs are like weeds(plants), there related to some additional context(garden instead of biology).

My context is related to a pure data view/collection. Or completely ignoring the fact that the origin of the data is textual in nature. Or viewing white space (or zero's for that matter) as being data to.

Bits: That just a practical point of the smallest(possible) data/unit size your using in your code. You also could just use bytes or character(UTF) as smallest unit. That's also why I used A..D as data units in my example, better readable instead of '010010'. (Ergo: 1 unit shift.)

Line = data stream, Image = array. (odd array I admit)

[czardas]

Bits: That just a practical point of the smallest(possible) data/unit size your using in your code. You also could just use bytes or character(UTF) as smallest unit. That's also why I used A..D as data units in my example, better readable instead of '010010'. (Ergo: 1 unit shift.)

True but, if you use bytes as the smallest unit, the third dimension will either be lost or reduced to a depth of only two characters. It may still be a daunting task for a quantum super computer to unravel, but I personally prefer to err on the side of caution.

Line = data stream, Image = array. (odd array I admit)

Very pretty, but it's still only two dimensions.

[MvGulik]

Don't think the point is getting trough. Might try some code myself later if I get to it and get it working ... (you do know that that image is a fractal based image right?)

[czardas]

Okay, perhaps I can offer some explanation. I intend to read the data from a file and use it in conjunction with other programs I make. However the concept is valid for any kind of data that can be arranged in a multidimensional array. The only tricky part was skipping the gaps where lines are too short or completely empty. If you wanted to parse a large amount of data then perhaps a system involving less passes (or a larger base unit such as 8, 16 or 32 bits) would be more appropriate.

I immediately thought of Mandelbrot when I looked at the image. Although the equations are unfamiliar to me, and probably somewhat over my head. I would be interested to look at your code if you post it.

Edited September 10, 2011 by czardas

[MvGulik]

No code of my involved. Source: The Van Koch Line Fractal

e:on->of

Edited September 17, 2011 by iEvKI3gv9Wrkd41u

[czardas]

Yeah I remember seeing this fractal construction previously, now you remind me.

When I mentioned code, I meant the implementation of a similar idea to the bit spinning in the first post. To be honest I was up a whole night trying to get it to work, and when it finally did work I was excited enough to start this thread.. I am hoping that I can turn the concept into a simple and effetive encryption to unlock parts of a program at startup.

While the current implementation is working, it still has some way to go before it can be effectively used for this purpose. I think it will eventually be worth my while, but the current use of the password is inefficient: the weakest link in the chain.. I'll fix that in due course. ==> FIXED

Edited September 17, 2011 by czardas

[czardas]

Problems caused by ineffective use of the password (while serving to demonstrate the subtleties of the algorithm) have been eliminated. It was simply a question of spinning the password (now a single array of numbers) between each change in spin direction on the bits. I have left the original post intact so you can see the difference it makes (when the password is corrupted).

This project is near to completion. The algorithm itself is complete. The only thing left to do is to find an elegant solution for creating the integer array from an average length password - it's an arbitory detail. The array doesn't need to be too large. I think the integers should range between 0 and about 1023. Since there are so many possible solutions, perhaps someone might want to offer some suggestions. If not, then never mind.

I don't know why I would get so excited by this. I imagine similar techniques will have been implemented previously. I'm not going to make any claims, other than to say: I'm pleased that I got it working! Still need to add one or two error checks.

Edited September 17, 2011 by czardas

[czardas]

I had trouble updating the code in the first post, but I manage to add an attachment with all necessary files included. See above.

Encrypt_3D.au3 ===> Requires >modal.au3

CODE REMOVED BY THE AUTHOR

All the error checks appear to be working fine, but the encryption still needs another few decades of testing. Please tell me if you find any bugs. Feel free to add more images of fractals: they make really interesting passwords.

Now I think I know what went wrong in the first post.

Edit
So far no known bugs but, I am likely to tidy up this code in the near future. It's still a bit messy to look at. Further tests need to be run on performance and size limits. I also need to ponder over the probability of ones or zeros forming clusters within the three dimensional space: and whether or not any such patterns are anything to be concerned about.

Edited November 11, 2013 by czardas

[czardas]

New update to first post.

The jar was full, but the lid hadn't been screwed on tightly enough. After spinning all the bits in my cubic type structure, I decided to take the thing apart and leave it in bits. No pun intended.

Although this is an experimental project, I'm going to push the boat out and say that Encrypt_3D is intended to be a sledge hammer to crack a nut. It doesn't rely on any sophisticated technology and simply uses brute force to produce maximum corruption. I can't rule out the possibility that someone will find a clever way to exploit some unthought of weakness. Use the code at your own risk.