1 / 13

Distributed Secure Multiparty Computations in Hostile Environments

Distributed Secure Multiparty Computations in Hostile Environments. by Joel Dominic, James Hunt, and Adam Mcculloch. Content. The Encryption M ethod Used The Problem Our Solution Conclusion. Asymmetric Encryption. Sender's Encryption Key. Receiver’s Decryption Key.

awen
Download Presentation

Distributed Secure Multiparty Computations in Hostile Environments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Distributed Secure Multiparty Computations in Hostile Environments by Joel Dominic, James Hunt, and Adam Mcculloch

  2. Content • The Encryption Method Used • The Problem • Our Solution • Conclusion

  3. Asymmetric Encryption Sender's Encryption Key Receiver’s Decryption Key

  4. Why Use Multiparty Computations • Allows low end machines to quickly complete computations that would otherwise take a great amount of time. • It frees up processing power on the base machine without effecting the time it takes to solve a problem. • It allows cooperative work within a non-geographic specific network.

  5. Why Secure Multiparty Computations • When computing sensitive information, some malicious entities outside the network may attempt to sniff out secure information. • Malicious entities may penetrate the network and try to feed false results or otherwise disrupt the computation. • Not all parties involved in computing the data may not have the authorization to view the end result.

  6. Securely Computing a Function Over a Network

  7. Our Goal Securely computing data across a network not only securing the integrity of the data itself but also the place each machine has in the computation

  8. Disclaimer Our solution should only be used in situations where the data to be computed must remain secure but is NOT time critical. Our approach results in a secure computation of the input set but the methods used will severely impact time and resource efficiency.

  9. Step One Take the all the operations to be solved and break them into a sequence of independent stand-alone (atomic) functions.

  10. Step Two • The Host machine generates n+1 asymmetric key combinations (where n is the number of functions) • Each function is then wrapped in a mobile agent in such a way that: • Encrypt keys 2 .. n+1 are added before functions 1 .. n • Decrypt keys 1 .. n are added after functions 1 .. n • The host holds onto encrypt key 1 and decrypt key n+1 • Each function is then randomly distributed to a machine in the computation network

  11. Step Three • The host machine broadcasts the initial encrypted input across the network. • Every machine in the network receives the encrypted information and attempts to decrypt it • If successful: • the atomic function is performed • the information is re-encrypted and broadcast out to the network • Mobile agent ignores all other input for this stage • If unsuccessful: • the information is discarded • if there is no more input for this stage, mobile agent broadcasts ‘junk data’

  12. Conclusion Our solution allows for data to be securely computed across a network without compromising the integrity of the data OR the functions involved

  13. References • Ishai, Yuval, EyalKushilevitz, RafailOstrovsky, and AmitSahai. "Zero- Knowledge Proofs from Secure Multiparty Computation." SIAM Journal on Computing 39.3 (2009): 1121. Print. • Backes, Michael, and Dominique Unruh. "Computational Soundness of Symbolic Zero-knowledge Proofs." Journal of Computer Security 18 (2010): 1077-155. Print.

More Related