\documentstyle{report}
\setlength{\oddsidemargin}{0in}
\setlength{\evensidemargin}{0in}
\setlength{\topmargin}{-2pc}
\setlength{\headheight}{1pc}
\setlength{\headsep}{2pc}
\setlength{\textwidth}{6.5in}
\setlength{\textheight}{8.5in}
\setlength{\parskip}{.1in}
\setcounter{tocdepth}{3}

%% Syntax \PSbox{postscript filename}{width}{height}
\newcommand{\PSbox}[3]{\mbox{\rule{0in}{#3}\special{psfile=#1}\hspace{#2}}}
\newcommand{\TedsName}{\PSbox{/mit/tytso/tex-macros/myname.PS}{1.7in}{0.25in}}

\title{{\Large A Summary of an Undergraduate Thesis \\}}
\author{Theodore Ts'o}
\date{\today}

\begin{document}
\bibliographystyle{ieeetr}
\maketitle

\begin{abstract}

\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}

This is a summary of work done to date on Nox, a private-key encryption
server.  First, we will discuss the current design of Nox.  Secondly, we
will discuss its security and ways to reason about its security.
Finally, we will discuss possible extensions to Nox, including multiple
servers in a single realm, and mutli-realm operation.
\end{abstract}


\chapter{Introduction}

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
users can read and write {\em transactions} to {\em meetings}.  Thanks
to Discuss's authentication and authorization features, one of its uses
which have developed are private meetings, where the participants are
restricted to a small group of people, who are the only people who can
read or enter transactions in that meeting.  Some of these private
meetings contain personal information which the participants would like
to keep private.  While discuss does use a relatively strong
Authentication system, the contents of the discuss meeting are
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 sensistive 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 do will the server be backed up?'' and ``where
will the backup tapes be stored?''  arise.

The obvious solution which solves the above problems is to encrypt the
data before sending it to the discuss server, but with what key?  The
discuss client could do the encryption and decryption, but then the user
would have to store key somewhere secure, which is itself somewhat
problematical, and it becomes impossible to revoke access later on,
since the user could always keep a copy of the key.

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
data, one or two such servers could easily provide encryption service
for a large network community.

This idea 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.

\chapter{The Basic Mechanism}

Nox maintains ``encryption compartments,'' which basically consist of an
access control list and a key used for encrypting and decrypting user
data.  When a client wishes to encrypt some data, it first opens a
connection to encryption server, and authenticates itself to Nox.
During this process, it obtains a session key to use for the connection.

The client then sends (encrypted in the session key) the name of the
compartment which it wishes to use along with the data to be encrypted
to the encryption server.  If the user is on the ACL, Nox will encrypt
the message along with other identifying information (who made the
encryption request and when), and send it back in a {\em satchel}.

The satchel can be later be presented to Nox, and if the user presenting
satchel is authorized to decrypt it, Nox will send back the decrypted
data, encrypted in the connection's session key.

The compartments are named hierarchically, using {\em compartment
containers}.  Functioning as directory in a hierarchical file system,
each compartment container may hold an arbitrary number of named
compartments or sub-containers.  Because of the hierarchical arrangement
of compartments, it is possible to give a user or group of users control
of a portion of the hierarchy without giving them privileges in other
parts of the hierarchy.

\section{Conceptual Objects In Nox}

\subsection{Description of an Satchel}

An satchel consists of the following:

\begin{itemize}
\item A structure tag and version number.

\item The (domain) name of the encryption server which created this
satchel.  These servers may be replicated, so this will probably have to 
be either the name of the master server or the domain name of the
servers, if we're willing to live with the assumption that a domain will
have only one server.

\item Sealed in the encryption server's private key:  

\begin{itemize}

\item The name of the compartment.

\item The key version number used to encrypt the message data.

\item Sealed in the compartment's key (which has been named above):

\begin{itemize}
\item The user who created this satchel.

\item A time stamp identifying when it was created.

\item An optional ACL, which if present, overrides the compartment's ACL.
\end{itemize}

\item The data, sealed in compartment's key.  This is encrypted
separately from the status information above so that the encryption
server doesn't have to decrypt everything (including the data) just to
read out the user or the time stamp. 

\end{itemize}
\end{itemize}


\subsection{Description of an encryption compartment}

An encryption compartment consists of the following elements:

\begin{itemize}
\item A list of keys, stored as a triple: (key, version number,
encryption system).  The latest key version is always used for
encryption; older keys are stored for the purposes of decrypting older
encrypted packets.

\item A description of what the compartment is to be used for.  (Max:
256 characters)

\item An access control list.  Since access control privileges are
relatively cheap (one bit per privilege), the privileges are relatively
fined-grained, with the following privileges being supported:

\begin{itemize}
\item Administrate --- this allows the user to add/delete/modify entries
on the compartment's ACL.

\item Encrypt --- this allows the user to encrypt messages using the
compartment's key.

\item Examine --- given an satchel encrypted using this
compartment, this allows the user to obtain the name of the compartment
and the accompanying status information.  time stamp, optional ACL, et. al)

\item Decrypt --- given an satchel encrypted using this
compartment, this allows the user to obtain the decrypted message data.
(The user must also either know the name of the compartment or have
Identify access.)

\item New Key --- this allows the user to request that a new key be
generated for this compartment.  Older keys are remembered so that
packets encrypted using them can still be decrypted.

\item Status --- this allows the user to list the members of the ACL and
to display the last time the compartment was changed and by whom.

\item Build-in ACL --- this allows the user to encrypt a message with a
built-in ACL which is stored within the satchel and which
overrides the compartment's ACL.
\end{itemize}

\end{itemize}

\subsection{Description of an ``Compartment Container''}

A compartment is may contain any number of named compartments or
sub-containers.   The compartment or sub-container is named using an
string, which is at must 255 characters long.  The name may not contain
a '$>$', since that is used to delimit container names.

Each container has a quota which represents the maximum number of new
compartments which can be created in the container.  The quota
can be disabled by setting it to -1.  If it is enabled, then each time
a compartment is created, the quota is decremented by one.  If the quota
is equal to zero, then no further compartments can be created in the
container.  When a new sub-container is created, if the parent container
had quotas enabled, then the user must specify a quota for the new
sub-container as well, which will be deducted from the parent container.
Naturally, during this the quota of the parent container must remain
greater than zero or Nox will not allow the sub-container to be created.
If the parent container has no quotas enabled, then the sub-container
may either have no quota or any user-specified quota without any
restrictions.

The compartment container has an ACL with the following privilege
levels:

\begin{itemize}
\item Administrate --- this allows the user to add/delete/modify entries
on the container's ACL.

\item List --- this allows the users to list all containers and
compartments in this container.

\item Sub-container access --- this allows the user to create/delete
any sub-container.  This also allows the user to modify the quota of
sub-container (subject to the constraints of this container's quota).

\item Create --- this allows the user to create a new compartment in
this container.

\item Delete --- this allows the user to delete a compartment in this
container. 

\item Manage --- this allows the user to enable or disable a
compartment in this container.  (This also allows the user to force a new
key to be generated for the compartment --- do we need this?  Yes, if
the administrator discovers a breach, and wants to force a new key to be
generated without needing to notify the compartment administrator.)

\item God --- This privilege allows the user to modify the ACL for any
compartment or sub-container.  This is extremely powerful, since
someone with this privilege will be able to read any satchel
just by forcing themselves onto the compartment's ACL.  This privilege
level may only be set by a user who has both the Administrate and God
privileges.

\end{itemize}

\chapter{Discussion of the security of Nox}

The security of Nox is based on the following assumptions:

\begin{itemize}
\item Kerberos is secure.  (Discussed in \cite{Burrows}, modulo a secure
time source)

\item All of the Nox servers are physically secure.

\item Only the Nox server knows the keys with which satchels
are encrypted.

\item The encryption system used by Nox (presumably DES in the
reference implementation), is secure.
\end{itemize}

Suppose client A wants to encrypt message X.  It authenticates itself to
the encryption server using Kerberos, proving to Nox that A's identity
and obtaining a session key $K_{an}$ which can be used to securely
exchange data between the Nox server and client A.  Client A sends to
Nox $\{X\}_{K_{an}}$.  Since $K_{an}$ is a secure session key provided
by Kerberos, X is protected from exposure while it is being transported
to Nox.  Nox then decrypts $\{X\}_{K_{an}}$, and immediately re-encrypts
in the compartment key ($K_C$), and sends it back to client A.  

Once A receives the satchel from Nox, the data is encrypted such that it
is unintelligible to everyone but Nox.  Thus, the data is completely
secure up to this point.  A can now freely send the satchel across the
network, and even post it to a public bulletin board, secure in the
knowledge that Nox will only decrypt it for someone who has proven
themselves to be on the ACL with decrypt access.

Suppose client B has decrypt access and has in its possession a satchel
which it would like to open and read.  It establishes Kerberos
authentication with the encryption server, thus proving its identity and
establishing a session key, $K_{bn}$.  B then sends the satchel to Nox.
When Nox receives the satchel, it alone knows the compartment key,
$K_C$, and so it can therefore decrypt the satchel and expose the
original data, X.  It then encrypts the data in the session key and
sends $\{X, A, T_n\}_{K_{bn}}$ back to client B, who can decrypt it
using its copy of the session key.  The data can then finally be viewed
by client B, who can be certain that A in fact did send the message
at time $T_n$, and that only the people on the decrypt ACL could have
also viewed the message.\footnote{Naturally, while B is
self-congratulating him- or her- self, someone will be reading the
top-secret information on his screen over his shoulder, but that's
life\ldots} 

Unfortunately, it appears that it is will be extremely difficult to
formally prove the security of Nox.  A proof addressing the security of
secrets against release must involve a temporal logic; unfortunately,
such logic systems not currently well understood, and appear to be
incomplete proof systems.\cite{Abadi}  It be possible to use an approach
similar to that of Interrogator\cite{Millen}, which attemps to find
flaws in a authentication or cryptographic protocol using a rule-based
system.  However, a negative finding does not prove the security of the
protocol; only that one particular rule-based system was not able to
find a successful attack.

\chapter{Extensions}

\section{Multi-server operation}

There are several problems which might require a multi-server system in
nox.  The first problem is that the Nox server may become
overloaded and prove to be able to handle all of its clients' demands.
There are several solutions to this problem.  The first, and most
simplest, is to install encryption hardware on the Nox
server.\footnote{Indeed, the specifications for DES state that DES is
not {\em true} DES unless it is implemented in hardware.} However,
depending on the encryption system, this may be costly.  This solution
also doesn't scale.  If the load continues to increase after the
encryption hardware has been installed, sooner or later the server will
again be overloaded.

Another solution is to split the realm into two or more parts --- thus
in order to read satchels for compartment A, the client will have to
talk to server A; to read satchels for compartment B, the client will
have to talk to server B.  However, while this solution solves the first
problem, there is another problem which it does not address.  This
problem is reliability.  Since only one machine --- the server --- knows
the encryption keys, if a client cannot communicate to the server
(either because the network has been partitioned or because the server
has crashed), any satchels in the client's posession become useless for
the duration of the downtime.

The solution which solves both of the above problems is to replicate the
Nox servers.  Thus, as long as the clients can reach one of several
servers, service will not be lost.

However, there are some problems with having replicated servers which
most be addressed.  First of all, all the servers have to be physically
secure; if any one of the servers are compromised, the entire scheme is
compromised.

The second problem is that the databases on all of the servers must be
kept consistent.  One way of doing this is to designate one of the
servers as the Master Server, just as Kerberos does.  Under this scheme,
changes can only be made if the client can reach the master server.  In
addition, because of network partitioning, some of the slave servers may
not be immediately reachable by the master server.  Thus, there may be
some lag for changes to propagate.\footnote{Indeed, this may cause some
problems in that an intruder maybe able to disable a gateway and keep a
slave server isolated from the master server.  Thus, if the intruder
knows that his access is about to be revoked, he may be able to delay
the revocation of his access rights for a time.  We will need to assume
that the gateway is relatively well protected, and that the loss of
service caused by the gateway being down will attract attention
relatively quickly.}

\section{Multi-realm operation}

There are two modes of inter-realm operation supported by Nox.  The
first assumes that there is a fast network connecting the two realms.  In
this case, the inter-realm operation is performed by having the remote
client perform inter-realm authentication using Kerberos.  (This
presumes that the remote-realm client and the local Kerberos server can
communicate via a fast network (ethernet).)  Using this authentication,
the remote-realm client can then contact the Nox server directly over
the fast network, and proceed as any other local client.

The trickier case happens when there is no fast network between the two
realms.  This is in fact a hard problem, so it may be appropriate to
define it away and simply require the user to wait for world-wide ISDN
to make its debut.  However, the following is a draft solution for how
this type of inter-realm operation might be easily grafted onto the
existing Nox protocol:  {\large\bf This is a kludge!!!  We need to fix this
somehow\ldots} 

We introduce the concept of a Nox realm, which is distinct from a
Kerberos realm.  Two Nox realms can only communicate if they have
exchanged a private key.  Principal entries in ACL's are modified to
take a triple: (auth system, principal, Nox realm).  When an
administrator sets the ACL of his compartment to grant decrypt access to
a foreign Nox realm, it will be recognized that this automatically
decreases the security of the compartment to the minimum of the security
level of the local Nox realm and the remote Nox realm.  

In addition, we add a new request to the Nox server, which asks it to
rekey a satchel so that instead of being encrypted in the compartment
key, it is now encrypted in the inter-realm key.  In addition, since the
foreign realm will not be able to access the compartment's ACL, if the
satchel did not have a built-in ACL already, this request will also
build-in a copy of the current ACL of the compartment.  Once this request
is invoked, the principals of the foreign host cannot be revoked, since
the ACL is now bound into the satchel.  This is simply the price one
pays for inter-realm Nox operation without a fast network.

If a user on in foreign realm wishes to encrypt a message on a local
compartment, he makes a request to his Nox server to encrypt in the
inter-realm exchange key:

\begin{itemize}
\item The compartment this should be encrypted in
\item An optional ACL
\item The sender
\item A creation timestamp 
\item The message data
\end{itemize}

Since the foreign Nox server does not know if the user is allowed to
encrypt messages in the specified compartment (or indeed if the
compartment exists at all), it just throws the interchange satchel
together.  When the local Nox server gets this interchange satchel, it
checks to see if the sender actually has encrypt rights.  If the sender
does not, then the Nox server will throw away the message then.  

Thus we see that even if we do not have a fast network between to
realms, it is possible, although awkward, to have inter-operability
between the two Nox realms.\footnote{But it is such a hack\ldots}

\subsection{Trust assumptions made under a multi-realm environment}
\nopagebreak\par
{\em Note:  This section still under development}
\nopagebreak\par
Stepping back a few levels, we find that under a multi-realm scheme we
must make the following trust assumptions:
\nopagebreak\par
\subsubsection{The foreign user is trust-worthy}

This is, in fact, the same assumption that an administrator of a
compartment must make for any user before putting that user onto the
Access Control List.  Thus, this is a problem that we would have even if
we were not running in a multi-realmed environment.

\subsubsection{The foreign authentication service is secure}

Since the foreign user will be using the authentication server of his
realm to authenticate himself, the administrator of the compartment who
puts a foreign user on an ACL must be prepared to trust the
administrators of the foreign authentication service.  

Unfortunately, there is no clean solution to this problem that scales.
If we assume a fast network between the foreign realm and the local
realm, it might be possible to allow the foreign user to authenticate
himself to the local authentication server, by giving him a Kerberos
principal on the local realm, for example.  If there only a few such
users who are trustworthy but who are in a foreign realm which is not
trusted, this solution might work; but ultimately it is impossible to
place every foreign user into the database of the local authentication
service --- this obliviates the reason for splitting the authentication
service into multiple realms in the first place.

\subsubsection{The foreign Nox server is secure}

In the case where we do not have a fast network between the foreign
realm and the local realm, the foreign user is prevented from carrying on
a series transactions with the local Nox server.  Thus, the only way of
allowing him to read the satchel is for the satchel to be re-encrypted
into an exchange key which is known only by the local Nox server and the
foreign Nox server.  Presumably, the local Nox server would only
re-encrypt a satchel if the compartment ACL contained a user who was in
the specified foreign realm.  

However, since setting up an exchange key requires the cooperation of
the administrators of the two Nox servers, this key must have been
exposed at one point or another {\em outside} the Nox servers
themselves.  Thus such an inter-realm exchange satchel will be
inherently less secure than a satchel which is intended for intra-realm
use only.

Another problem which is related to trust is that if there is no fast
network, the foreign Nox server will not be able to access the
compartment ACL, since it is only available on the local Nox server.
Thus, the ACL must be bound inside the inter-realm exchange satchel.
However, this means that once an inter-realm exchange satchel is
created, revocability is lost.

One potential solution to this problem is to only allow a few principals
to crate inter-realm exchange satchels, by controlling this request by
an ACL.  This reduces the exposure of the inter-realm exchange satchels
to perhaps only {\em SysDeamon.Mailer} principal, who is trusted to only
request inter-realm exchange satchels just before sending them to the
foreign realm.

\appendix

\chapter{Details of a Sample Implementation}

\begin{quote}
\begin{description}

\item[prototype, n.] ---
         First stage in the life cycle of a computer product, followed
         by pre-alpha, alpha, beta, release version, corrected release
         version, upgrade, corrected upgrade, etc.  Unlike its
         successors, the prototype is not expected to work.
\end{description}
\end{quote}

The following are some implementation notes for a planned reference
implementation of Nox.  

\section{Server-client communication protocol}

\begin{quote}
\begin{description}

\item[handshaking protocol, n.] ---
         A process employed by hostile computer equipment to initiate a
         terse but civil dialogue, which, in turn, is characterized by
         occasional misunderstanding, sulking, and name-calling.
\end{description}
\end{quote}

Communications between the server and the client will be done using an
RPC protocol.  When a client wishes to initiate a session with Nox, it
sends a connection request to the server, which includes the necessary
information to authenticate itself to the server using some specified
authentication method (Kerberos, for example.)  The server stores away
the following state per connection:

\begin{itemize}
\item A connection ID, which is unique with respect to the lifetime of
the server.

\item The user which has authenticated using the connection ID.

\item The host address from which the connection was initiated.

\item A session key which was generated from the authentication
sequence.
\end{itemize}

Nox returns a connection descriptor and a connection ID when a
client opens a connection with the server.  The connection descriptor is
a low-numbered integer which is used by the server to index into an
array of structures describing the connection.  When the server is
initialized, it picks a random number which is the initial connection
ID.  This connection ID is incremented each time a new connection is
opened to the server.

Every time the client sends a request to the server, it includes the
connection descriptor and the connection ID in the packet; the rest of
the packet contains the request to the server and the appropriate
arguments for that request encrypted in the session key.  When the
server receives the packet, it uses the connection descriptor to get the
Connection Data Block (CDB) associated with the connection and compares
the connection ID supplied with the client packet to the connection ID
in the CDB.  If either the ID's do not match or the lifetime of the
authentication has expired, the server will respond with an error code
which asks the client to re-open a connection with the server and
retransmit the request. 

If necessary, the server can at any point invalidate a connection.  It
may need to do this if it has run out of CDBs when its opening a
connection with for a client and it has run out of free CDB.  In this
case, it will merely pick the CDB which has been used least recently and
assign it to the new connection.  The next time the old client tries to
use that connection descriptor (assuming the old client is still
running!), the connection ID which has will no longer match the
connection ID in the CDB, and the server return an error indicating that
the client should open a new connection to the server.

The following is a list of requests that the server will support on
compartments:   (Note: these requests are not yet fully defined yet;
for example, what exceptions have not listed here, and need to be at
some point\ldots) 

\begin{itemize}
\item Encrypt --- client sends subject, data and optional Built-in ACL;
server returns a satchel encrypted with a the specified compartment.
Requires Encrypt and optionally Build-In ACL access.

\item Decrypt --- client sends satchel and bit-field corresponding to
Identify, Examine, and Decrypt actions; the server returns the requested
data.  Requires Identify, Examine, and/or Decrypt access.

\item Status --- server returns the current key version number, the last
modification time of the compartment and the ACL of the compartment.
Requires Status access. 

\item New Key --- server creates a new key for the compartment, and
returns the new current key version number.  Only the master Nox server
supports this query, and at some point will arrange for the new keys (or
perhaps the entire database) to be distributed to all of the slave
servers, probably encrypted in the Nox master server.  Requires
Administrate access.

\item Set Acl --- client sends a principal and a list of access rights;
the server will set the ACL on the compartment to have those access
rights.  Requires Administrate access.

\item Delete Acl --- client sends a principal; the server will delete
that principal from the compartment's ACL.  Requires Administrate
access.  (Note that because of wild-carding, setting the ACL for a
principal to have null access rights and deleting a principal from an
ACL have entirely different semantics.)
\end{itemize}

The following is a list of request that the server will support on a
compartment container:

\begin{itemize}
\item List --- the server returns a list of names of the containers and
compartments contained in the specified container.  Requires the List
access right.

\item New --- the client passes the name of the new compartment; the
server creates the compartment, placing the principal with which the
client authenticated with the server on the compartment ACL with full
access rights, including Administrate.  Requires the Create
access.

\item Remove --- the client passes the name of the new compartment; the
server destroys that compartment.  Note that this will make any satchels
which were encrypted in that compartment permanently useless, so this
operations should not be done lightly.  Requires the Delete
access.

\item Make Compartment --- the client passes the name of the new
sub-container, the initial quota of the sub-container and a flag
indicating whether or not the ACL of the new sub-container should
contain just the user creating the sub-container or whether the ACL
should be copied from the parent container; the server creates the
sub-container, with the appropriate ACL.  Requires the Sub-container
access. 

\item Delete Compartment --- the client passes the name of the
sub-container to be deleted; the server will delete the sub-container if
it is empty.  Requires the Sub-container access.

\item Set Quota --- the client passes the name of the sub-container and
its new quota; the server will set the quota of the sub-container,
modulo the rules on quotas detailed elsewhere.  Requires the
Sub-container access.

\item Disable --- The client passes the name of a compartment; the
server will disable the compartment.  Requires Manage access.

\item Enable --- The client passes the name of a compartment; the
server will enable the compartment.  Requires Manage access.

\item Force ACL --- The client passes the name of a compartment, a
principal, and a list of access rights; the server will forcibly set the
supplied principal to have the specified access rights on that
compartment.  Requires God Access. 

\item Deify --- The client passes a principal and a container; the
server will grant the principal god access for that container.  Requires
God access on either the container or in the parent container.

\end{itemize}


\section{Server Internals}

This details a design of a sample implementation of Nox, and should
highlight some of the potential problems an implementor will have to
face.

The RPC mechanism that will be used will be a modified version of
Apollo's Networking Computing System (NCS).  It has the advantage of
being one of the more efficient RPC mechanisms available, and it has a
featureful interface compiler / stub generator.  The modification that
will be necessary is so that some of the arguments of the RPC can be
encrypted in the connection's session key after they have been
marshaled by NCS.  Likewise, the arguments will have to be decrypted
before they can be unmarshaled by the RPC system.  I am told by Bill
Sommerfeld\footnote{An employee of HP/Apollo who is currently working on
NCS} that this should be relatively trivial to do.

The encryption containers and encryption compartments can be easily
modeled by the Unix$^{\hbox{TM}}$ filesystem.  Each encryption container
can be modeled as a directory, with its access control file stored in
the file ``$>$ACL'' (which will not conflict with potential compartment
names since the $>$ character is not allowed in either compartment or
container names.)  All of the state of an encryption compartment will be
stored in a file, in the appropriate directory corresponding to its
parent container.

The majority of the server will be coded in C++.  The reason for this is
that the server can easily be broken down into several easily understood
conceptual objects.  A disadvantage of using C++ is that the language is
still relatively young, and certain debugging tools, such as Saber C++,
are not yet ready.  However, it is hoped that the better data hiding and
abstraction abilities of C++ will make the coding more robust and make
debugging tools less necessary.

There will be abstract classes for to describe authentication systems
and encryption systems.  Each authentication system or encryption system
that will be supported by the Nox server will be coded as a derived
class of its respective base class.  Furthermore, there will be two
tables, each associating a string with a pointer to a class object
implementing the authentication system or encryption systems named by
the string.  This allows the server to be easily extended to support
future authentication or encryption schemes.

\nocite{TCSEC}
\bibliography{thesis}

\end{document}

