OSDev.org

I have an array size 8 of unsigned chars. (We'll call these 8 the "key").

These 8 key-elements need to be placed into a larger array of size 8X8. (We'll call this 8X8 array a "card").

Here's the crux of the matter:

I need to read a "key" like: in which the combination of the chars (which are randomly generated) represents a specific way to arrange itself within the larger key.

To help visualize this: the '0's represent "other" values that I don't care about at this time.

Basically the placement needs to have some algorithm so that the card can be later decomposed back into its original form.

Are there any algorithms out there that are similar to this?

dudeman wrote:Are there any algorithms out there that are similar to this?

pad with 56 bytes of garbage, shuffle/encrypt

pad with 56 bytes of garbage, shuffle/encrypt

you over-estimate my abilities. little explanation pleez?

dudeman wrote: in which the combination of the chars (which are randomly generated) represents a specific way to arrange itself within the larger key.
...
Basically the placement needs to have some algorithm so that the card can be later decomposed back into its original form.

Might sound silly, but does the arrangement in larger key depend on the 8 byte key itself only? What if we arrange the 8 bytes randomly, and set the rest of 56 'don't care' values accordingly, so that we can convert card back to key using the rest of 56 values?

@Combuster:
How would encryption[!=shuffling] help? With encryption, how can you ensure that the original characters in the key will be present in the card?

Might sound silly, but does the arrangement in larger key depend on the 8 byte key itself only?

you got it.

at least, the 8 byte key should define its own placement within the 8X8 array.

prashant wrote:@Combuster:
How would encryption[!=shuffling] help?

Some forms of encryption apply shuffling, thanks

Since the process must be reversible for any given card, there are two alternatives:

either the rest of information on the card is true garbage. That means that there is one item in the key in a fixed location, and the rest of the locations are determined as a function of the locations known. The alternative is that the rest of the card is not garbage, in which case all items can be put at almost any location.

I kind of fail to see the line of thought behind the OP's question. i.e.:
WHY?

it looks kindof random to me

key size expansion maybe. Or to apparently hide the key in large mass of seemingly unrelated bytes (maybe to be used as public token).

not sure if that helps cryptographically.

Or to apparently hide the key in large mass of seemingly unrelated bytes

yeah, that's pretty much the idea.

The rest of the 56 bytes are not completely unrelated. They do represent the actual information being encrypted. Therefore they have a certain relationship to the 8 key bytes.

As to WHY? as combuster asked, I'm starting out with a relatively small amount of information and relatively small containers, to keep the complexity down a bit for testing purposes.

Once I've worked out all the kinks, the complexity of the encryption will be jacked up a bit.

As for now, I need to figure out how a seemingly random group of 8 bytes can actually define their own behavior.

This reminds me of AES encryption, it uses a fixed block as a translation table. I think this is what your trying to do.

B.E wrote:This reminds me of AES encryption, it uses a fixed block as a translation table. I think this is what your trying to do.

My technique is similar to the AES in that uses grids and sub-keys, however the encryption technique itself is somewhat different. For one, the "keys" are embedded, this has advantages and disadvantages.

The main advantage with embedded keys is that in encrypted form, the key is practically indistinguishable from the other data.

The main disadvantage is simply bloat.

At current, the key accounts for 1/8th the size of the file itself, which is flat unacceptable. So once I can work out some different schemes, I hope to get that ratio down quite a bit.

The only remark I want to post now is this: the enemy knows the algorithm. I.e. if you want there to be a way to lift the key from the sequence, Trudy can do the same and decrypt everything with the same ease.

The only remark I want to post now is this: the enemy knows the algorithm.

At first glance it might seem that way, but really there's much more to the algorithm than what i've disclosed here.

To be honest, I'm beginning to think this whole idea of taking a string of chars to represent a specific permutation is one of those "unsolvable-problems" like some famous conjecture for which the experts will tell you, "It's never been proven, but if your going to attempt it, you're just wasting you're time!"

I suppose another thread in the program could in theory develop the algorithm for me, but there's a major problem with that design... time.

One of the greatest things I can see with the AES is that it's pretty darned efficient (with respect to time and with respect to where my technique is at this point.)

The best I could come up with:

for an 8X8 grid with an key-length 8, there's something like 1.78x10^14 ways of embedding the key. Using uppercase/lowercase/digits that's a pssword of length at least 8. However, considering what i've disclosed and and the simplicity of such a substition it hardly seems worth it.

I'm going to sleep on this one for a while...

This type of encryption is redundant (i.e anyone and everyone can work out the key base on the encrypted data. but here's a solution to it anyway.

Here's an Idea, work out the position of the next char in the key based on it's the previous chars value, for example 8x8 using a 3 bit per char, 8 chars long (key 1 2 3 4 5 6 7 :
Also the position of the first char of the key could be related to a check sum of the block.

Here's a way around doing that, yet still allows the client to decrypt the message, have a look at how SSH Key Exchange solves this problem.