non-interactive secure computation from one-way functions · secure two party computation p 1 p 2...
TRANSCRIPT
Non-InteractiveSecureComputationfromOne-WayFunctions
SaikrishnaBadrinarayanan Abhishek Jain(UCLA) (JHU)
Rafail Ostrovsky IvanVisconti(UCLA) (UniversityofSalerno)
SecureTwoPartyComputation
P1 P2
Inputx Inputy
Functionf
Goal:Bothpartieswishtorunaprotocolattheendofwhichtheybothlearntheoutputofthefunctionontheirjointinputs.
SecureTwoPartyComputation
P1 P2
Inputx Inputy
Functionf
Security:Informally,adversaryshouldnotlearnanythingaboutyotherthanf(x,y)!
UC-SecureComputation[Canetti01]
P1 P2Inputx1 Inputx2
P3Inputz3
Inputy1
Inputy3
Inputz2
P4
Inputw4
Inputw2
Manysessionsareexecutedinparallel
Functionf
Functiong Functionp
UC-SecureComputation[Canetti01]
P1 P2Inputx1 Inputx2
P3Inputz3
Inputy1
Inputy3
Inputz2
P4
Inputw4
Inputw2
Informally,adversaryshouldnotlearnanythingotherthanfunctionoutputs!
Functionf
Functiong Functionp
Continued..
• Numerousapplications• Unfortunately,impossibletoconstructwithoutasetup
assumption!
SetupAssumptions• CommonReferenceString[Canetti-Lindell-
Ostrovsky-Sahai 02]
• PhysicalAssumptions– HardwareTokens[Katz07]
– PhysicallyUncloneable Functions(PUFs)
Focusofthispaper
HardwareTokens[Katz07]
• Apieceofhardwarethatcanevaluateanyfunction(embeddedinsideit)oninputqueries.
• Physicalmanifestationofidealobfuscation?• Difference:Needthehardwareobjectinhandtobeableto
queryandrecoveroutput.
Inputx Outputf(x)Functionf
TypesofHardwareTokens
• Stateless:– Honesttokendoesnothaveanymemoryacrossinvocations.
• Stateful:– Tokencanmaintainmemory.– Hardertodesignsuchtokens.– Easiertodesignprotocolsusingthem.
Focusofthistalk
Challenge:Adversarialtokenscanbestateful!
MotivatingScenario
Input:DNADatax
Encrypt(x)
Encryptf(x)
Decryptandlearnf(x)=listofrelativesGoal:Alicewantstopublishanencryptionofher
privateDNAdatatoanorganizationthatcancomputethesetofrelativesofagivenDNAsample.
Securityrequirement:Alice’sprivatedataandcompany’sdatashouldbehidden.
Reusablemessage
Input:DNAmatchingalgorithm
Non-interactivesecurecomputation(NISC)[IKOPS’11]
• Formalizesthescenariointhepreviousslide.
Input:xEncrypt(x)
Input:y
Encryptf(x,y)
Decryptandlearnf(x,y)
Securityrequirement:asinstandardtwopartycomputation
Reusablemessageforinputx
Priorwork
• [IKOPS11]:NISCinOTHybridmodel.• [AMPR14,MR17]: NISCinCRSmodelfromOT+onewayfunctions.
• [CJS14]:UC-secureNISCinGlobalRandomOraclemodelfromOT+onewayfunctions.
• [BGISW17]:NISCinplainmodelfromsub-exponentiallysecureOT+onewayfunctions.
Question
• CanweachieveNISCfromtheminimalassumptionofOne-WayFunctions?
• Further,canweachieveUCsecurity?
OurResult
• UC-securenon-interactivesecurecomputationassumingone-wayfunctionsusingasinglestatelesshardwaretoken.
• Optimalintermsofassumptionsandnumberoftokens.
• AchievesUCsecurityunlikeallpriorworkexceptCJS14.
OurResults:Corollary
• TwomessageUC-securetwopartycomputationwherebothpartiesreceiveoutput,assumingonewayfunctions usingasinglestatelesshardwaretoken.
Techniques
Tokendirection:Priorworks
Receiver:inputxSender:inputy
.
.
.
Issuesinoursetting:1. Needafreshtokenforeachnewinteractionwitha
fixedreusablereceivermessage.2. Allpriorworksrequireatleast tworoundsof
interactionaftersendertoken.
Inallpriorworks,tokensentbythesender.
Solution:TokenfromReceiver
Receiver:inputxSender:inputy
message
Reusablex
MainChallenge:ResettingAttacks
1. Howtopreventsenderfromresettingthetokenandtryingdifferentinputsy?
2. Needthereceivertoauthenticatethesender’sinputtothetokenbeforeitprocessedbythetoken.
3. Butthatwilltakeatleast2rounds!
Solution:1. Weallowthesendertoresetthetoken!2. However,tokeniscarefullydesignedtoperformonly
“encrypted”computationthatislaterdecryptedbythereceiver.
3. Hence,evenontryingdifferentinputs,senderdoesn’tlearnanythingmeaningfulfromthetoken.
OtherChallenges
• Selectiveabortattacks.• Subliminalchannelinformationthroughtoken.
• AchievingstraightlinesimulationtogetUCsecurity.
• Pleaserefertothepaperformoredetails!https://eprint.iacr.org/2018/1020