\chapter{Introduction}

\begin{quote}
\begin{description}
\item[{\Large Nox}] \large --- the Goddess of the Night, who knows all
secrets and keeps most of them.
\end{description}
\end{quote}

The original idea for the encryption server came out of a discussion
which I had with Mark Eichin on Sunday, February 18, 1990.  The problem
which we were originally trying to solve involved ``super-secure discuss
meetings.''  Discuss\cite{discuss} is an electronic conferencing system,
modeled after Multics' forum subsystem.  Discuss has several private
meetings, which contain transactions with personal information and to
which access should be restricted which the
participants would like to keep private.  While discuss does use a
relatively flexible and powerful authorization system to mediate access
to individual discuss meetings, thus preventing unauthorized users from
reading the discuss meeting, it is still vulnerable to people who have
privileged or physical access to the discuss server. 

One solution would be to physically secure the discuss server and
restrict physical and logical access to it.  Unfortunately, there are a
large number of discuss servers located across the campus; while it
might be possible to place all of the sensitive discuss meetings on a
secured machine, maintainence of this machine becomes difficult, since
only a few people could have access to create, delete, and expunge
meetings.  In the current model, anyone with a system and disk space
could set up a discuss server create his or her own meetings.  It seems
awkward that the only way to have a really secure meeting is to use the
disk space of a centrally administered machine.  Furthermore, standard
problems such as ``how will the server be backed up?'' and ``where
will the backup tapes be stored?''  arise.

The above problems can be solved by encrypting the data before sending
it to the discuss server.  Since the data which is stored by the discuss
server would be encrypted, merely having physical access would not be
enough to compromise the contents of the meeting.  In this scheme, all
users would know the encryption key for each particular private meeting
to which they have access, and each user would have to supply the
encryption key to the discuss client before he or she could read or post
transactions to the meeting.  However, each user has to either memorize
the key, which would be bad since a user might be tempted to write it
down, or the discuss client would have to retrieve the key from a file
in a user's directory, which would be insecure since the an intruder
might be able to breach the security of the file.  An additional problem
with requiring either the discuss client or the discuss user to know the
encryption key is that the only way to revoke a user's access to the
discuss meeting would be to to re-encrypt all the transactions in the
discuss meeting in a new encryption key, and to distribute the new key
to all of the participants of the meeting except for the user whose
access is to be revoked.  This is both difficult and clumsy.  Finally,
there is nothing to prevent a user who knows the encryption key from
sharing with an unauthorized user.

Thus, the idea of an encryption server was devised whose would keep the
key and whose job was to encrypt and decrypt data for the user.  Users
would authenticate themselves using Kerberos\cite{Kerberos}, and if they
were on the proper access control list, the server would encrypt and
decrypt data for them.  Of course, the encryption server would have to
be kept in a secure location --- ideally, just as secure as the Kerberos
servers.  However, since the encryption server doesn't need to store any
bulk data, one or two such servers could easily provide encryption
service for a large network community.  In addition, the users of the
private discuss meeting need to trust the administrators of the Nox
server; however, at least in an environment which uses Kerberos, users
must trust the administrators of the Kerberos service anyway; thus, Nox
may not require much (if any) trust assumptions.

Nox has evolved further into a service that could be used to do many
interesting things, by virtue of having a private keys which are known
only by the server.  This allows the creation of data which is useful
only to the encryption server.  Because of this fact, it is possible to
implement almost any semantics that are desired.  This flexibility has
been extremely important in Nox's design.
