FairplayBI

A version of Fairplay software for 2-party SMC (Secure Multi-party Computation) which is really able to handle arbitrarily long integers. Related links:

• Secure multi-party computation
• Original Fairplay project
• FairplayPF patch for Fairplay

Quick example

Lets say you wanna communicate according to the "Sub.txt" circuit program specification.

1. Always specify rundir for the JVM: "-Drundir=/home/ctoth/FairplayBI/bin/run/"
2. Compile the program with Alice or Bob with parameters: "-c progs/Sub.txt"
3. Start Bob with parameters: "-r progs/Sub.txt randomstring1 4"
4. Start Alice with parameters: "-r progs/Sub.txt randomstring2 localhost"

See later about the explanation of these.

Convention over configuration

The software is able to handle input from the parties (Alice and Bob) either from standard input or from file. The file input is detected automatically and works by convention over configuration. The rundir needs to be specified for Fairplay anyway, so log4j can be configured using the SFE_logcfg.lcf file. FairplayBI extends the usage of this rundir Java environment variable and leverages it for all potential inputs and outputs. FairplayBI assumes that the program file and other input and output files will reside in the "progs" subdirectory of the folder specified in the rundir variable.

FairplayBI
+- src
   +- SFE
   |  \- ... Java source files
   \- run - this directory supposed to be the "rundir" environment variable
      |- Readme.txt - usage guide
      |- SFE_logcfg.lcf - log4j configuration file
      \- progs
         |- Sub.txt - the circuit program, input of the compilation step
         |- Sub.txt.Opt.circuit - output of the comilation step, input of the run step (note: this may differ a little depending on circuit compilation options, but it's handled automatically later by Fairplay)
         |- Sub.txt.Opt.fmt - output of the comilation step, input of the run step (note: this may differ a little depending on circuit compilation options, but it's handled automatically later by Fairplay)
         |- Sub.txt.Alice.input - Alice's assumed input in file
         |- Sub.txt.Bob.input - Bob's assumed input in file
         |- Sub.txt.Alice.output - Alice's output to file (in case the input was from file)
         \- Sub.txt.Bob.output - Bob's output to file (in case the input was from file)

If FairplayBI automatically searches for a file type input by postfixing ".Alice.input" or ".Bob.input" to the program file full path. If FairplayBI doesn't find these files, it'll wait for the corresponding input on the standard input, and it'll produce the output also to the standard output. If the input is specified in a file then the output will be also written into a file, which name is generated by postfixing ".Alice.ouput" or ".Bob.output" to the program file full path.

Changelist

• FairplayFP patch
• All container classes (Vector, Map, Set, etc) were converted to type-safe generics from raw generics
• Had to add Compiler/InputFormat.java to be able to fully accomplish the type-safe generics
• Converted the internal representation of Int<*> SMC program types to BigInteger instead of Java int
• Changed the party (Alice/Bob) run-time input parsing so it can take in BigIntegers
• The program file (besides Alice/Bob inputs) also can contain arbitrarily long integers (program code parsing is modified)
• Arbitrarily long integers mentioned above can be specificed also in hexadecimal (0x prefix), binary (0b prefix) and octal (0o prefix) besides regular decimal radix representation (no prefix).
• It is possible now to place the run-time input into files (name derived from the other file names by convention over configuration) instead of a console input, see more later
• If the file comes from the input, than the output will be written to a file too, file name is also derived from the other file names by convention over configuration, see more later
• The software searches for the program script and all other inputs relative to the rundir Java environment variable (that was already used for finding the log4j configuration file), it produces the outputs relative to that too
• The output is able to display negative integer results (original Fairplay couldn't even do that with int)
• The output is able to display BigInteger (arbitrarily long integer) results (regardless of negative or positive)
• Enhanced error messages
• Lots of minor fixes and corrections

Effects of changes

• The source code became somewhat more modern Java conform, safer (mostly fromthe type-safe generics)
• Really able to handle arbitrarily long integers in any part fo the program
• Can integrate with other solutions easier (run-time input from file)
• Testing easier because of the file input/output features. See Wei Xie's testing kit in his own FairplayBI clone.
• There can be performance penalty for BigInteger usage compared to int (simple increment for example)
• The source code got cleaner (converting from and to bit representations: BigInteger natively supports that while with integer there were bit manipulation/shift operations)

Known limitations (apply to original Fairplay also)

• Iteration number of for loops must be constant values. This is essential, since the software has to generate the circuit, and during circuit generation every loop is basically fully unrolled: the kernel of the loop is repeated as many times as the iteration number. There can be an "if" branch in the kernel though. We need to research if that can be improved or not.

License

Please refer to GPL.txt

Authors

• Csaba Toth <csaba (dot) toth (dot) us (at) gmail (dot) com>
• Wei Xie <wei (dot) xie (at) vanderbilt (dot) edu>