Abstract

AbstractWe study the question of designing leakage-resilient secure computation protocols. Our model is that of only computation leaks information with a leak-free input encoding phase. In more detail, we assume an offline phase called the input encoding phase in which each party encodes its input in a specified format. This phase is assumed to be free of any leakage and may or may not depend upon the function that needs to be jointly computed by the parties. Then finally, we have a secure computation phase in which the parties exchange messages with each other. In this phase, the adversary gets access to a leakage oracle which allows it to download a function of the computation transcript produced by an honest party to compute the next outgoing message.We present two main constructions of secure computation protocols in the above model. Our first construction is based only on the existence of (semi-honest) oblivious transfer. This construction employs an encoding phase which is dependent of the function to be computed (and the size of the encoded input is dependent on the size of the circuit of the function to be computed). Our second construction has an input encoding phase independent of the function to be computed. Hence in this construction, the parties can simple encode their input and store it as soon as it is received and then later on run secure computation for any function of their choice. Both of the above constructions, tolerate complete leakage in the secure computation phase.Our second construction (with a function independent input encoding phase) makes use of a fully homomorphic encryption scheme. A natural question that arises is “can a leakage-resilient secure computation protocol with function independent input encoding be based on simpler and weaker primitives?”. Towards that end, we show that any such construction would imply a secure two-party computation protocol with sub-linear communication complexity (in fact, communication complexity independent of the size of the function being computed).Finally, we also show how to extend our constructions for the continual leakage case where there is: a one time leak-free input encoding phase, a leaky secure computation phase which could be run multiple times for different functionalities (but the same input vector), and, a leaky refresh phase after each secure computation phase where the input is “re-encoded”.Keywordsleakagesecure computationprotocolmalicious adversarycontinual leakagecommunication complexity

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.