Real-world offline phase implementation in MPC setting

Question

I've been reading up on various basic MPC primitives (multiplication, inversion, exponentiation and so on of secrets shared between multiple parties). One of the problems of implementing MPC in real-world is performance. One of the common solution trends is splitting of the protocols into offline (preprocessing) and online phases.

The more complicated and resource-intensive a computation is, the more we win by offloading it into the offline phase... and I am trying to imagine what would that mean in practice: I am imagining a constant stream of requests for some "business" functionality (say, for example, for computing AES), each of which requires for some (potentially multiple) preprocessed data pieces (say, Beaver Triples) to have already been prepared in the offline phase... so, basically, an even (computationally) bigger stream of "offline" processing to be happening in the background...

My own vision includes either computing such offline resources in background when the "business" load is lower, pooling those in some storage (which is also sensitive, I guess?) or trying to offload the preprocessing into separate processes (servers?).

So, my main question is: Are there any works/guidelines that discuss the way to implement such offline phase(s) in practice?

Answer 1

I don't think there are some guidelines as such. However, different approaches have been considered.

A common consideration across several implementations that aim at making these things more accessible in practice (e.g. TF-Encrypted, or PySyft) is to consider a third trusted party that distributes the necessary preprocessing material before the computation starts. This, however, introduces different security assumptions and generates new potential points of failure.

Another approach that has been suggested in the literature consists of letting a set of servers produce triples "as a service" towards the servers requiring the computation. This would reduce the single point of failure that an individual preprocessing producer would imply.

This is all, however, research literature. I am not aware of any actual deployment of protocols with heavy preprocessing, nor any guidelines about how to do so. Also, there is an argument that this idea of the preprocessing not "mattering" so much, due to it being input-independent, is not that valid in practice. For actively secure 2-party protocols, the preprocessing can really take a large amount of time with respect to the online phase, so in a real scenario in which you get a constant flow of computation requests, it is more accurate to count end-to-end running times.

Finally, heavy preprocessing times are common in the dishonest majority setting, but when you're willing to assume that the adversary corrupts at most a strict minority of the parties, we can find protocols with very cheap preprocessing, or even no preprocessing at all. This is common in the $3$-party setting (with $1$ corruption), so I'd expect a real deployment in practice to make use of one of these settings, instead of, say, $2$ parties.