One more post on encryption before moving on to other things.

In Part I, I submitted an encryption program that "should prevent the casual snoop from decoding your files." The program's security can be increased tremendously by using the random number generator to generate the key. As it stands the key must be typed in on the command line, a feature that encourages the use of short keys. When the program gets to the end of the key it goes back to the key's beginning and reuses it. In our example we used "buttermilk" as the key. In a file of 500 characters a codebreaker would then get 50 clues to the key.

The random number generator will produce sequences of tens of thousands of characters before it begins to repeat itself. The first problem we have to solve is how to get the random number generator to generate the same sequence during decoding. We solve this by giving the program a "pin" of four characters. Since each number is 8 bits we have a 32 bit seed or 4,294,967,296 possible keys. Of course the user is most likely to use pins made up of alphanumeric characters so there are more like 15,000,000 most probable keys. A user who limits himself to keys made up of easily remembered words limits himself even further. Nevertheless, the number of most probable keys is still in the 100s of thousands.

Program Crypt ;
{
    Crypt -- encrypt and decrypt
}
var
    Pin      :  String ;
    Ch       :  Char ;
begin
   if ParamCount > 0 then
      begin
         Pin := Copy (ParamStr(1), 1, 4) ;
         if Length(Pin) >= 4 then begin
            RandSeed := Ord(Pin[4])
                     + 256*Ord(Pin[3])
                     + 256*256*Ord(Pin[2])
                     + 256*256*256*Ord(Pin[1]) ;
            while NOT eof do begin
               Read(Ch) ;
               Write (Chr(Ord(Ch) XOR (Random(128) + 128)))
            end
         end
         else
             WriteLn('Pin number must be at least four characters long.')
      end
   else
      WriteLn('usage: crypt key')
end.

A few more comments are in order before we leave this subject behind.

First, users of this algorithm are usually advised that their data can be made more secure by encoding it multiple times, i.e., encode the data first with one key, then encode it again using a second key (maybe even three or four times, each time with a different key). Unfortunately the EOF bug we encountered in the first version will return full force under multiple encodings so we must limit ourselves to a single encryption.

Second, the method of encrypting a file would use redirection, i.e,

     crypt Act! < clear.txt > coded.txt

which leaves the file clear.txt on the computer. It will have to be deleted. Unfortunately, as most users of DOS know, deleting the file does not completely remove it from the disk, it only marks the space it occupied as available. Anyone hacking your machine would probably concentrate of undeleting the file rather than decoding its child. The file would need to be wiped clean from the machine, not merely deleted. How you could do this is beyond what we are trying to do here.

If your machine is physically secure you don't have to delete the original or even encrypt it. The program is most effective in moving a file from one machine to another, either on a disk carried by a trusted courier or through cyberspace.

Finally, I must state (even though it should be obvious) that it is imperative that a different pin be used for each file encoded (or re-encoded).