2020 IEEE Symposium on Security and Privacy (SP) 2020
DOI: 10.1109/sp40000.2020.00016
|View full text |Cite
|
Sign up to set email alerts
|

Efficient and Secure Multiparty Computation from Fixed-Key Block Ciphers

Abstract: Many implementations of secure computation use fixed-key AES (modeled as a random permutation); this results in substantial performance benefits due to existing hardware support for AES and the ability to avoid recomputing the AES key schedule. Surveying these implementations, however, we find that most utilize AES in a heuristic fashion; in the best case this leaves a gap in the security proof, but in many cases we show it allows for explicit attacks.Motivated by this unsatisfactory state of affairs, we initi… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1
1
1

Citation Types

0
20
0

Year Published

2020
2020
2021
2021

Publication Types

Select...
5
3

Relationship

0
8

Authors

Journals

citations
Cited by 44 publications
(20 citation statements)
references
References 49 publications
0
20
0
Order By: Relevance
“…However, DeepSecure reports the number of non-XOR gates that can be used for performance estimates. We used state-of-the-art for GC implementation, i.e., EMP-Toolkit [1], [52], [53], to obtain these performance estimates that are better than the performance reported by DeepSecure. The communication of our protocols is 25× lower (4 th row of Table I).…”
Section: Discussionmentioning
confidence: 99%
“…However, DeepSecure reports the number of non-XOR gates that can be used for performance estimates. We used state-of-the-art for GC implementation, i.e., EMP-Toolkit [1], [52], [53], to obtain these performance estimates that are better than the performance reported by DeepSecure. The communication of our protocols is 25× lower (4 th row of Table I).…”
Section: Discussionmentioning
confidence: 99%
“…Factoring in the cost of securely distributing Gen (with semi-honest security, building on [Ds17]), the amortized communication complexity of our silent OT extension protocol is 0-3 bits for each random 128-bit string-OT. To put that into context, state-of-the-art OT extension protocols [IKNP03,ALSZ13] require 128 bits of communication per random 128-bit string-OT and can generate around 10 million OTs per second [GKWY19] over a fast network, so the price we pay for the (much) lower communication complexity seems quite modest. Even for the easier case of random bit-OT, the best previous OT extension protocol [KK13] required roughly 80 bits of communication per OT.…”
Section: Silent Ot Extensionmentioning
confidence: 99%
“…We use the following generalization of a correlation robust function over F p . As recently shown in [GKWY19], this can be instantiated with fixed-key AES modeled as a random permutation when p = 2.…”
Section: Al [Iknp03] Which Convertsmentioning
confidence: 99%
“…Our protocol makes ℓ/𝑚 calls to 𝑀 1 -OT 2 (after merging steps 9&10), where 𝑀 = 2 𝑚 . Using OT extension techniques, generating an instance of 𝑀 1 -OT 2 requires 6 AES FK 256 9 There are two types of AES in MPC applications -fixed-key (FK) and re-keyed (RK) [10,35]. While the former runs key schedule only once and is more efficient, the latter generates a new key schedule for every invocation and is required in this application.…”
Section: Cryptographic Backendmentioning
confidence: 99%