A problem with previous versions of SEPIA was that all input and privacy peers needed to be connected simultaneously, i.e., flexible joining or leaving of peers was not supported. In fact, a single closed socket could lead to a crash of the entire computation. However, as supported by Shamir's secret sharing scheme, secrets can be reconstructed and computation continue even though not all privacy peers are present (depending on parameters). Also, if large numbers of input peers contribute data, supporting short-lived connections for submitting shares greatly enhances scalability.
Therefore, connection handling in SEPIA was rewritten from scratch to accommodate flexible connection management. Connections of each input/privacy peer are now handled by a central ConnectionManager. It creates, stores, and manages SSLSocket connections between the input and privacy peers. The protocol threads no longer hold sockets themselves but request messages to be sent or received to/from a peer identified by a String ID, using the public interface of the ConnectionManager. In case a connection is closed, the ConnectionManager transparently handles the failure, checks if the configured minimum number of peers are still available, and attempts to reestablish lost connections before the next round.
SEPIA Configuration EditorCreating configuration files and certificates/keystores for large numbers of input and privacy peers can be tedious, especially if various configurations with different parameters need to be evaluated. To facilitate the creation of configurations, we implemented the SEPIA configuration editor (see the picture below). It operates on a config file template and automatically generates specific config files and (optionally) key material for a configurable list of input and privacy peers. The configuration editor comes with a GUI but also has a command-line interface.