MPC-SoK / frameworks

Sample code and build environments for MPC frameworks
Other
487 stars 111 forks source link

add swanky framework #35

Closed marsella closed 3 years ago

marsella commented 4 years ago

Links:

To do: build environment, sample programs, documentation.

zenkuro commented 3 years ago

hi, is there any progress regarding this issue/task? Im thinking to start doing it, so checking in advance.

marsella commented 3 years ago

Nope, I haven't started this at all.

zenkuro commented 3 years ago

it took a bit of time passed. But. https://github.com/zenkuro/frameworks/tree/master/swanky

I was wandering if should I put more info about examples and what should I put?

zenkuro commented 3 years ago

Ive placed pull request. Would love to hear your feedback and propositions @marsella.

Also Im thinking about wrapping swanky in daemon-like grpc code. So user do not have to lear specific programing language.

I think that is a good general thing for crypto protocols since we know that most of them can be described as 'KeyGen, Enc, Dec' functions

marsella commented 3 years ago

Thanks! I will review this more carefully in a few days.

You're welcome to write some kind of useful wrapper for swanky, but I think such a thing does not belong in this repo. This is for demonstrating existing work, not adding new extensions. If you build it, we'd link to it in the Wiki, though.

zenkuro commented 3 years ago

@marsella , I was thinking about 'usability' of this framework.

  1. It is hard to use it since there is a lot of frameworks written in different languages. So developer/researcher have to know particular language to use it
  2. Im not fully understand organization of frameworks. In a same frameworks there are solutions like sharemind and libraries like swanky. From nooby-outsider perspective(like me) it is number of independent things brought together.

What I think can be done:

  1. Simplify interaction with a code base. Make it in a form so that other developers/researchers can easily use it by themselves with single easy to use language-agnostic interface. Crypto protocols very often looks like matryoshka doll. With one construction use another as an input. It should be easy for user to combine multiple constructions together in a single protocol. Unfortunately with current it is hard
  2. Provide classification. This project points itself as overview of existing protocols and implementations. I think it is natural to provide classification of protocols, solutions and libraries provided in it. It would be grate if it is done in a formal way, so that other people can come try out and learn from it.
marsella commented 3 years ago

When you say "framework," do you mean the swanky framework or this MPC-SoK repository? This response assumes the latter. If you have other large-scale questions or requests for the repo, I encourage you to make a separate issue to discuss them.

I sympathize with your concern that these frameworks are difficult to use. These are mainly academic projects and do not aim to provide production-quality software; this often manifests as minimal documentation and testing, and sometimes as confusing design choices. However, the project you propose is out of scope for this repository.

Simplify interaction with a code base. Make it in a form so that other developers/researchers can easily use it by themselves with single easy to use language-agnostic interface.

General-purpose MPC frameworks implement an extremely complex and flexible set of protocols. The ones in this repo (mostly) implement two parts: a compiler, which parses a function representation into an intermediate representation; and a runtime, which is executed jointly by each party, consuming the IR and the parties' inputs and producing the output of the function. These protocols typically require a great deal of setup (to produce correlated randomness, generate cryptographic keys and material for various sub-protocols, set up network connections, etc). These implementations are often tightly bound to specific choices and representations of this setup phase.

Unfortunately, there is no standard for the "API" of an MPC protocol. Consistent APIs exist for many "low level" primitives, like digital signatures, commitment schemes, or hash functions; these have two benefits over MPC. First, they are basically atomic functions, with well-defined inputs and outputs. Second, they have APIs and instantiations that have been standardized by bodies like NIST, and thus have widespread community buy-in and agreement. In contrast, there is no standardization even for the sub-protocols that MPC depends upon, like oblivious transfer, some flavors of secret-sharing, or circuit garbling.

The frameworks rarely agree even on an intermediate representation for the function description. This alone would make it extremely difficult to provide a general, language-agnostic interface compatible with all the software projects. You may be interested in some other projects that have started to develop frameworks that support a more general interface for combining privacy-related protocols [1], but I am not sure this provides the functionality you want.

Overall, MPC is achieving greater community and industry interest, and there will be greater momentum towards improving standardization and consistency across implementations, and in developing production-quality (rather than academic proof-of-concept) frameworks. However, I do not think the field is mature enough right now to support the project you propose. I know with certainty that I do not have the bandwidth to spearhead such a project.

Provide classification.

There is an enormous amount of classification of the software libraries in the paper, which contains an overview of the classification criteria and analysis of the first 11 frameworks, and the wiki, which has additional information about the newly added frameworks.

If there is a specific classification or criteria you'd like to see added to these tables, you can make a separate issue proposing it.

1: https://www.cs.cornell.edu/andru/papers/viaduct/viaduct-tr.pdf

marsella commented 3 years ago

I took a look at your PR this weekend. Unfortunately, I didn't realize that swanky doesn't include a front-end compiler. It looks like the user needs to generate their own circuits (e.g. for mult3, innerprod, xtabs) and plug them into the existing protocol implementation. That sadly makes it ineligible for inclusion in this repo.

Thanks for your work, anyway!

zenkuro commented 3 years ago

life is suffering... TT