On the theoretical gap between synchronous and asynchronous MPC protocols

Abstract

Multiparty computation (MPC) protocols among n parties secure against t active faults are known to exist if and only if• t < n/2, when the channels are synchronous, and • t < n/3, when the channels are asynchronous, respectively. In this work we analyze the gap between these bounds, and show that in the cryptographic setting (with setup), the sole reason for it is the distribution of inputs: given an oracle for input distribution, cryptographically-secure asynchronous MPC is possible with the very same condition as synchronous MPC, namely t < n/2. We do not know whether the gaps in other security models (perfect, statistical) have the same cause. We stress that all previous asynchronous MPC protocols inherently require t < n/3, even once inputs are distributed. In particular, all published asynchronous multiplication sub-protocols inherently require t < n/3 and cannot be used in our setting.Furthermore, we show that such an input-distribution oracle can be reduced to an oracle that allows each party to synchronously broadcast one single message. This means that when one single round of synchronous broadcast is available, then asynchronous MPC is possible at the same condition as synchronous MPC, namely t < n/2. If such a round cannot be used, then MPC (and even Byzantine agreement) requires t < n/3.

Asynchronous MPC with a strict honest majority using non-equivocation

“…Nevertheless, as detailed in our protocol overview (Section 2), secret-sharing based AMPC with n = 2t + 1 and O(n 3 κ) communication complexity (per multiplication) presents several interesting challenges. As a result the NeqAMPC protocol is significantly different than those in the literature [HNP05,HNP08,BTH07,BTHN10].…”

“…The weaker restrictions on the adversary in the asynchronous model not only worsen the required resiliency conditions and communication complexities, but also make designing protocols a more challenging task; intuitively this is because in a completely asynchronous setting, it is not possible to distinguish between a slow (but honest) sender and a crashed sender. Due to this, at any Our protocol, called NeqAMPC , improves upon the previous AMPC protocol [BTHN10] with n ≥ 2t + 1 in the following ways:…”

“…The NeqAMPC protocol needs a transferable non-equivocation mechanism, but unlike [BTHN10] neither makes a synchronous broadcast round assumption nor requires a threshold homomorphic encryption setup. Given the feasibility of realizing transferable non-equivocation over prevelent computing devices, we argue that transferable non-equivocation is a more practical assumption than the synchronous broadcast round assumption.…”

“…(b) Efficiency. For a security parameter κ, our AMPC protocol requires an amortized communication complexity of O(n 3 κ) bits per multiplication gate, which improves upon the AMPC protocol of [BTHN10] by a factor of Θ(n).…”

“…To reduce the setup assumptions for the NeqAMPC protocol, we avoid the traditional threshold additive homomorphic encryption based circuit evaluation approach as used in [HNP05,HNP08,BTHN10]. Instead, we employ a secret-sharing based circuit evaluation approach [BOGW88,CCD88,RBO89], where privacy of the computation is maintained via secret sharing.…”