This is crude ASCII rendering from the MS Word 97 document Encode.doc.
Winword gets worse with every version at generating text-only documents.
This was partly manually tidied.

ENCODE ENCIPHER ENCRYPT FOR ELECTRONIC MAIL
VERSION 3.1

Purpose

This package includes three different methods of preparing binary or text files for sending via Email.
"Encrypt" is a one-write encryption system for sending private messages over insecure
communications channels.  Even the NSA and CIA cannot crack the code if you take a few simple
precautions.  Encrypt uses the Mexican peasant algorithm, which is a bit cumbersome.  That is the
penalty you must pay for 100% security.  Note that the commonly used DES government standard
encryption algorithm is in theory crackable.
Encrypt can also be used to encrypt files that are not even going to be sent via electronic mail, but
which must be stored in an uncrackably secret form.
The pacakage includes a simpler system for sending secret messages.  "Encipher" is quick and
inexpensive and keeps the casual observer from intercepting the message.
The computer programs "Encode" allows spreadsheets, programs, source code, word processor docu-
ments, data files (in fact any file at all) to be sent via electronic mail (e.g. Envoy, GTE Telemail,
SourceMail, MCI Mail, Telex, Western Union EasyLink) between MS-DOS (i.e. IBM PC compatible)
computers with perfect integrity.

Without Encode/Decode word processing files lose their formatting (underline, bold etc.) when they
are sent via electronic mail.  Documents with lots of blank lines in them often flood the
Telenet/Datapac packet network resulting in "data lost" errors.  Programs and spreadsheets cannot
be sent at all as the Electronic Mail systems cannot handle the special characters in them.
Teleprocessing programs often tack on extra characters at the beginning and end of documents that
must be removed manually.  Static on the phone lines can garble the transmissions with no warning.
Encode and Decode do not actually send the documents.  Programs such as Procomm, PibTerm,
QMODEM, Telix, Procomm Plus, Smart-Com or PC-Talk do this.

Encode prepares a document for sending by converting all the special characters in the document
into ordinary characters.  The document is then sent via Envoy, Telemail, Telex etc.  At the other end,
Decode converts the ordinary characters back into the original special characters.
Encode also compresses the document and prepares it in special ways for very efficient transmission.
This means that the charges for sending the document are less.  For a simple word processing
document, the encoded form is shorter than the original document.  Even in the worst possible case
the encoded document is never more than twice as long as the original.
If any characters were garbled in transmission via Electronic Mail, Decode would detect this and
warn you that you must send the document again.

It costs about $0.60 per 1000 characters to send a file by electronic mail.  Thus it is usually cheaper
to send files by mailing a diskette rather than by sending via electronic mail.  Electronic mail is best
used for short files or when the files are needed immediately.
Now that EMAIL services are offering ZMODEM, XMODEM or other binary file transfer methods,
ENCODE is not as important as it was back in 1985 when it was written.  However big brother has
become ever more invasive, so ENCRYPT is even more important than it was then.

Justification

These seven programs predate the Internet. They are distributed now mainly to explain how
uncrackable ENCIPHER style X-or one-time-pad algorithms could be used to provide complete
assured privacy for Internet email and telephone conversations.
Americans have given up an extremely important right --  the right to privacy by solidly encrypting
email and telephone conversations in a way the government cannot crack.
As technology advances, authorities will be tempted to use artificial intelligence to monitor all
telephone conversations and email.  The time to head off this potential Orwellian future is now.
Here are eight ways to fight back.

1) Encrypt routinely with PGP or other schemes.  If ALL email traffic were encrypted, it would be
huge job to decrypt and monitor it all even if the authorities had the ability to decrypt parts of it.

2) Lobby software vendors to have email software routinely, by default, and automatically
encrypt/decrypt all email.

3) Push telephone manufacturers to include encryption chips in cell phones.

4) Use civil disobedience and break the law and use  X-or one-time-pad encryption. This is even in
theory uncrackable.  The algorithm is extremely simple. The basic idea is quite old and was used
long before the invention of the computer.  Russians used it during the cold war for highly secret
diplomatic messages. You can get some circa 1985  DOS code with Pascal source that still works
from http://mindprod.com/zips/encode31.zip to understand how it works.

5) Push manufacturers to build X-or one-time-pad encryption hardware. The master key generator
uses a small radiation source (like that used in smoke detector) to generate truly random
numbers which are recorded on a CD or DVD.  Key CDs or DVDs are distributed by courier.  The
encoder/decoder is just an ordinary CD or DVD reader and a small cpu.  It is simple byte-wise X-
or between message and key to both encode and decode. The cpu power needed is almost nil.  A
100% secure cellphone would look a bit like a Sony Discman glued to a cellphone or attached to
a cellphone by a wire.  A single CD key disk could perfectly encrypt one hour of CD-quality
speech, or many hours of telephone quality speech, or six hundred megabytes of email.

6) Challenge the encryption laws, including those that forbid exporting decryption software to
people in other countries whom you may want to communicate with privately.

7) Dissemble.  There are many ways of hiding encrypted data such as random variations in photos,
or random variation in tree height data etc.  There is no way to PROVE you did it.  You can
provide a phony key disk that will decode your actual message to say ANYTHING you want it to,
even something edifying like the Bible.

8) Encryption is legal in other free countries such as Canada, England and Sweden.  Push vendors
in those companies to create X-or one-time-pad software for email and hardware for cell phones.

Who Should NOT use Encode

Note that if you use the Ezymail program with Envoy or GTE Telemail then Encoding is unnecessary
because Ezymail has built in encoding.  Some electronic mail nets are now offering Xmodem or
Zmodem file transfers.  If these protocols are available they should be used in preference to Encode.
The best Email system I have seen so far is Zoomit which handles all file transfers completely
automatically.  If you are using direct computer to computer long distance calls, you should use
Zmodem protocol in preference to Encoding and using ASCII protocol.

What Encode Is For

If you wish to send a file, you must first use ENCODE to prepare it for sending, then send it using the
standard electronic mail, then use DECODE at the other end.

What Decipher is For

If you wish to send a confidential file you must first use ENCIPHER to prepare it for sending, then
send it using the standard electronic mail, then use DECIPHER at the other end.  Note that an
amateur cryptographer could crack the code if he intercepted the file or had a copy of DECIPHER.

What Encipher Is For

If you wish to send an absolutely top secret confidential file you must first use MAKEKEY to prepare
a secret key file.  This file must be sent ahead of time via secure courier to the recipient.  If the key
file were sent by electronic mail (using ENCODE ENCIPHER or ENCRYPT) you would risk
interception.  Then when you wish to send a secret message you must use ENCRYPT to prepare it for
sending, then send it using the standard electronic mail, then use DECRYPT at the other end using
the same keyfile used to encrypt the message.   For absolute uncrackability (even by the CIA and the
KGB or anyone else with access to special supercomputers) the key file must be used only once and
it must be longer than the message encoded.

If you are serious about using Encrypt, you should also use the Norton Utility every night to fully
erase any erased files.

WIPEDISK C:/E

The public domain COVERUP will do an even better job, since it also wipes information in the file
tails and in unused directory entries.

If someone wishes to crack your code, the way he will do it is by breaking in to either the sender or
receiver's computer installation and secretly making a copy of the key file.  The key files and any
decoded secret files must thus not be kept on hard disk.  They must be locked in a safe on floppies.
It is quite safe to leave Encrypted files lying about on your hard disk.  If you suspect a breakin, send
out a new set of key files.

Under no circumstances send key files by electronic mail, regular mail or any service that could be
tampered with by the codebreaker.  If you get lazy and reuse key files, or use keyfiles that are too
short, or use text files as key files, any clever codebreaker with access to a supercomputer will soon
crack your codes.

Of course it is perfectly safe to send the Encrypted files via electronic mail or over any other insecure
channel.

Using ENCODE to send files

e.g. ENCODE  C:\SYS\MYPROG.COM  C:\SCOM\MYPROG.TEL

This means encode file MYPROG.COM on disk C: in subdirectory \SYS and create a file called
MYPROG.TEL on disk C: in subdirectory \SCOM placing the encoding of MYPROG.COM in it.
Never use the same name for both files.  ENCODE does not modify or destroy the original file

MYPROG.COM.
The file C:\SCOM\MYPROG.TEL can then be sent using the standard electronic mail.  Don't send
MYPROG.COM!!
Using DECODE to receive files
e.g. DECODE  C:\SCOM\MYPROG.TEL  C:\FASTSYS\MYPROG.COM

This means decode file MYPROG.TEL on disk C: in subdirectory \SCOM that has just arrived via
electronic mail and create a file called MYPROG.COM on disk C: in subdirectory \FASTSYS placing
the decoded original contents into it.
If the C:\FASTSYS\MYPROG.COM is left out, the program will fill it in for you automatically with the
name of the original file on the sending system.  This name (C:\SYS\MYPROG.COM) is embedded in
the MYPROG.TEL file that is sent.
Never use the same name for the two files.  DECODE does not modify or destroy the input file
MYPROG.TEL.

If DECODE Beeps and prints an error message that the transmission was garbled, you have three
choices:

1)      Use the file as is knowing that it is slightly corrupted.  Attempt this only with word processing
documents.  Any *.WKS spreadsheets, *.COM or *.EXE program files cannot be used even with
the tiniest corruption.

2)      Receive the file over again and retry the DECODE.  This will fix the problem if the garbling
occurred during the receive from the Electronic Mail system, but it won't help if the garbling
occurred during the send to the Electronic Mail system.

3)      Send the file over again, receive the file over again and retry the DECODE.
Using ENCIPHER to send confidential files
e.g.. ENCIPHER  C:\LETS\MYSTUFF.DOC  C:\SCOM\MYSTUFF.TEL
This means encipher file MYSTUFF.DOC on disk C: in subdirectory \LETS and create a file called
MYSTUFF.TEL on disk C: in subdirectory \SCOM placing an enciphering of MYSTUFF.DOC in it.
Never use the same name for both files.  ENCIPHER does not modify or destroy the original file
MYSTUFF.DOC.

The file C:\SCOM\MYSTUFF.TEL can then be sent using the standard electronic mail.  Don't send
MYSTUFF.DOC!!

Using DECIPHER to receive confidential files

e.g.. DECIPHER  C:\SCOM\MYSTUFF.TEL  C:\MAIL\MYSTUFF.DOC

This means decipher file MYSTUFF.TEL on disk C: in subdirectory \SCOM that has just arrived via
electronic mail and create a file called MYSTUFF.DOC on disk C: in subdirectory \MAIL placing the
deciphered original contents into it.
If the C:\MAIL\MYSTUFF.DOC is left out, the program will fill it in for you automatically with the
name of the original file on the sending system.  This name (C:\LETS\MYSTUFF.DOC) is embedded
in the MYSTUFF.TEL file that is sent.
Never use the same name for the two files.  DECIPHER does not modify or destroy the input file
MYSTUFF.TEL.

If DECIPHER Beeps and prints an error message that the transmission was garbled, you have three
choices:

1)      Use the file as is knowing that it is slightly corrupted.  Attempt this only with word processing
documents.  Any *.WKS spreadsheets, *.COM or *.EXE program files cannot be used even with
the tiniest corruption.

2)      Receive the file over again and retry the DECIPHER.  This will fix the problem if the garbling
occurred during the receive from the Electronic Mail system, but it won't help if the garbling
occurred during the send to the Electronic Mail system.

3)      Send the file over again, receive the file over again and retry the DECIPHER.
Using MAKEKEY to prepare a key to send top secret files

e.g.. MAKEKEY  C:\HIDE\MYKEY9.KEY

This creates a file of random numbers that can be used as a key for encrypting.  You will be prompted
to type anything you want.  You can just keep hitting the space bar if you like.  The program
measures the random time between keystrokes -- not the keystrokes themselves.  The randomness is
increased by taking only the low order 8 bits of the time between keystrokes measured in tens of
microseconds.

Hit Ctrl-Z when you have entered enough keystrokes.  What is enough?  In practice 80 would be
enough.  But if you want to ensure the code is totally theoretically uncrackable, hit more keystrokes
than the length of the file you plan to encrypt.
It is a boring task creating these random files.  I jokingly once said that the illegal drug industry
would be more interested in Encrypt than anyone else.  They would need to set up cottage industries
in Mexico to produce the necessary random key files;  hence the name "The Mexican Peasant"
algorithm.  In reality the main user is Greenpeace to help in protesting cruise missile testing.  In the
old days the military monitored Greenpeace's electronic mail and thus managed to sidestep
confrontation.

The key file must be sent to the recipient ahead of time.  It could be sent via Electronic mail, but for
complete security the key file should be sent via secure courier.  The key file can be re-used, but for
total security a fresh key file should be used for every message.  Copies of the key files must be kept
secure.  With copies of the key files the messages can easily be decoded.  It depends on the resources
of the codebreaker how careful you have to be.
For less secure systems, any file at all can be used as a key file as long as both the sender and
recipient have a copy of it, and no one else does.

Using ENCRYPT to send top secret files

e.g.. ENCRYPT  C:\HIDE\MYKEY9.KEY  C:\LETS\MYSEC.DOC  C:\SCOM\MYSEC.TEL
This means use the secret key file MYKEY9.KEY on disk C: in subdirectory \HIDE to encrypt
MYSEC.DOC on disk C: in subdirectory \LETS and create a file called MYSEC.TEL on disk C: in
subdirectory \SCOM placing the secure encryption of MYSEC.DOC in it.
Never use the same name for any of the three files.  ENCRYPT does not modify or destroy the original
file MYSEC.DOC.
The file C:\SCOM\MYSEC.TEL can then be sent using the standard electronic mail.  Don't send
MYSEC.DOC!!

Using DECRYPT to receive confidential files

e.g.. DECRYPT C:\HIDE\MYKEY9.KEY  C:\SCOM\MYSEC.TEL  C:\MAIL\MYSEC.DOC
This means use the secret key file MYKEY9.KEY on disk C: in subdirectory \HIDE to decrypt file
MYSEC.TEL on disk C: in subdirectory \SCOM that has just arrived via electronic mail and create a
file called MYSEC.DOC on disk C: in subdirectory \MAIL placing the decrypted original contents into
it.
If the C:\MAIL\MYSEC.DOC is left out, the program will fill it in for you automatically with the name
of the original file on the sending system.  This name (C:\LETS\MYSEC.DOC) is embedded in the
MYSEC.TEL file that is sent.
Never use the same name for any of the three files.  DECRYPT does not modify or destroy the input
file MYSEC.TEL.

If DECRYPT Beeps and prints an error message that the transmission was garbled, you have three
choices:

1)      Use the file as is knowing that it is slightly corrupted.  Attempt this only with word processing
documents.  Any *.WKS spreadsheets, *.COM or *.EXE program files cannot be used even with
the tiniest corruption.

2)      Receive the file over again and retry the DECRYPT.  This will fix the problem if the garbling
occurred during the receive from the Electronic Mail system, but it won't help if the garbling
occurred during the send to the Electronic Mail system.

3)      Send the file over again, receive the file over again and retry the DECRYPT.  The same key can
be used over again with no danger.
Equipment Required

The programs work on PC DOS or MS DOS 2.00,or later, in Win 3.0 or later, Win 95 or Win98
The programs will run on any MS-DOS computer e.g. IBM PC, IBM XT, IBM AT, Ericsson, Compaq,
Corona, Hewlett-Packard 110, Microcan, Dot etc.  If the computer cannot read 5 1/4" diskettes, the
programs must be copied to the non standard diskettes.  This can be done by connecting an IBM PC
and the other computer back to back with a serial link (or through the dial up network) and
transferring the programs using the XMODEM or KERMIT protocol.  CPM versions are also available
for the underprivileged.

The programs will run with monochrome, color or Hercules CRT controller cards.
The programs require only 15K of RAM (above what DOS uses) to run.
No printer or modem is required.

Installing The Programs

Installing need be done only once by someone who understands the DOS commands MD CD and
COPY.  From then on anyone can use the programs.

The *.COM files are the executable versions of the programs.  The *.PAS files are the source code
written in Turbo Pascal version 3.0.  This is an outdated version of Pascal.  You will have to make
minor changes to bring them up to snuff for the more recent versions.  The programs run quite slowly
compared with equivalents written in C or MASM.  The *.DOC files are standard DOS text files that
can be PRINTed.  The *.TXT files are Microsoft Word files.

You must make copies of the diskette, send them by courier, and then install the programs on all the
machines that will interchange files.  It is not possible to receive the programs themselves by
electronic mail without first having the DECODE program.

Presuming you use subdirectory \FASTSYS on the C: hard disk drive to keep your most commonly
used programs, and presuming the ENCODE diskette is your floppy drive A: type

COPY  A:*.COM  C:\FASTSYS
Presuming you have no hard disk and you have a diskette in the A: drive where your electronic mail
software is and presuming the ENCODE diskette is your floppy drive B: type

COPY  B:*.COM  A:
The file ENCODE.TXT containing this documentation can be massaged with the Microsoft Word
Processor.  You can modify this documentation for your own purposes or include it in your own
documentation.   The file ENCODE.DOC is a standard DOS text file with this documentation in it
which can be printed with the MS-DOS command

PRINT A:ENCODE.DOC
If your electronic mail system cannot handle lines 125 characters long (Envoy and Telenet can
handle up to 132 characters), then you can replace the programs with versions that produce lines
only 65 characters long by typing:

COPY  A:*.65  C:\FASTSYS\*.COM

or

COPY B:*.65  A:*.COM
If these versions have not been supplied they can be created by modifying the Pascal source and
recompiling.  Instructions are in the source code.
It is theoretically possible to install the programs on a remote machine without first sending a
diskette.  The source code for DECODE can be sent using standard electronic mail.  At the remote
site the code can be compiled using the Turbo Pascal compiler version 3.  Then the rest of the files
can be sent via ENCODE / DECODE.

Notes For SourceMail Users

SourceMail (the electronic mail system offered by The Source) inserts -MORE- prompts into the
messages as they are received.  These look to DECODE like part of the file (it is not very bright -- for
all it knows you are writing a document about MCI mail (like the document you are reading now) and
-MORE- truly is part of the file).  To get around this you must type NOCRT after the first -MORE-
prompt appears (immediately following the subject line of your mail) to turn the -MORE- prompts off.

Technical Details

This information is important only to people planning to modify the programs.
Electronic mail systems cannot be trusted to pass control characters (Tab Cr Lf FF etc) or characters
with the high bit on (accented characters).  In addition they sometimes trim trailing blanks from
lines, or append them.  It is very inefficient to send short lines to an electronic mail system as each
line usually forms a full packet even if it consists of a single Cr.  The file transfer programs often in-
sert additional printable characters before and after the file itself because the computer operator
must manually decide when to start and stop capturing characters from the communications line to
disk.

The brute force approach to solving this problem is to encode files in hexadecimal before
transmission using only the safe characters 0..9 A..F, inserting Cr-Lf sequences every 65 characters.
The problem with this is that a word processing file is exactly twice as long as if it were sent plain.
This means it costs twice as much to send

The electronic mail system can be trusted only to handle the ASCII characters chr$(33..126) vis. A..Z
a..z 0..9 or punctuation but not space.  Our approach roughly is this, if the character is already safe
send it unmodified.  If it is a control character chr$(1..31) we send it as two safe characters ^A ^B
^chr$(c+64) etc.  If it is a control character with the high bit on i.e. chr$(128..159) it is encoded as
the pair 'A 'B 'chr$(c-64) etc.  If it is a regular character with a high bit on i.e. chr$(161..254) we
encode it as the pair `A `B `chr$(c-128) etc.
This means we have stolen some of the punctuation characters for use as indicators.  How then do
we send a real ^ ' or ` and not have it taken as an indicator?  We steal yet another character the ! as
literal next character so that ^ is coded as the pair !^ ' as !' etc.  What about ! itself?  It is coded as !!.
In addition we note that text files often contain the string CrLf.  This would be encoded as a 4-
character sequence ^M^J.  This occurs so often we use a single character abbreviation ; for it.
In addition text files often contain long strings of spaces or zeros and binary files contain long strings
of nulls and hex FFs.  For example, if a file contained 5 spaces in a row we compress the file by
sending two characters -- one indicating repeating spaces the > and another indicating the fact there
were five of them -- the # (chr$(count+30)).

This scheme does not do that great a job compressing a single space or a pair of spaces.  So we code
a single space as an & and a pair of spaces as a <.
In a similar way 0's are encoded with 0 { and }.  Nulls chr$(0) are encoded with \ ~ #, and hex FFs
(binary -1) Chr$(255) are encoded with % [ ].
This leaves three characters falling between the cracks chr$(127) which is encoded as the pair ^` and
chr$(160) which is encoded as the pair ^a and the period chr$(46) which is encoded as the pair ^b.
Earlier versions did not encode the period in any special way.  This new feature was added to bypass
a bug in the Envoy NIO electronic mail system that sometimes gets confused by lines that contain a
period as the first non-blank character.
For a simple word processing document, the encoded form is even shorter than the original
document.  Even in the worst possible case the encoded document is never more than twice as long
as the original.

We then insert CrLfs every 125 characters.  This breaks the document into efficient long lines for
sending.  For maximum efficiency each line should exactly fill one packet.  Different Electronic mail
systems have different optimum line sizes, so this size can be modified in the source code of
ENCODE, ENCIPHER and ENCRYPT.  DECODE, DECIPHER, and DECRYPT work with any line length.
Find out the maximum length of a line that your Electronic mail system can send.  It will be 65, 80,
127, 132 or 255.  Find this out by experimenting.  If you do not want to bother, presume 65.  For
Envoy it is 132.  However the packets sent via the Telenet / Envoy gateway are 128 characters long.
To allow for the CrLf and the space and the space at the head of the line, the optimal size of line is
125 characters.  If 125 is not suitable, modify the source code and recompile or use the *.65 versions.
The output is preceded by the letters ^c3ENCODE ^c3ENCIPHER or ^c3ENCRYPT to indicate the
version and type.  Previous versions failed to carry the version number and horrible confusion
reigned when people tried to ENCODE with version 2 and then DECODE the file with version 1.
Following that is the filename from which the file was encoded.  Following that is a ^c.  Then comes
the encoded file.  Then come the two characters ^c to mark the end of the body of the file.  Then
comes the 4 digit checksum.  Then comes another ^c.
Every line except the first starts with a blank.  This ensures that no line of data will accidentally be
interpreted as a command to the electronic mail system.  Envoy and Telemail for example treat any
lines starting with a dot as a command.
The checksum includes the words ENCODE, the file name, and most of the ^c's.  The checksum does
not include the CrLfs, the first ^c or the checksum itself or the ^c after the checksum.  The
checksum is computed by adding the codes of all the characters in the output file as a 16 bit binary
number ignoring overflow.  The checksum consists of the 4 low order decimal digits of this sum,
padding with zeros if necessary.

Encipher uses a very simple algorithm to encode the file.  It simply converts each character with
chr$(159-c) after encoding in the standard way.  A more complex algorithm would end up turning the
safe characters into unsafe ones and would thus require double the transmission time.  The
algorithm is designed to keep the casual reader out.  Anyone with a copy of Decrypt or who is good at
cryptograms can easily break the code.

Encrypt uses the only truly secure way of sending encrypted files.  It is cumbersome but perfectly
secure.  I thought I'd invented it myself, as have many other computer science students.  It turns out
Gilbert Vernam first used it in 1917 with paper tape.  In World War II, the Germans used this
technique with Lorenz machines.  My version is a high-tech variant.
You must first prepare a key file of random numbers -- for example the times between keystrokes
accurate to the microsecond while you type the Gettysburg address (created by Makekey).  This file of
random numbers must be sent ahead of time by secure courier to the recipient.  It must NOT be sent
electronically unless you wish to take the risk of the key being intercepted.  Then the message to be
sent is exclusive ORed with the key file of random numbers.  That message is then sent using the
usual encode mechanism.  At the receiving end the message is first decoded in the usual way then it
is again exclusive ORed with the key file of random numbers, which reconstructs the message.
For a theoretically uncrackable system, the file of random numbers can only be used once and it
must be at least as long as the message.  In practice even the CIA could not crack the code if the key
file were up to 3 times shorter than the message file.  However they could crack the code if the key
file were used more than a few times.

Copyright

The programs ENCODE, DECODE, ENCIPHER, DECIPHER, ENCRYPT, DECRYPT and MAKEKEY are
written in Turbo Pascal version 3.0.  The programs, in both source and object form, and the
documentation are copyrighted but may be used, copied, sold or modified without restriction or
credit.  You may use them for any purpose except military.

Version History

Version 1.0 was written in DOS 1.1 C by Steve Cross with coaching from Roedy Green.

Version 1.4 added a CrLf to the last line of an Encoded file to make it easier to use Procomm.

Version 2.0 added special coding for the period to bypass bugs in Envoy NIO electronic mail.  It also
added version messages.  It is not compatible with earlier versions.  To send the new versions to the
field, you must encode/decode with the old versions.

Version 3.0 added the version number to the file so that if different versions of ENCODE and
DECODE are used, the problem will be detected.

Version 3.1 recorded the new mailing and email address.  It also added polemic.
Future
Encrypt as it stands makes binary files bulkier.  If your datacommunications channel can handle
binary files (e.g. Internet FTP, MIME or Binxhex) and has built-in integrity, I could write a
streamlined assembler version of ENCRYPT that PkZips (compresses thefile), then applies the XOR
scrambling.  This would produce compact files, much smaller than the original, but still 100%
secure.  It would also run at least five times faster.  If you want such a program, I would be prepared
to write it for $500 US and give you a copy including the MASM source code.
For $10000 I will write you a much more modern version that uses writeable CD-ROMs to distribute
keys and build you the hardware to create the random key files using a small radioactive source or
FM radio white noise.  It would encapsulate encoded messages with MIME.

Please pass any comments or suggestions for improvement to:
Roedy Green
Canadian Mind Products
5017 Barker Avenue
Burnaby, BC
Canada  V5H 2N6
(604) 435-3016
mailto:roedy@mindprod.com
http://mindprod.com

P.S. A cheque to help support the writing of more free software would be appreciated too.


