Release Notes for v0.9

Supporting Join and Leave of Input and Privacy Peers

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 Editor

Creating 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.
SEPIA Configuration Editor


Note that protocols written for SEPIA v0.8.3 and earlier will not compile with v0.9. Due to the comprehensive refactoring of the connection layer, protocols need to be ported to v0.9. Please consult the user manual and all the currently available protocols for v0.9 (e.g., the tutorial protocol). Probably the fastest way of porting an old protocol is to use the current tutorial protocol as a basis and re-add the protocol-specific code.