Comms Corner 10 - originally published in the May 1996 issue of PCW Plus.

Last month, we looked at the plethora of file compression formats in use today. This month, we're going to investigate the related topic of file encryption. To clarify the distinction: compression is used to reduce the amount of space consumed by a file, whilst encryption is utilised to make files illegible or transmissible.

When sending and receiving binary files (such as programs, LocoScript documents or DTP files) by e-mail, you'll need a way of encrypting and decrypting the files so that they can be transferred intact by the Internet, whose e-mail specification only guarantees the integrity of 7 bit data rather than the more usual 8. What this means is that characters with a higher ASCII value than 127 will be mutilated in transmission, usually by having the most significant bit lopped off. If you've ever received foreign language e-mail and detected strange characters where accented letters should have appeared, or found numbers where you suspect a pound sign should have graced the page, this is the reason. As strange as it now seems, when the Internet mail system was conceived, the idea that people might want to send more than plain ASCII text to each other just didn't occur to anyone.

Why might you want to send binary files? Well, for one thing, there's only so much you can do with the ASCII character set. If, for example, I want all the formatting codes (bold, italics, etc.) in this article to be preserved, then I need to encrypt it before mailing it to Genghis, er... the editor. This has the advantage of the person at the other end being able to view the document as it was intended, and saves me from having to convert it to ASCII format.

The most universal method of getting around this obstacle is by using UUENCODE and UUDECODE, which we first encountered back in the article on FTP-mail. There are several versions of these two programs available under CP/M, so I'll list only the best (which were coincidentally both written by PCWers!).

Stephen Younger's single program will decode and encode both UU and XX encryption formats, effectively combining four utilities in one (although in practice, XX coding is rarely encountered). John Elliott provides separate utilities for encryption and decryption, although these also handle both UU and XX coding and feature some additional options. Both Stephen Younger and John Elliott's programs come with documentation and are as easy to use as DISCKIT.

UU encoding is much more ubiquitous than BTOA encryption, but produces slightly larger files. BTOAed files are 10% smaller and include error checking, which ensures that a file corrupted in transit is always detected at decode time. For this reason, use BTOA if you know that your friend has a copy of its complement, ATOB. If not, you can always UUENCODE him a copy and use that subsequently.

What do you do if your friend has no decryption utilities at all? Post him a disc with UUDECODE or ATOB on it? You could do, but there's still a way of supplying him with the necessary decryption software electronically. You can ask your friend to send the FTP-mail request published in the December 1995 issue of PCW Plus, which will reward him with a copy of UUDEC.HEX (if you're extremely helpful, you could even send the request on his behalf and include his e-mail address in a line beginning with the word reply - the file will then be sent to him without his having to lift a finger).

The program required to reinstate the UUDEC.HEX file can conveniently be found on your friend's CP/M master disc under the moniker HEXCOM.COM. Once UUDEC has been restored to its former glory, your friend can then use it to decode any further files you wish to send him. (The .HEX format itself is used only as a last resort for sending files, since a file encoded using this format is much larger than the original.)

Another thing you need to know is that encoded files can't be decoded immediately upon receipt. When a file is mailed, various lines of information are added to it, such as the sender's name and e-mail address, plus the names of any computers it passes through on the way to its final destination. These are collectively called the message header. Before you can successfully decode an encrypted file, you need to weed out this junk using your favourite word-processor.

You'll also need to remove any signatures attached to the message. It's traditional for e-mail messages to carry an automatically appended signature bearing the personal details of the sender, plus a humorous quote or slogan of some kind. Many BBSes also exhibit the annoying behaviour of attaching a signature of their own to outgoing mail, perhaps bearing the name of the software used to send it. Needless to say, this text also has to be chopped to avoid confusing the decoder software.

Another thing to watch out for is sending and receiving very large encoded files. Some BBSes will cut large files into a series of smaller ones and post each of them separately. Some less friendly systems adopt the truncate and destroy approach, discarding all but the first segment. Many Internet e-mail gateways will also run into difficulties with files larger than 64 Kb. If you receive a multipartite message, you need to remove all the individual headers and signatures in a gargantuan cut-and-paste frenzy and restore the coded portions to a single file. I suggest that you don't use LocoScript for this, since whatever benefits this fine program has, speed isn't one of them.

Note that FidoNet users aren't allowed to send or receive any form of encrypted mail: it goes against the open principles of the network. If you're a FidoNet user and want to be able to send and receive encrypted files, you're going to have to take your business elsewhere.

For the sake of completeness, I should mention one more CP/M encryption utility. For encoding and decoding messages that might conceivably cause offence, there's also:

This utility simply rotates the letters of the alphabet through 13 positions, so that the A becomes an N, the B an O, the C a P, etc. This means that running the program once will encrypt a message, whilst running it a second time will restore it to legible text. ROT13 used to be quite common on the Internet, but is seldom if ever seen nowadays. No-one worries about causing offence any more!

In recent months, you might have heard mention of a program called PGP. PGP stands for Pretty Good Privacy and is a surprisingly powerful encryption tool for preventing prying eyes from reading the contents of your e-mail. The encryption used is so strong that in America, the program is governed by the munitions laws and export of it is illegal. This even includes downloading it from abroad by FTP!

The governments of many countries even went so far as trying to outlaw it, a move which gained widespread condemnation from the Internet community, even though the governments concerned claimed they only wanted to ban the program because it would make criminal activity untraceable. The sad news is that no version exists for CP/M, but if you have Unix shell access, you should be able to use the PGP software on your provider's computer.

Other encryption formats in use today are SHIP, BinHex and MIME. SHIP is relatively uncommon and BinHex is used almost exclusively in the Apple world, but MIME (Multipurpose Internet Mail Extensions) is fast on the way to becoming the new standard for mail encryption and is very popular on other platforms. Once again, I'm afraid no CP/M software exists for manipulating these formats. (Update! There is now a MIME decoder for CP/M.)

As usual, all software discussed in this article can be obtained from PCW-PD or the familiar Internet CP/M archives.

Next month, we take a look at linking the PCW to its wayward sibling, the PC.