galoisinc / swanky

A suite of rust libraries for secure multi-party computation

swanky: A suite of rust libraries for secure computation

swanky provides a suite of rust libraries for doing secure computation.

• bristol-fashion: A parser for Bristol Fashion circuits.
• diet-mac-and-cheese: A diet version of the Mac'n'Cheese protocol
• fancy-garbling: A library for boolean and arithmetic garbling
• fancy-garbling-base-conversion: Lookup tables useful for the fancy-garbling crate
• humidor: A test-bed for Ligero-like protocols
• inferno: An implementation of the Limbo zero knowledge proof protocol
• keyed_arena: Bump allocator which allows for random access to its allocations
• mac-n-cheese-compiler: A tool to compile a zero knowledge circuit to the mac n'cheese IR
• mac-n-cheese-event-log: Utilities to define metrics for mac n'cheese
• mac-n-cheese-inspector: A tool to inspect mac n'cheese IR files
• mac-n-cheese-ir: The definition of the mac n'cheese IR
• mac-n-cheese-runner: A tool to proof mac n'cheese IR files in zero-knowledge
• mac-n-cheese-sieve-parser: A parser for SIEVE IR (a zero knoweldge proof circuit format)
• mac-n-cheese-vole: An implementation of Vector Oblivious Linear Evaluation
• mac-n-cheese-wire-map: An implementation of a sparse array
• ocelot: A library for oblivious transfer protocols
• popsicle: A library for private set intersection
• schmivitz: A library for zero-knowledge protocols using VOLE-in-the-head
• scuttlebutt: A library of useful multi-party computation utilities
• simple-arith-circuit: Simple arithmetic circuit library
• swanky-channel: A channel abstraction to let users avoid manual flushing
• swanky-field: Definitions of the core FiniteField and FiniteRing traits
• swanky-field-binary: Binary finite (extension) fields
• swanky-field-f61p: An implementation of GF(2^61-1)
• swanky-field-ff-primes: Finite field implementations for large prime fields
• swanky-field-fft: FFT implementations for finite fields
• swanky-field-test: Utilitites for testing correctness of finite field implementations
• swanky-flatbuffer-build: Tooling to automate compiling flatbuffer schemas
• swanky-party: Support for types indexed by a party.
• swanky-serialization: Traits and utilities for compact serialization into a canonical byte representation
• vectoreyes: Cross-platform SIMD types and functions
• web-mac-n-cheese-wasm: Web Mac'n'Cheese, the wasm part
• web-mac-n-cheese-websocket: Web Mac'n'Cheese, the websocket part
• zkv: Zero knowledge proofs for verilog files generated using saw / abc

2024-02-09 Projection gates in arithmetic garbled circuits have a proven security vulnerability in their design. The issue affects the fancy-garbling library and its dependencies (including popsicle). We are currently investigating the impact this bug has on Arithmetic Garbling (CRT) in swanky.

A note on security

swanky is currently research software. Do not deploy it in production, or trust it with sensitive data.

Please reach out to us at [email protected] if you're interested in using Swanky in a production setting.

Using swanky

Preferred Way

The preferred way to use swanky is to fork this monorepo, and add your code to your fork. This approach makes it easy for your code to inherit the configuration of the swanky repo.

Alternative Way

It is also possible to use swanky as traditional Rust crates. The downside of this approach is that you won't automatically get the configuration of the swanky repo. swanky is only tested against the pinned rust version in the repository and the pinned dependency versions.

To use a swanky crate in your project, add the following line to the [dependencies] entry in Cargo.toml:

<crate-name> = { git = "https://github.com/GaloisInc/swanky", rev = "xxxxxx" }

where <crate-name> is one of the crates listed above and rev is the particular revision to use.

Note: As swanky is currently considered prototype software, it is best to pin a particular revision of swanky, as there is no guarantee that future versions of swanky will maintain backwards compatibility.

It is also advisable to copy over swanky's .cargo/config file, and to enable LTO in your release builds (lto = true in your Cargo.toml file).

Software Requirements

To compile Swanky, you should install and use Rust via rustup. The swanky repo will direct rustup to use the correct version of Rust.

The ./swanky tool automates some tasks in the codebase. For example, ./swanky lint will run the Swanky linting checks. In order to use this tool, you need to install the Nix package manager. You'll also need a python3 installation (no packages other than the standard library are required).

Citing swanky

If you use swanky in your academic paper, please cite it as follows:

@misc{swanky,
    author = {{Galois, Inc.}},
    title = {{swanky}: A suite of rust libraries for secure computation},
    howpublished = {\url{https://github.com/GaloisInc/swanky}},
    year = 2019,
}

License

MIT License

Contact

You can contact the swanky team at [email protected].

Acknowledgments

This material is based upon work supported in part by ARO, SSC Pacific, IARPA and DARPA under Contract Nos. W911NF-15-C-0227, N66001-15-C-4070, 2019-1902070006, and HR001120C0085.

Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the ARO, SSC Pacific, IARPA and DARPA. Distribution Statement ``A'' (Approved for Public Release, Distribution Unlimited).

Copyright © 2019-2022 Galois, Inc.

swanky's Issues

Implementation of HL17 OT protocol

Hi, thanks for open sourcing swanky!
I'm a student interested in MPC and have just implemented Efficient and Universally Composable Protocols for Oblivious Transfer from the CDH Assumption (HL17) in a public repo.

Would you be interested in a PR for this OT protocol to be included in ocelot? Obviously I'd change my current implementation such that it is in line with the current chou orlandi implementation :)

Best, Robin

`SymChannel` not appearing in docs

I'm not sure why, but SymChannel (in scuttlebutt) doesn't appear to be included in the documentation. I've checked the hosted documentation (https://galoisinc.github.io/swanky/scuttlebutt/) and built the documentation locally, neither seem to have it.

I'm not sure why this would be, it seems to be part of the public API in scuttlebutt/src/lib.rs.

Just leaving an issue here in case swanky begins active development again.

Simple GC produces the deadlock

I'm developing a complex GC, and stuck in deadlock. I've managed to reduce the code causing problem, so here's a simplest circuit:

1. Both Garbler and Evaluator encode constant a = 1 (mod 2)
2. Garbler receives and Evaluator encodes some single value b (using FancyInput::{receive, encode})
3. Parties evaluate c = a ^ b
4. GC outputs c, Evaluator learns its value

Code snippet is available here. I'm using the latest version of the fancy-garbling library (e673c2 commit).

The code above produces deadlock. Specifically, Garbler freezes at step 2 (at FancyInput::receive value b), and Evaluator freezes at step 1 (while encoding the constant, it blocks at reading from a channel)

If we swap step 1 and step 2 (so parties exchange encoded value b first, and then encode the constant a), GC will terminate and produce a valid output c. Order of steps doesn't matter here, but matters in more complex GCs following streaming approach.

Is it a bug or known limitation?

Fixed-key AES-128 has half of each round key be all zeros

Each round key is supposed to be 128 bits long, but they are hard-coded with only the low 64 bits specified.

pub const FIXED_KEY_AES128: Aes128 = Aes128 {
    rkeys: unsafe {
        [
            (__U128 {
                bytes: 0x15B5_32C2_F193_1C94,
            })
            .vector,
            (__U128 {
                bytes: 0xD754_876D_FE7E_6726,
            })
            .vector,
            // ...

This means that the high 64 bits of every round key are zero. As far as I can tell, there are no AES-128 keys that expand into such a sequence of round keys. It seems likely to me that not using the proper key schedule could make AES weaker.

sigma function implemented incorrectly

Currently, the sigma function is implemented as per this comment

swanky/scuttlebutt/src/hash_aes.rs

Line 44 in bf632db

/// function and `σ(x₀ || x₁) = (x₀ ⊕ x₁) || x₁`.

which is not correct. It should be σ(x₀ || x₁) = (x₀ ⊕ x₁) || x₀ <-- the second half must be replaced by the first half.

Can I use fancy garbling for three party computation?

For example, among three parties, we have a garbler and an evaluator, there is another party providing the inputs. Can the third party get labels from the garbler via OT then send labels to evaluator? Can I implement such a scenario using this library?

is using a TCCR hash with random OT KOS safe?

Hi, ocelot currently uses a TCCR hash for breaking correlations after the KOS check acc.to this line

swanky/ocelot/src/ot/kos.rs

Line 106 in bf632db

let y0 = self.ot.hash.tccr_hash(Block::from(j as u128), q) ^ input.0;

However, the security proof of the KOS paper uses a random oracle.

Since we are also implemting a KOS OT extension, we're trying to understand has there been any recent work which proves KOS security with a TCCR hash? Or is this a liberty that ocelot is taking without relying on a formal proof?

Thanks.

Replace custom aes library with existing rust library

Fix Popsicle's Cuckoo Hashing

Issue:
Currently popsicle's cuckoo hashing has a bug where it is always full and fails for certain numbers like 100,000 and larger powers of 10.

Solution:
Use ocelot's cuckoo hash instead and turn popsicle's cuckoo hash into a wrapper for ocelot's.

Tests do not pass with alternative AES circuits.

Hi, I tried to plug in the aes_128.txt circuit from https://homes.esat.kuleuven.be/~nsmart/MPC/ by first "downgrading" its header into the old format:

36663 36919
128 128  128 

and also changing key,msg input ordering and reversing the output bits.

It passed the first 2 tests in parser.rs but failed on the 3rd:

swanky/fancy-garbling/src/parser.rs

Lines 191 to 196 in 4455754

	let mut key = vec![0u16; 128];
	for i in 0..8 {
	key[i] = 1;
	}
	let pt = vec![0u16; 128];
	let output = circ.eval_plain(&pt, &key).unwrap();

Then I took another AES circuit from here https://github.com/n-for-1-auth/circuits/tree/main/aes (aes128_full.txt) , adjusted input/output ordering and set its header to

36548 36804
128 128 128

this time the test failed on test2

How can such non-deterministic behaviour happen? Does swanky choose different code paths based on the gate ordering of the circuit?
Either way, you probably want to look at this as some corner case is triggering a bug.

KOS OT flaw pointed out by Roy 2022

Hi,

I was browsing your OT protocols and noticed that Keller, Orsini, and Scholl (KOS) have posted an "update" to their paper acknowledging a flaw pointed out by Roy.

I haven't begun to dig into what precisely is happening but it looks like:

• The KOS protocol now lacks a security proof.
• There is a proposed fix to the original protocol [but it still lacks a security proof it seems?]

Fix ci build for stable

The current stable build in travis-ci fails because we use the --features argument, which no longer exists. We should probably fix that.

fancy-garbling test failures

When I run the fancy-carbling test without cargo test, the following error occurs：

failures:

---- parser::tests::test_gc_eval stdout ----
thread 'parser::tests::test_gc_eval' panicked at 'called Result::unwrap() on an Err value: IoError(Os { code: 2, kind: NotFound, message: "No such file or directory" })', fancy-garbling/src/parser.rs:209:72
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

---- parser::tests::test_parser stdout ----
thread 'parser::tests::test_parser' panicked at 'called Result::unwrap() on an Err value: IoError(Os { code: 2, kind: NotFound, message: "No such file or directory" })', fancy-garbling/src/parser.rs:180:68

---- twopac::semihonest::tests::test_aes stdout ----
thread 'twopac::semihonest::tests::test_aes' panicked at 'called Result::unwrap() on an Err value: IoError(Os { code: 2, kind: NotFound, message: "No such file or directory" })', fancy-garbling/src/twopac/semihonest/mod.rs:110:68

Questions about ocelot choices

I'm to understand the rational for ocelot's implementation choices.

Is there any reason why ocelot does not implement the IKNP OT Extension?

Why does ocelot implement two OT extensions that use Chou-Orlandi as the base OT (as listed in swanky/ocelot/src/ot/mod.rs ) but none that use Naor-Pinkas as the base OT?

Thank you!

Assume `std::io::Read` and `std::io::Write` for `AbstractChannel`?

It seems like all the implementations (so far) are parameterized by types that satisfy these traits already (e.g. https://github.com/GaloisInc/swanky/blob/master/scuttlebutt/src/channel/sync_channel.rs#L38). For example,

pub trait AbstractChannel: std::io::Read + std::io::Write {
...
}

Again, not urgent, just documenting for the future.

The correctness of the garbler result

Hi,

I am using the semihonest_2pc.rs in examples for testing some garbled circuit txts. I found that the sha256 circuit comes from https://homes.esat.kuleuven.be/~nsmart/MPC/old-circuits.html where it provides some test vectors. However, I found that the result is not compatible with the given ones...

There are only one correct with all 1 (0xffff.ffff) as the first (garbler) input, but the remaining aren't... I did think of the endian problem, but the case with all 1 is correct and all 0 is not correct...

Could anyone give me some help or any approaches?

Thank you very much!