The next program is one which appeared in the original Software Tools but not in Software Tools in Pascal. The program is Crypt which encrypts and decrypts a text file.

The algorithm for the encryption is what cryptologists call a "one time pad" (google it). When properly used it is theoretically unbreakable. What we are doing here does not include all the steps entailed in properly using the algorithm but it should prevent the casual snoop from decoding your files.

The algorithm consists of merging the input stream of data with a second stream, the key, to produce an output stream of encrypted data. We extract the ascii codes from each char of input and from each char of the key. A bitwise XOR operation gives us the ascii code for the output which is converted back to a char. Here is the code for Crypt.

Program Crypt ;
{
	Crypt -- encrypt and decrypt
}
var
	Key      :  String ;
	KeyLen   :  Byte ;
	i        :  Byte ;
	Ch       :  Char ;
begin
	if ParamCount > 0 then
		begin
			Key      := ParamStr(1) ;
			KeyLen   := Length(Key) ;
			i := 1 ;
			while NOT eof do begin
				Read(Ch) ;
				Write (Chr(Ord(Ch) XOR Ord(Key[i]))) ;
				i := (i MOD KeyLen) + 1
			end
		end
	else
		WriteLn('usage: crypt key')
end.

The key is a string up to 255 characters long. The input and output files are selected by redirection. E.g.:

crypt keystring < in.txt > out.txt

The elegant property of the XOR operator is that it is its own reciprocal operator. I.e., if

	c = a XOR b

then

	b = a XOR c

This allows us to use the same program for both encryption and decryption by merely switching the source and destination files.

OK! Try the following:

crypt buttermilk > crypt.dat
Now is the time for all good men to come to the aid of their country.
^Z

This should encrypt "Now is the time for all good men to come to the aid of their country." and store it in the file crypt.dat. Now we should be able to get the original text back by using crypt again. However, if we redirect crypt.dat back though crypt we get

	crypt buttermilk < crypt.dat
	N

All we get is the leading N. Why? Clearly there is a bug in the program.

The bug lies in the fact that for text files DOS treats Chr(26) as an end-of-file marker. When the 'u' in 'buttermilk' meets the 'o' in 'Now is the time...' we get

	Chr(Ord('o') XOR Ord('u')) = Chr(26)

In encrypting any file with any key we can expect this condition to surface frequently.

One easy fix for this is to assume that the input will consist only of the standard ascii characters, Chr(0) .. Chr(127). In this case the most significant bit will always be zero. If we make sure that the first bit of the key is one then the resulting encrypted bit will be one. Here is the modified code.

Program Crypt ;
{
	Crypt -- encrypt and decrypt
}
		Function Map (S : String) : String ;
		{
			maps ascii characters onto the extended ascii set         
		}
		Var
			i  :  Byte ;
		
		begin
			for i := 1 to Length(S) do
				if Ord(S[i]) < 128 then
					S[i] := Chr(Ord(S[i]) + 128) ;
			Map := S
		end ;

var
	Key      :  String ;
	KeyLen   :  Byte ;
	i        :  Byte ;
	Ch       :  Char ;
begin
	if ParamCount > 0 then
		begin
			Key      := Map(ParamStr(1)) ;
			KeyLen   := Length(Key) ;
			i := 1 ;
			while NOT eof do begin
				Read(Ch) ;
				Write (Chr(Ord(Ch) XOR Ord(Key[i]))) ;
				i := (i MOD KeyLen) + 1
			end
		end
	else
		WriteLn('usage: crypt key')
end.

Now all the encrypted code is mapped to the extended ascii set. We can still use the same program for both encryption and decryption.

The bug survives but in a more tolerable form. An uncrypted file that contains an extended ascii character could still generate an unexpecgted eof. I doubt that a totally satisfactory solution can be found. For now we'll simply list it as a "known bug."

Post Comment Return To Blog