LogStack: Stacked Garbling with O(b log b) Computation
LogStack: Stacked Garbling with O(b log b) Computation
复制标题
DOI:
10.1007/978-3-030-77883-5_1
复制
发表时间:
2021
期刊:
影响因子:
--
通讯作者:
David Heath;V. Kolesnikov
中科院分区:
文献类型:
--
作者:
David Heath;V. Kolesnikov
Secure two party computation (2PC) of arbitrary programs can be efficiently achieved using garbled circuits (GC). Until recently, it was widely believed that a GC proportional to the entire program, including parts of the program that are entirely discarded due to conditional branching, must be transmitted over a network. Recent work shows that this belief isfalse, and that communication proportional only to the longest program execution path suffices (Heath and Kolesnikov, CRYPTO 20, ). Although this recent work reduces needed communication, itincreasescomputation. For a conditional withbbranches, the players usecomputation (traditional GC uses onlyO(b)).Our schemereduces stacked garbling computation fromtowithnoincrease in communication over . The cause of ’s increased computation is the oblivious collection ofgarbage labelsthat emerge during the evaluation of inactive branches. Garbage is collected by amultiplexerthat is costly to generate. At a high level, we redesign stacking and garbage collection to avoid quadratic scaling.Our construction is also morespace efficient: algorithms requireO(b) space, while ours use onlyspace. This space efficiency allows even modest setups to handle large numbers of branches.assumes a random oracle (RO). We track the source of this need, formalize a simple and natural added assumption on the base garbling scheme, and remove reliance on RO:is secure in the standard model. Nevertheless,can be instantiated with typical GC tricks based on non-standard assumptions, such as free XOR and half-gates, and hence can be implemented with high efficiency.We implemented(in the RO model, based on half-gates garbling) and report performance. In terms of wall-clock time and for fewer than 16 branches, our performance is comparable to ’s; for larger branching factors, our approach clearly outperforms . For example, given 1024 branches, our approach isfaster.