Swap Encryption

[encode]

Just an idea. Instead of XORing data with PRNG's output we may swap bytes in input block according to the random bytes.

For example:

for I := 1 to Count do
begin
  J := Random(Count - 1) + 1;
  Temp := Buf[I];
  Buf[I] := Buf[J];
  Buf[J] := Temp;
end;

Encryption/Decryption is not equal - we must pass forward or backwards and at some stage we need vector of random numbers - to pass backwards.

This thing may be used with other encryption tricks. It's just fun how we may mix and swap all bytes within a given block...

[biject.bwts]

Well It's a thought. But seems like a waste of the random numbers. I think it's not a good idea. First of all you have to keep track of the random numbers like large key. Second if the message is short there may only be one sorting of the message that makes any sense. If you have an array of random number the length of message then using it as a OTP leads to perfect security in the Shannon sense why mess with perfection.
However why not do a bitwise UNBWTS on the message and then use the random array to XOR the results. I think that might help to extend the life of the random data as a key so that it could be used several times before a break where as doing nothing to the message the break would occur as soon as the second message sent. That is if the attacker is using a ciphertext only attack and your encrypting in plain english text ( or Russian test) So what is your comment on that?

[encode]

Think more deeply on my idea. PRNG's output may be attacked by the first bytes of the encoded data - especially if you know the first bytes of the plain text. For example if we encrypt an EXE file - the first N bytes of the header always the same. (MZ, DOS header, PE, etc.) And now imagine that we spread all header and other bytes across the entire file... And after do regular XOR+PRNG for example...

What about compression+encryption. I think any method may be used. Especially, good CM compressor with complex modeling and a high compression ratio might rock! I tried LZW with fixed codes - each 16-bit code XORed with random 16-bit number... Nice and simple!

[encode]

Just wrote some testing program.

OK, check this out. The phrase:

"encode.su" is the *BEST* forum about data compression around the globe!

Transforms into:

C ameaE.t*hed"ih ng bstoicoosSu Nr Uu*mbtpn e oouadTEE"rfBs!a eD orlORt

And such transform is reversible.

[biject.bwts]

Well if you use Shanons Unicity Distance based only on common frequency you can see that it changes nothing. You do protect against users that have a common hearder if attacker trying to break on some common header you have protected against that. If using a just a repeated password XORed for encryption the attacker could easily determine the password. Know once the password is found then you get the shuffled ascii. The attaker knows he has the correct key by Unicity constraints. He has at least seperated the problem at this point security is know on the strength of your method. With the UNBTWS the layer that was xored by a password would be harder to attack since no easy way to use standard methods to know if you have part of the repeated XOR key if off even by one bit you would have to test them all.