\subsection{Communications package}

The clients and servers use a communications package based on SSL
to ensure the authenticity and confidentiality of connections.
The communications package handles the following tasks internally:

\begin{itemize}
\item Tunneling communications using an underlying secure transport,
like SSL.
\item Providing an intuitive, platform-independent interface for
reading and writing abstract data types, like large integers.
\item Managing a large number of simultaneous network connections
and presenting a simplified networking API for higher-level code.
\item Handling transparent end-to-end authentication using techniques
such as certificates and sequence numbers.
\item Maximizing efficiency by taking advantage of buffering and
nonblocking I/O.
\end{itemize}

In short, the package ensures that the underlying protocol security
assumptions mentioned earlier are met while abstracting away the
complexities of asynchronous networking and any optimizations we
implement at the communications level.

A configuration file, which is read upon program startup, contains
network settings for the clients and servers, such as IP addresses,
port numbers, and pathnames.
Instead of requiring each program to know all the details of each
server, the API allows servers to be referenced directly by number.
The communication package takes care of the mappings between
server number and address/port information.
In addition, it handles peer identification transparently, so that
a server knows the identity of any clients that contact it.

\subsubsection{Authentication}

As stated earlier, the communications package is based on
Eric Young's SSLeay~\cite{SSLeay} package.
Client and server certificates are issued by a private CA,
whose public key is distributed by hand to all clients and servers
beforehand.
Each party has its own certificate, signed by this CA, which
contains its own identity as part of the signed certificate data.
For example, the certificate for server 0 has a subject field that
looks like:

\begin{verbatim}
/C=US/ST=California/O=Stanford University/
    OU=ITTC Project/CN=[SERVER 0]
\end{verbatim}

The name field contains the authenticated identity of the party, which
can be verified by clients and other servers.

At the moment our approach to authentication is ad-hoc. After all, the
method of authentication depends on the environment in which our system
is used. For instance, when generating a CA private key, authentication
can be done using certificates generated by a higher level CA. For a root CA
authentication can be done using the current CA root key. In other
environments where shared keys are used authentication can be done using
standard certificates issued by a CA.

In addition to certificate authentication, the communications package
keeps track of sequence numbers for each pair of parties.
This allows the system to detect when a private key is compromised
and used, since this would introduce a skew between the sequence
numbers held by the servers and the legitimate client.

% Do we need to write up the whole protocol here?

\subsubsection{Multiparty I/O}

There are many instances where conventional network programming can lead
to considerable implementation inefficiencies, even under normal usage.
Consider an application of threshold decryption when one of the servers
has failed.  One of the benefits of threshold decryption is the ability to
tolerate the loss of one or more shares.  However, if one naively attempts
to connect to each server in series, the procedure will stall when the
non-functioning server is reached.

Instead, the communications package uses {\em non-blocking} I/O underneath
to alleviate this problem.  In this mode, when the communications package
makes an I/O request, it tells the operating system to return immediately
instead of waiting until the operation can be completed.  This is useful
when communicating with multiple parties, because the application can open
multiple connections and have the communications package deliver packets
on several of the connections without waiting for acknowledgments.
This reduces the amount of time spent waiting on the network to its
theoretical minimum.

The core of the communications package is a state machine that tracks the
status of each connection.  This state machine handles the initial
connection establishment and negotiates the initial authentication
handshakes transparently to the application.  This approach is needed
because multiple connections, in different stages, may be in progress
simultaneously.  All data is buffered internally and delivered to the
application as complete and well-formed packets.

\subsection{Key storage}

\label{disk}

The SSLeay package supports reading and writing both public and
private keys in PEM format.
Our private shares and shared public keys are represented internally
as extensions of the standard RSA key data
structure\footnote{Because SSLeay supports some degree of object
polymorphism, our ``extended'' RSA keys can be used interchangeably
with ``ordinary'' RSA keys in SSLeay.}.
On disk, we support a PEM-encoded ASN.1 format similar to that
used for RSA keys.
The private and public share formats are described in Table~\ref{privshare}.
Note that none of these files contains the optional values
$d \bmod p - 1 ,\; d \bmod q - 1 $, or $q^{-1} \bmod p$
normally used to optimize RSA computations because none of
the parties can construct these values.

\begin{table*}[ht]

\begin{center}

\begin{tabular}{|c|c|c|c|c|} 
\multicolumn{2}{c}{Private share file format} & 
	\multicolumn{1}{c}{\mbox{\hspace{1in}}} &  
	\multicolumn{2}{c}{Public key file format}  \\
\cline{1-2}  \cline{4-5}  
Data Type & Field & & Data Type & Field \\
\cline{1-2} \cline{4-5}  
INTEGER & Version    & & INTEGER & Version    \\
INTEGER & $N$        & & INTEGER & $N$ \\
INTEGER & $e$        & & INTEGER & $e$ \\
INTEGER & $k$ (number of sets) & & INTEGER & $g$ (generator) \\
INTEGER & $d_1$ & & INTEGER & $k$ (number of sets) \\
$\vdots$ & $\vdots$  & & INTEGER & $g^{d_1} \bmod N$ \\
INTEGER & $d_k$      & & $\vdots$ & $\vdots$ \\
 &                   & & INTEGER & $g^{d_k} \bmod N$ \\
 \cline{1-2}          \cline{4-5} 
\end{tabular} 

\end{center}

\comment{

\begin{tabular}{|c|c|} \hline
Data Type & Field \\ \hline
INTEGER & Version \\
INTEGER & $N$ \\
INTEGER & $e$ \\
INTEGER & $k$ (number of sets) \\
INTEGER & $d_1$ \\
$\vdots$ & $\vdots$ \\
INTEGER & $d_k$  \\ \hline
\end{tabular} 
Private share file format

\begin{tabular}{|c|c|} \hline
Data Type & Field \\ \hline
INTEGER & Version \\
INTEGER & $N$ \\
INTEGER & $e$ \\
INTEGER & $g$ (generator) \\
INTEGER & $k$ (number of sets) \\
INTEGER & $g^{d_1}$ \\
$\vdots$ & $\vdots$ \\
INTEGER & $g^{d_k}$ \\ \hline
\end{tabular}
Public share file format.

}

\caption{Private and public shared key formats} \label{privshare}
\end{table*}

The values $g$ and $g^{d_i} \bmod N$ stored in the public shared key
are used to detect incorrect (or possibly compromised) private
share operations by the share servers.  Their function is not
discussed in this paper.
