Choose your poison

[PAUL LOGSTON <PLOGSTON@usagroup.com>]

There seems to be some (actually, a lot of) doubt as to whether or not
PGP will come through with the product that we were planning to buy. 
And, even if they do come through, do we really want to continue to
subscribe to the "PGP Heartbreak of the Month"?  In light of these
problems, I've wracked my tiny brain and come up with the following
alternatives.  BTW, I don't pretend that I've thought of every possibility,
but this is what I have now.  If nothing else, it will give us something to
discuss on Monday.

_Use PGP's 32-bit Products_

I've done a very quick test, and believe that I can call a 32-bit ActiveX
server from a 16-bit program.  So, we could write encryption servers in
32-bit development environments that called PGP's 32-bit SDK, but still
provided services to 16-bit programs.  This is actually a pretty attractive
option, since it gets us into the supported realm at PGP, gets us to the
algorithm that PGP obviously prefers, and moves us a little bit closer to
going 32-bit.  However, the downside is that it is a substantial
development project to actually make a usable server and it does require
a 32-bit operating system (Windows 95, 98 or NT) at the client's site.

_Use the Freeware PGP_

This is an attractive option, since the freeware DOS PGP is available just
about everywhere.  However, calling a DOS program to do our encryption
is aesthetically unpleasing and difficult to control programmatically.  Also,
I feel that we would be violating the freeware PGP license agreement by
using it for commercial purposes.  

_Run Naked Through the Internet_

In short, don't encrypt.  This has the advantage of separating us all of
the encryption vendors.  However, we do run into privacy concerns, since
schools are required to protect this data to some extent and we can't
guarantee the safety of the data as it moves from server to server.  

_Run Naked Through CompuServe_

Another alternative is to use POP3 mailboxes without encryption, but
specify that we only use CompuServe as an ISP.  This might be a little
more safe than using the Internet, especially if we can get information
from CompuServe about the routing of their e-mail data, but still ties us
to CompuServe.  At least POP3 seems to be the strategic mail platform
for them.  We would need to find out who owns these POP3 mailboxes:
CompuServe/Worldcom or AOL.  This solution might be the best yet, since
it would preserve much of the group's work and most of our current
clients are on the CompuServe network already.

_Use Symmetric Encryption_

There are several symmetric encryption algorithms that we could use
outside of PGP.  This would provide some protection for the data.  There
are a couple of permutations of this idea, the first being to establish one
key for the entire network and simply use this to invisibly encrypt the
data.  The bad part of that idea comes if the key is ever compromised --
it would be nearly impossible to update the key through all of the
network.  The second version of this idea is for each participant to create
their own key, which would be stored in a database of keys at each
participants site.  There would still be a key exchange between
participants, and if one key became compromised, then only that
participant's key would have to be changed and resubmitted.  A downside
to both of these symmetric key options is that symmetric key encryption
doesn't support digital signatures, but this isn't a very big problem.

_Move the CommonLine Network to an FTP Solution_

This is an attractive option, since the protection issues for FTP aren't as
big and most people can do FTP in some fashion.  For encryption, we can
use SSL (Secure Sockets Layer) when we connect to the service
provider's FTP server.  However, getting everyone's FTP site setup in a
compatible manner would be a nearly impossible task.  Also, this idea
pretty much nukes all of the work that we've done so far, since the
e-mail related issues are much different than those for FTP.

_My Pick_
It's hard to pick one of these, since they all have problems and <gasp>
require me to do work!  However, I think I prefer either running
CompuServe POP3 mailboxes with no encryption or trying to use the
32-bit SDK.  The other options just strike me as having too many
problems and issues to be viable in the short term.