Along those lines, I'd hazard a guess that Rubix is gonna be a -really- poor cipher, based simply on the mathematics and patterns of the cube. You are going to need -really- long keys to have anything reasonably good.

Second, Note this: You have 6 faces, let's call them "Up", "Down", "Front", "Back", "Left", "Right", for consistancy with weirdos like me who have done a reasonable amount of study of the Cube. Those names can be unambiguously abbreviated U, D, F, B, L, and R. Second, note that an NxNxN cube has N "slices" parallel to each face, which can be labelled 0-9 (for up to 10x10x10 cubes). Then you could use the following convention: For each turn, use a letter indicating the face, and a number indicating the slice. If the letter is uppercase, turn the slice clockwise; lowercase, counterclockwise. Note that every turn can be notated two ways: U1 is equivilant to d2

Using this coding, your example could be coded in one of these four ways: U1R2, U1l1, d2R2, or d2r1.

I would suggest a couple of modifications:

First, instead of using the cube faces, use the cube cells. For a 2x2x2, this would give you 8 cells to use, rather than the 24 you have now, which is cutting down a bunch, but for a 4x4x4, you'd have 64 instead of 56, and it goes up from there. This helps deal with the issue that in your example, the three cells A,R,E are always going to move together, which helps the cryptographer immensely.

Second, add to your basic operations a way of reordering the slices -- say by rotation. Take what was slice U0, and make it slice U9 (or whatever), and renumber accordingly. That way, every cell has an opportunity to go to every other cell -- something which doesn't happen with a normal cube. This could be symbolised by a face letter with no number, like in the sequence U0bu0B, which would perform some scrambling on the upper face (but leave the rest of the cube alone, modulo data augmentation).

I'd also drop the data augmentation, and go with a pure transformation cipher.

I was under the impression that a more common notation was 'U,D,F,B,L,R for 90° clockwise turns, 'U²,D²,F²,B²,L²,R²' for 90° turns, and either 'U',D',F',B',L',R'' ('prime') or 'U^-1,D^-1,F^-1,B^-1,L^-1,R^-1' for 90° anti-clockwise. The obvious advantage of this system is that U' or U^-1 imply the inverse of U.

I would be inclined to agree with you to the security of the cryptosystem. Istr that a 2x2 cube has only ~10⁷ permutations, which strikes me as a rather small number compared to those people throw around when talking about PGP (but then, i am not a cryptologist). The number of permutations increases exponentially with cube size, so if you a use a bigger one, this may cease to be a problem.

It would be really cool if you could use the resulting cryptosystem using nothing but a Rubik's cube, some paper, and a lot of free time (à la '<cite>Pontifex</cite>'), but maybe that's a little optimistic.....


---


Some interesting cube-related links from my bookmarks:
• How to solve the Rubik's cube
• Data structures for the Rubik's cube.
• Lecture notes on the mathematics of the Rubik's cube
• Solving Rubik's cube using the 'bestfast' search algorithm and 'profile' tables

Yes, that notation is more common, but the problem is that it doesn't scale well for NxNxN cubes. It fixes the centers for 3x3x3 cubes, and it doesn't handle the inner slices for 4x4x4 or higher order cubes. The notation I described was reasonably compact, and handled cubes up to 9x9x9. That's why I went with it.

The security really gets worse the larger the cube -- mainly because of key-length. True, the total number of permutations goes up exponentially (and how! one -factor- in the number of permutations is 24!^{floor((N-1)/2)}. I don't have time to compute the other factors, but with that exponential base, who cares?), but the number of permutations that can be reached within m quarter-turns is less than 12N^m. If you want to reach anywhere near a decent subset of the permutations, you are going to quickly need huge keys. If you use too small of keys, you get too little mixing, which ruins your cipher. I'd be interested to know when the length of good keys exceeds the length of the datablock (6N²). I suspect it happens quite low -- I know 3x3x3 cubes require at least 22 quarter-turns to reach all permutations, with a datablock size of 24 characters.

Justa thought but maybe you should increment and decrement chars in the slice moved by direction, every time they move. That way when you rotate segment BAEKUWTN four times in one direction it would be the same as +4ing them but every turn would obscure the bast data up or down.

What a goofy crypt.

--
$you = new YOU;
honk() if $you->love(perl)

Yeah... that's what I said it does. I didn't do it in the example, but it's in the specification in the code.

$_="goto+F.print+chop;\n=yhpaj";F1:eval