Results 1 to 5 of 5

Thread: Swap Encryption

  1. #1
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts

    Lightbulb Swap Encryption

    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:
    Code:
    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...

  2. #2
    Member biject.bwts's Avatar
    Join Date
    Jun 2008
    Location
    texas
    Posts
    449
    Thanks
    23
    Thanked 14 Times in 10 Posts

    swap encryption

    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?

  3. #3
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    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!

  4. #4
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    Just wrote some testing program.

    OK, check this out. The phrase:
    "ENCODE.RU" 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.

  5. #5
    Member biject.bwts's Avatar
    Join Date
    Jun 2008
    Location
    texas
    Posts
    449
    Thanks
    23
    Thanked 14 Times in 10 Posts
    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.

Similar Threads

  1. Idea: Combine Compression & Encryption
    By dirks in forum Data Compression
    Replies: 16
    Last Post: 22nd February 2010, 11:49
  2. interleaving 2x 256bit = 512bit encryption ?
    By SvenBent in forum Data Compression
    Replies: 6
    Last Post: 30th August 2009, 21:20
  3. XOR encryption
    By encode in forum Data Compression
    Replies: 12
    Last Post: 16th March 2009, 10:49
  4. Simple encryption (RC4 like)
    By encode in forum Forum Archive
    Replies: 37
    Last Post: 26th January 2008, 04:05

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •