The History of VIFF

VIFF was started by Martin Geisler in March 2007. The original name for the project was PySMPC since it was, well..., a Python library for doing secure multi-party computations (SMPC). That name was eventually dropped since it is somewhere between difficult and impossible pronouncing it in a fluent way. After a vote on Martin’s blog, the name was changed to Virtual Ideal Functionality Framework with the much smoother abbreviation VIFF. The idea is that VIFF allows you to implement an ideal functionality in software, and can thus be seen as a framework for building virtual ideal functionalities.

Background

VIFF grew out of a research project called SIMAP which is conducted at the University of Aarhus, Denmark in collaboration with the University of Copenhagen and industry partners. SIMAP is short for Secure Information Management and Processing and the main goal of the project is to develop tools that can be used to build applications which use SMPC to solve real-world problems. The tools are a set of efficient cryptographic protocols and a domain-specific language which aims to allow normal programmers to use the cryptographic protocols in an easy and secure manner without being security experts themselves. In January 2008 the SIMAP project ran the first ever large-scale SMPC application in which Danish farmers traded sugar beet contracts using a secure double auction.

The SIMAP project is the successor to the SCET project (short for Secure Computing Economy and Trust) which implemented a prototype of the secure double auction used in SIMAP. The comparison protocol used is available as ComparisonToft05Mixin in VIFF, but people might still refer to it as the “SCET comparison” on the mailing list.

Problems and solutions

While the foundation for the sugar beet auction was being programmed in Java in the SIMAP project, Martin began experimenting with a new architecture in Python. The Java implementation was big with about 8,500 lines of code for some 130 classes and interfaces and while implementing the comparison protocol it had become clear that there were a number of problems with its design.

Problems

We knew from the beginning that it was important to run things in parallel to use the bandwidth in the most efficient way. So a concept of “batch jobs” was introduced for grouping parallel operations together. The problem was that one had to write code for dealing with combinations of different batch jobs so when implementing a new operation (such as a comparison protocol) one had to define how a batch job would look like for the new operation and how the batch job would be combined with all other types of batch jobs. This severely limited the modularity since every new piece of code needed to know about every old piece.

Another problem was that although the high lever interface manipulated secret shared values as first class objects, the runtime system did not. Instead the values were kept in a HashMap and referenced using integers by the internal runtime code. So extending the runtime system could not be extended in terms of itself, akin to how the earliest compilers had to be written in assembler instead of a higher level language.

Solutions

The Twisted network framework turned out to be a both simple and elegant solution to the first problem. The key is the Deferred class which allows the code to treat all operations equal: they all take deferred inputs and return a deferred output. All time is spend either working on local data or waiting for more inputs to arrive over the network. When data arrives the associated callbacks are immediately executed without regard to what kind of operation they are. This uniform interface means that as many operations as possible are executed in parallel. Extending the runtime with new operations is also much simpler since the framework will take care of running things in parallel – new operations work the same as old “primitive” operations.

It is interesting to note that this design relies heavily on the use of function pointers, something which Java lacks. Python also supports anonymous functions (lambda expressions) which are very convenient with this programming style. It might be possible to design a similar system in Java by using objects to represent the callbacks, but it would probably be much more cumbersome.

The problem with representing secret shared values by integers internally instead of objects could of course have been solved equally well in Java.

Current status

VIFF supports most if not all the protocols that the SIMAP code supports, and extends them in some cases by providing security against active adversaries. VIFF started out as 450 lines of code which supported arithmetic with Shamir shares and pseudo-random secret sharing – that was all it took to implement the basic ideas using Twisted. The code has since grown to a little less than 4,000 lines.

Despite the growth in code size, we believe that VIFF can still be considered a light-weight library for secure multi-party computation. To the best of our knowledge VIFF is the only library available for general SMPC and we hope that it will become the standard SMCP library and thus a stable test-bed for new cryptographic protocols.

Table Of Contents

Previous topic

Preprocessing

Next topic

Planned Work on VIFF

This Page