From: ichudov@algebra.com (Igor Chudov @ home)
Date: Sat, 31 Aug 1996 02:02:15 +0800
To: dthorn@gte.net (Dale Thorn)
Subject: Re: Encryption
In-Reply-To: <3226ADC6.6C87@gte.net>
Message-ID: <199608301351.IAA09141@manifold.algebra.com>
MIME-Version: 1.0
Content-Type: text


Khm, am I being trolled?

The purpose of encryption is to make decryption easy for designated
parties and hard for all others. The proposed algorithm simply destroys
the original text that you had. How you plan to decrypt your encrypted
messages?

It is not an encryption method, it is "data destruction" method.

igor

Dale Thorn wrote:
> 
> This is a multi-part message in MIME format.
> 
> --------------5E91F122B2E
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> 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?
> 
> --------------5E91F122B2E
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline; filename="readme.1st"
> 
> 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.
> 
> --------------5E91F122B2E--
> 



	- Igor.