Gavin and Cindy Scott were kind enough to come and spend this last weekend
with us and discuss various methodologies to put encryption into QCTerm. I
feel relatively certain that we exhausted all of the options and have decided
on a path of least resistance, quickest implementation, and lowest cost.

Four options were given serious consideration:

    o VPN router to VPN router
    o Microsoft Windows-resident VPN code to NT-box front-end
         to target HP3000
    o Microsoft Windows-resident VPN code to HP3000-resident
         VPN code
    o QCTerm (or similar application) encryption to HP3000-
         resident application decrypting code

The first method can be done now. VPN routers are commercially available and
not particularly expensive. However, this methodology was rejected. The
encryption exists only for the duration of travel on the internet, not within
the local organization's LAN. If a sniffer was to be most likely placed
anywhere and benefit someone the most, it would be internally, at one end or
the other. Moreover, this methodology is only truly useful from fixed office
to fixed office, not from anyone telneting in, in the manner that people do
now from web browsers.

The second method is the one that we chose as most reasonable. VPN software
has been in every version of Windows since 95 and is readily callable by any
32-bit application. By placing a corresponding NT-box (and thus
100%-compatible) just in front of the HP3000, decryption/encryption & key
exchange can be accomplished with (i) no modification of MPE and (ii) without
the plaintext being placed on any significant part of the internal LAN at the
HP3000's end -- and none at the user's end.

It also has the salutary advantage of being "instantaneous", instantaneous
being defined as requiring no modification to the MPE O/S, a process that
takes at least two years to get into the hands of users, if done extremely
expediously, and if the decisions on what to do were completely settled and
well thought out right now.

Indeed, that reason alone is why the third option was rejected, that and the
fact that all of this is not nearly settled enough. The IETF has just revised
the draft standards again for telnet-based encryption this last month. IF
these standards ever come to fruition, then they are what clearly should be
implemented in both the telnet client and server routines. Encryption is not
an applications layer process. Rather it properly lies somewhere in the
presentation or session layers, halfway between the applications and
transport layers.

The fourth method was rejected for a number of reasons: (i) encryption was
being put at the wrong layer, (ii) it did nothing for MPE password
protection, and (iii) although we would have total control at this level,
whatever was done now would very likely appear "strange" and non-standard in
just a very few years. Encryption is a critical problem and it is inevitable
that it will be solved. In these sorts of situations, it is important not to
get too far out ahead of the most likely eventual global solution. In that
regard also, the second method is the most flexible.

However, having said all of this, all of this discussion was merely a
transparent excuse to drive up to the Very Large Array in Socorro, New Mexico
(where they filmed the movie, "Contact") and later listen that evening to a
public SETI lecture by Frank Drake, who is famous for the "Drake Equation." I
put up just a very few of the pictures that were taken while we were out at
the VLA. They're at:

            http://aics-research.com/vla.html

For those of you who haven't yet met Gavin, this is at least a chance to see
what he looks like.

Wirt Atmar