From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 16-OCT-1990 19:34:35.64
To:	MRGATE::"ARISIA::EVERHART"
CC:	
Subj:	Re: request for crypt software for vms

Received:  by crdgw1.ge.com (5.57/GE 1.75)
	 id AA06132; Tue, 16 Oct 90 19:17:45 EDT
Received: From CRDGW1.GE.COM by CRVAX.SRI.COM with TCP; Tue, 16 OCT 90 06:05:46 PDT
Received:  by crdgw1.ge.com (5.57/GE 1.75)
	 id AA25029; Tue, 16 Oct 90 09:01:01 EDT
Message-Id:  <9010161301.AA25029@crdgw1.ge.com>
Date: 16 Oct 90 08:54 EST
From: EVERHART%ARISIA.DECNET@crdgw1
Subject: Re: request for crypt software for vms
To: info-vax@sri.com

Re the request for info on encryption software for VMS...
  We used the Bear Systems virtual disks for some time, and now use
my drivers. Bear's drivers support driver-based ACLs over and above those
of VMS, and the nifty option to hang a process that violates security
access so that you can examine at your leisure what was being attempted,
as well as logging all failed access attempts. My drivers don't have
that, but FDDRV has several cryptodisk "host processes", which do a
fairly decent job of garbling text into rubbish and restoring it to
sense. It can be found on VAX SIG tapes and a few FTP sites; I recently
sent my latest & greatest to Ehud Gavron's site (sunquest.com) where it
is available for FTP. 
   I tend to favor cryptodisks rather than encryption programs, which
abound in the public domain, because my experience is that the data which
needs to be secured is often administered by people not computer
literate enough to reliably use crypt/decrypt commands every time, and by
software to which hooks cannot readily be added to handle encrypted data
correctly. A driver that encrypts its contents automatically encrypts all
data stored there and allows a system manager to provide reasonable
security without a lot of hassles. A simple command file to mount the
cryptodisk unit and get the crypto key lets the data owner do the mount
himself (If something sensitive enough to need a cryptodisk is on my
machine, *I* don't want to be on the access list for it and thus
chargeable with responsibility for leaks) and by having the drive
controlled by a subprocess, logout automatically gets the system to
forget the key. Neat stuff, and software needs NO hooks to handle
encrypted data. My driver's algorithm is fast and imposes no excessive
burden. (An earlier driver I did for IAS back around 1978 used an
algorithm similar to DES which DID eat a marvelous amount of CPU time
while running. That's why I tend to believe software DES is likely to be
a bad idea for cryptodisks. Of course, the sources of my driver are such
that adding DES encryption would be fairly easy, instead of or in
addition to the existing algorithm; being public domain has its
advantages. Incidentally, the Bear drivers do not use DES either.)

   If you want to encrypt data and don't happen to have a crypt tool
around, a compression tool that's one-pass will do nicely. The key is
that the compress tool must be one-pass, so the output depends only on
what went into it before the point of output, not on a global file. Thus,
Huffman compressors will not work this way; LZW compressors (like
compresss) will.
   Also, you should see that the compressor does not reset itself during
the compress if possible; such a reset may allow decipherment of the
data.
   The method is simple: Take a file you and your recipient have. Let's
say it's 5 blocks long and compresses to a file 3 blocks long. (Ensure
you're working with stream files or fixed files here; VMS variable record
streams can introduce complexities.)
   Now take the file you want to encipher. Tack the keyfile in front of
it so you have now a file like this:
  <---keyfile><---file to send crypted--->

   Now compress this file. This gives something like
  <-ckey-><-ccryptfile->
  where ckey is compressed key, and ccryptfile is compressed file you're
sending. The ccryptfile consists of strings of tokens of variable numbers
of bits which correspond to text strings largely depending on the
contents of keyfile.
   Now chop off most of ckey. In the example mentioned, you know ckey is
3 blocks long, so chop off the first 2.2 blocks, let's say. Your
recipient needs to know how many bytes you chopped off as well as having
the keyfile, unless he wants to do some heavy pattern matching to find
the point himself. If you succeed in chopping off all of ckey, of course,
this is not essential.
   You now send the truncated compressed file to your recipient:
  -><-ccryptfile->
  where "->" is meant to mean that part of ckey may be there.

   The recipient now compresses keyfile and where you chopped off and
threw out n bytes, HE saves exactly n bytes of his ckey, prepends it
to the file you sent him, decompresses, and throws out the uncompressed
keyfile. Voila! Now he has the file in the clear, and someone lacking the
keyfile will have a hard time duplicating the decode. Much of this can be
wrapped in command procedures. I consider this an interesting proof that
encryption can be a side effect of many types of operations as well as a
possibly useful technique.

   It would be interesting to hear from folks using the algorithms of
LHARC to see whether this technique would work with them also. Obviously
by compressing, this technique reduces the amount of material that must
be sent as well as hiding its contents, and may have advantages over
cryptors that don't compress. The cryptographic strength of this sort of
thing is unclear, though by reducing the redundancy in the information,
compression has got to make decrypting data harder.

   The foregoing techniques are of course public domain also. Enjoy.
Glenn Everhart
Everhart@Arisia.dnet.ge.com