Re: Encryption (shuffling proposal)

[peter.allan@aeat.co.uk (Peter M Allan)]

>  DALE THORN ON CRYPTOGRAPHY: (edited for brevity)

>  It appears to me that PGP encryption et al is really 1940's technology, 
>  albeit fancied up by 1990's computers.  Why use keys and cyphers when 
>  all you should have to do is maximize the randomization of bits in a 
>  script?

>  Algorithm: Select bit-groups of random length from the file until the file is
>             completely processed.  Shuffle the bits in each group randomly and
>             save each group back to the file. Repeat if needed using different
>             key-strings for each successive encryption, for increased security.

>  "Due to the nature of compounded bit-shuffling, no algorithm ever developed
>  or proposed could 'crack' multi-pass encoding with a single decryption pass.


You are producing a permutation table.  Repeat passes just get you
a new table, no different in principle.


>  [Time calc for 12kb file....]


>  "One of the difficulties in breaking this type of encryption (other than the
>  numerical time factors) is the fact that you might have to deal with several
>  unknown random number generators from different compiled executable programs.
>  Add to this another factor, the 'Intelligent User' who adds their own tweaks
>  to the source code. The tweak is added, the program is compiled, the file(s)
>  are encrypted, and then the modified source code is destroyed along with the
>  executable file.

But the internet worm of 1988 was captured, decompiled and analysed in days.
Self-modifying viruses get analysed (by single stepping).  Your programs will
go the same way as soon as there is (financial ?) motivation.

So the users have to know the algorithms, including "tweaks" in order
to communicate ?  Not the most convenient key.


>  EXAMPLE    when_it_rains_it's_a_bath   (least significant bit at left):

>     11101110000101101010011001110110111110101001011000
>     10111011111010010011101000011010010110011101101100
>     11101111101010010110001011101110010011001110111110
>     10100001101111101001000110100001100010111000010110

becomes

>     01011100010110101100011110101000011101101111101011
>     00101101100011111010010101111001011001000100000101
>     00111101010101011011000011101111001111110101001011
>     11101000001101101110101011000100111111000010111001


>From this known plaintext-cyphertext pair the enemy can list
all the possible sources and destinations of each bit.

EG  first bit of plaintext (position 0, value 1) can move to 1,3,4,5,....,199
   second bit of plaintext (position 1, value 1) can move to 1,3,4,5,....,199

Given a number of pairs of the same length, produced with the
same key details each of these lists of possibilities shrinks
by around half.  Your 12kb file is well on the way to being
cracked after 4+10+3=17 pairs are discovered.

If the intention is never to reuse keys, then this scheme gets
you nothing you couldn't have with a normal stream cipher.
And they, don't reveal the number of 1-bits and 0-bits in the
message.  Different messages will be recognisable different.

A chosen plaintext attack (where these are possible) becomes a breeze.

>        b. Passwords/phrases, algorithms, code routines, and even whole programs
>           might change from step to step, thereby invalidating any 'single-pass'
>           decryption scheme that's likely to be proposed.

How are the above remarks invalidated ?

I don't want to stifle creativity.  If you keep thinking you may
come up with a good idea.  But this isn't it.

I encourage you to read about existing systems.  There have been
bright people before, and things are done (or not done) for a reason.





 -- Peter Allan    peter.allan@aeat.co.uk