MPC Framework Wishlist

[voltrevo]

Hey there! In MPC Framework we currently primarily use emp-toolkit for a malicious secure backend. We're super interested in using mpz instead in the future, and we already have mpz-ts utilizing an old version of mpz for not-malicious-secure garbling.

I'm not sure whether having a wishlist issue is compatible with your process, but please consider the following and feel free to split up/capture these in a way that makes more sense for you.

• Authenticated garbling
• N-party authenticated garbling
• wasm compatibility
  • possibly avoid simd
  • possibly avoid openssl (when porting emp-toolkit I had to replace it with mbedtls)
  • option to not use threading (or figuring out why that was an issue in the past and possibly fixing it)
• Incremental/streaming preprocessing
  • Doing this all upfront consumes a lot of memory. Much larger circuits should be possible if this can be done as-needed instead.

[sinui0]

Hey!

wasm

mpz is already compatible with WASM. We don't use SIMD directly anywhere and Rust will conditionally turn it off depending on enabled target features. mpz is also transport agnostic, we don't have any dependencies to deal with there. Multi-threading can be disabled by turning off the rayon feature on whichever crates you're using. Although, it does work in the browser using the wasm-bindgen-rayon shim. Browser runtimes do not support the WASM threads extension, which is one reason we don't have any hard dependency on std::thread anywhere.

streaming

Our GC VM does stream the garbled circuits :)

auth garbling

@nakkstar123 is currently implementing authenticated garbling (see #217), so it should be available soon.

n-party garbling

We don't have any imminent need for >2PC ourselves, but it is a future nice to have along with a motivating usecase. It would require a fair bit of work developing the interface for it. Our abstractions are mostly oriented around 2 party semantics.

---

Take a look at the alpha.1 branch if you're wanting to see the current state of mpz. We should be cutting a release for it within a couple weeks.

Likely the biggest integration hurdle you are likely to face is compiling user programs. Our circuit model is on its way out, but in the meanwhile it does support parsing bristol fashion.

[voltrevo]

wasm

mpz is already compatible with WASM. We don't use SIMD directly anywhere and Rust will conditionally turn it off depending on enabled target features. mpz is also transport agnostic, we don't have any dependencies to deal with there. Multi-threading can be disabled by turning off the rayon feature on whichever crates you're using. Although, it does work in the browser using the wasm-bindgen-rayon shim. Browser runtimes do not support the WASM threads extension, which is one reason we don't have any hard dependency on std::thread anywhere.

streaming

Our GC VM does stream the garbled circuits :)

auth garbling

@nakkstar123 is currently implementing authenticated garbling (see #217), so it should be available soon.

Awesome 🙌

n-party garbling

We don't have any imminent need for >2PC ourselves, but it is a future nice to have along with a motivating usecase. It would require a fair bit of work developing the interface for it. Our abstractions are mostly oriented around 2 party semantics.

Gotcha. Discussed on on discord.

Take a look at the alpha.1 branch if you're wanting to see the current state of mpz. We should be cutting a release for it within a couple weeks.

👍

Likely the biggest integration hurdle you are likely to face is compiling user programs. Our circuit model is on its way out, but in the meanwhile it does support parsing bristol fashion.

Ah ok, that should be fine, we have bristol output :).