From: Dale Thorn <dthorn@gte.net>
Date: Fri, 30 Aug 1996 20:10:51 +0800
To: cypherpunks@toad.com
Subject: Encryption
Message-ID: <3226ADC6.6C87@gte.net>
MIME-Version: 1.0
Content-Type: text/plain

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?  Big computers should not be able to de-randomize such encoding, 
since the permutations/combinations would be astronomical after just a 
half-dozen or so random number initializations, as well as the fact that 
the bits are relatively undifferentiated (just ones and zeros) and are 
not maintained with their original bytes, words, paragraphs, or pages?


DALE THORN ON CRYPTOGRAPHY: ABSTRACT                            23 August 1996
------------------------------------------------------------------------------

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.

"If a high-speed computer could perform 'a trillion processor ops per second',
and it took just one millionth of a second to 'crack' my test file on such a
machine (i.e., a million ops), it would still require 10^36 ops to 'crack' 6
consecutive encodings, which translates to 10^24 seconds, or 3 x 10^16 years."

"Due to the nature of compounded bit-shuffling, no algorithm ever developed
or proposed could 'crack' multi-pass encoding with a single decryption pass.
In plain English, if a file were encoded six times (in six passes, with six
different password phrases), you'd have to decode all six passes before you
would know whether even the first decryption pass was successful or not."

"Since each byte in the encrypted file may contain bits from other 'original'
bytes, multi-pass encoding moves you rapidly in the direction of true-random
distribution of the source bits (note the 'Intelligent User' comment below)."

"My desktop computer (a 90 mhz Pentium) can encrypt a 12 kb file in less than
one second (in a single pass) using 'C', and takes less than two seconds with
the PDQ version of Basic I use, hence, the six passes that I normally perform
on such a file require nine seconds or less total computer time."

"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.  This type of modification, together with the fact that the
individual bits in the encrypted text file are scattered very effectively in
normal encoding, yields the ultimate level of security for concerned persons."

------------------------------------------------------------------------------
A SIMPLIFIED EXAMPLE FOR ENCRYPTION/DECRYPTION
------------------------------------------------------------------------------

We're going to encrypt the following 25-character text string:

   when_it_rains_it's_a_bath

The unencrypted string (in bit form, least significant bit at left) is:

   11101110000101101010011001110110111110101001011000
   10111011111010010011101000011010010110011101101100
   11101111101010010110001011101110010011001110111110
   10100001101111101001000110100001100010111000010110

We now generate 200 random numbers, and sort them in ascending order.
The following list represents the original physical positions of the
numbers, and we move the bits as shown above from these positions in
the 25-byte text string to bit positions 0, 1, 2, etc. (move bit #4
to the first position, move bit #179 to the second position, etc.).

     4 179  67 127  46  76 136  74  92  54
    88 121 134 192  77  36  47  26  45 144
   111 141 150  58 110  12  94  13 161 177
    18 155 153 175  91  95  86 195  79  20
    23 172  51  96 126  93  64   3 125  81
   166 131  71  63 170  78 140  87 107 147
    15  35  10 168  33 149 189 118  42  90
     6  85 120  68 102 173 103 104 138  83
    53  43 182 139  29  60 146 184 176 114
   123  44 191  56  70 185  73 137 148 199
   196  27  65  62  37 181  28   0 106 158
   100   1 190   2  25 194   8  30 174 101
   105 135 162  61  75  32 115 142  14  49
   186  50 183  21 119  52  69  99  11  89
    72  34  98 188  82  17 163   9 167 109
   113 171  38 157  84   5  59 178  22  57
   151 122 160 130  39 116 133 156 164  66
   159  40 124 193 108 180 152  41  97   7
   197 145 132 169  55  16  24 165 198 112
    19 129 187  31 154  48  80 128 117 143

The text string (in bit form) following the first encryption is now:

   10001010010000110111011110111010001011000001110010
   10000110110100101101110111010111101110100001100110
   01110101111111100111101001111011010110111101001000
   00110110110111001010011010101011010100110100001110

At this point, it's obvious (with a sufficient length of text to analyze) that
we could restore the original text using an algorithm equivalent to the pseudo-
random number generator we used above.  However, we're going to encrypt again:

Generate another 200 random numbers and sort them in ascending order.
The following list represents the original physical positions of the
numbers, so move the bits the same way we moved them above (move bit
#41 to the first position, move bit #9 to the second position, etc.).

    41   9  38  86  67 108   8  99 157  69
    91   6  15 150  28 192  56  98  54  72
   145  19  48  64 183 147 102   7 138 177
   167  29 164 176  97  82  83 168 181  95
   185  22  21  30  93 182 109  39 197  14
    96  40  84 137 155 143  16 126  58  33
   149 144 140 159  88 189   4 190 153  90
    68 114 129  45  53 112 119 125 127 124
    20 141 142  77 188 115 175 105  60 194
   106  80  31  49  51 116   1 113 151  94
     2 199 161 146  71 101  62  66 154 166
     3 128   5 118  10  61 110 165  43 122
    42  47 184  46 133  85  74 173  36  44
   111 171  89  35 163 136 162 198  17  23
    78 152 121  37  12 186  55 169 103  24
    34  26 178  87  81 123 132 195  65  11
   174 191 193 172  18  25 196 107 120 187
    27 100 180 134  59 135 179  57 148   0
    63  13 158 130  70 131 117 139  32 104
    92 170  50  76  73  79  75 160  52 156

The text string (in bit form) following the second encryption is now:

   01011100010110101100011110101000011101101111101011
   00101101100011111010010101111001011001000100000101
   00111101010101011011000011101111001111110101001011
   11101000001101101110101011000100111111000010111001

Now that we've doubly-encrypted the text string, try to describe an algorithm
that will restore the original string in a single decryption step, i.e., move
directly from the last-encoded text to the original text without the need for
an intermediate decryption step.

Text parsers and lexical analyzers won't do you any good in intermediate steps
as described above, since all intermediate encodings will be garbage text (not
only will the bits in each character be scrambled, but bits will be scrambled
across characters, words, and paragraphs as well.

Multi-step decryption could be facilitated where text can be analyzed a few
characters or words at a time, assuming the analysis engine could determine
from where to get the appropriate bits when processing a large text stream.

In the above examples of bit-level encryption, the individual bits migrate to
various places in the text string rather than remain within each set of eight
bits which DOS arbitrarily designates as character bytes. Therefore, the ONLY
tenable (but not necessarily viable) methods for decoding such text are:

   1. Try rearranging the bits randomly.  The disadvantages are:

      a. You could come up with "Mary had a little lamb...", etc., given
         that the bits are minimally differentiated (just ones and zeros).

      b. Decryption would require eons of time (an exponential factor of the
         number of bits processed, divided by the cycle time of the computer).

   2. Decrypt the text one step at a time, in the reverse order of the
      encryption steps.  The disadvantages are:

      a. You can't be sure you've decrypted any step correctly until decryption
         is completed (until all steps are performed and the text is readable).

      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.