fully homomorphic encryption
play

Fully Homomorphic Encryption Zvika Brakerski Weizmann Institute of - PowerPoint PPT Presentation

Fully Homomorphic Encryption Zvika Brakerski Weizmann Institute of Science AWSCS, March 2015 Outsourcing Computation () Email, web- search, navigation, social networking Search query, location, business


  1. Fully Homomorphic Encryption Zvika Brakerski Weizmann Institute of Science AWSCS, March 2015

  2. Outsourcing Computation 𝑦 𝑦 𝑔 𝑔(𝑦) Email, web- search, ¡navigation, ¡social ¡networking… Search query, location, business information, ¡medical ¡information… What if 𝑦 is private?

  3. The Situation Today We promise we wont look at your data. Honest! We want real protection.

  4. Outsourcing Computation – Privately Learns nothing on 𝑦 . 𝐹𝑜𝑑(𝑦) 𝑦 𝑔 𝑧 𝐸𝑓𝑑 𝑧 = 𝑔(𝑦) WANT NTED Homomorphic Evaluation function: 𝐹𝑤𝑏𝑚: 𝑔, 𝐹𝑜𝑑 𝑦 → 𝐹𝑜𝑑(𝑔 𝑦 )

  5. Fully Homomorphic Encryption (FHE) 𝑡𝑙 , 𝑞𝑙 𝑓𝑤𝑙 𝐹𝑜𝑑 �� (𝑦) 𝐹𝑜𝑑(𝑦) 𝑦 𝑔 𝑧 = 𝐹𝑤𝑏𝑚 ��� (𝑔, 𝐹𝑜𝑑 𝑦 ) 𝑧 Correctness: 𝐸𝑓𝑑 �� 𝑧 = 𝑔(𝑦) 𝐸𝑓𝑑 𝑧 = 𝑔(𝑦) Input privacy: 𝐹𝑜𝑑(𝑦) ≅ 𝐹𝑜𝑑(0) Fully Homomorphic = Correctness for any efficient 𝑔 = Correctness for universal set • NAND. • (+,×) over ℤ � (= binary 𝑌𝑃𝑆, 𝐵𝑂𝐸 )

  6. Trivial FHE? NOT ¡what ¡we ¡were ¡looking ¡for… PKE ⇒ ¡ “FHE”: All work is relayed to receiver. - 𝐿𝑓𝑧𝑕𝑓𝑜 and 𝐹𝑜𝑑 : Same as PKE. - 𝐹𝑤𝑏𝑚 ��� 𝑔, 𝑑 ≜ (𝑔, 𝑑) ��� (𝑔, 𝑑) ≜ 𝑔(𝐸𝑓𝑑 �� (𝑑)) - 𝐸𝑓𝑑 �� = 𝑔 𝐸𝑓𝑑 �� 𝐹𝑜𝑑 𝑦 = 𝑔(𝑦) 𝐹𝑜𝑑 (𝑦) Compact FHE: 𝐸𝑓𝑑 time does not depend on ciphertext. ⇒ ciphertext length is globally bounded. In this talk (and in literature) FHE ≜ Compact-FHE

  7. Trivial FHE? PKE ⇒ ¡ “FHE”: This ¡“scheme” ¡also ¡completely ¡ reveals 𝑔 to the receiver. - 𝐿𝑓𝑧𝑕𝑓𝑜 and 𝐹𝑜𝑑 : Same as PKE. Can be a problem. - 𝐹𝑤𝑏𝑚 ��� 𝑔, 𝑑 ≜ (𝑔, 𝑑) ��� (𝑔, 𝑑) ≜ 𝑔(𝐸𝑓𝑑 �� (𝑑)) - 𝐸𝑓𝑑 �� Circuit Privacy: Receiver learns nothing about 𝑔 (except output). Compactness ⇒ Circuit Privacy (by complicated reduction) [GHV10] Circuit private FHE is not trivial to achieve – even non-compact. In this talk: Only care about compactness, no more circuit privacy.

  8. Applications In the cloud: • Private outsourcing of computation. • Near-optimal private outsourcing of storage (single-server PIR). [G09,BV11b] • Verifiable outsourcing (delegation). [GGP11,CKV11,KRR13,KRR14] • Private machine learning in the cloud. [GLN12,HW13] Secure multiparty computation: • Low-communication multiparty computation. [AJLTVW12,LTV12] • More efficient MPC. [BDOZ11,DPSZ12,DKLPSS12] Primitives: • Succinct argument systems . ¡[GLR11,DFH11,BCCT11,BC12,BCCT12,BCGT13,…] • General functional encryption. [GKPVZ12] • Indistinguishability obfuscation ¡for ¡all ¡circuits. ¡[GGHRSW13,…]

  9. Verifiable Outsourcing (Delegation) 𝑦 𝑦 𝑔 𝑔(𝑦) , 𝜌 What if the server is cheating? Can send wrong value of 𝑔(𝑦) . Need proof!

  10. FHE ⇒ Verifiable Outsourcing FHE ⇒ Verifiability and Privacy. 1. Verifiability ¡with ¡preprocessing ¡under ¡“standard” ¡ assumptions: [GGP10, CKV10,KRR13,KRR14] . 2. Less standard assumptions but without preprocessing via SNARGs/SNARKs [DCL08,BCCT11,…] (uses FHE or PIR). Pre-FHE solutions: multiple rounds [K92] or random oracles [M94].

  11. FHE ⇒ Verifiable Outsourcing [CKV10] But preprocessing is as hard as computation! Preprocessing: 𝑡𝑙 , 𝑞𝑙 𝑓𝑤𝑙 𝑑 � = 𝐹𝑜𝑑(0) 𝑨 � = 𝐹𝑤𝑏𝑚(𝑔, 𝑑 � ) 𝑑 � = 𝐹𝑜𝑑 𝑦 , 𝑑 � 𝑦 𝑔 𝑧 � , 𝑧 � Verification: Check 𝑧 � = 𝑨 � ? Server executes Yes ⇒ output 𝐸𝑓𝑑(𝑧 � ) 𝑧 = 𝐹𝑤𝑏𝑚(𝑔, 𝑑) No ⇒ output ⊥ Idea: “Cut ¡and ¡choose” 𝑑 � , 𝑑 � look the same ⇒ ¡ cheating server will be caught w.p. ½ (easily amplifiable)

  12. FHE ⇒ Verifiable Outsourcing [CKV10] Preprocessing: 𝑡𝑙 , 𝑞𝑙 𝑓𝑤𝑙 𝑑 � = 𝐹𝑜𝑑(0) 𝑨 � = 𝐹𝑤𝑏𝑚(𝑔, 𝑑 � ) (𝑓𝑤𝑙 �� , 𝐹𝑜𝑑 �� 𝑑 � ), (𝑓𝑤𝑙 � , 𝐹𝑜𝑑 � 𝑑 � ) 𝑦 𝑔 𝑧′′ � , 𝑧′ � Verification: Check 𝐸𝑓𝑑′(𝑧′ � ) = 𝑨 � ? Server executes 𝑧′ = 𝐹𝑤𝑏𝑚′(𝐹𝑤𝑏𝑚 𝑔,⋅ , 𝑑 � ) Yes ⇒ output 𝐸𝑓𝑑′′(𝐸𝑓𝑑 𝑧 � ) 𝑧′′ = 𝐹𝑤𝑏𝑚′′(𝐹𝑤𝑏𝑚 𝑔,⋅ , 𝑑 �� ) No ⇒ output ⊥ Server is not allowed to know if we accept/reject! Idea: Outer ¡layer ¡keeps ¡server ¡“oblivious” ¡of ¡ 𝑨 � . ⇒ ¡ Can recycle 𝑨 � for future computations.

  13. FHE Timeline Basic scheme: Ideal cosets in polynomial rings. ⇒ ¡ Bounded-depth homomorphism. - Assumption: hardness of (quantum) apx. short 30 years of hardly scratching vector in ideal lattice. the surface: Bootstrapping: bounded-depth HE ⇒ full HE. • Only-addition [RSA78, R79, GM82, But ¡bootstrapping ¡doesn’t ¡apply ¡to ¡basic ¡scheme... G84, P99, R05] . • Addition + 1 multiplication - Need additional assumption: hardness of sparse [BGN05, GHV10] . subset-sum. • Other variants [SYY99, IP07, MGH10] . … ¡is ¡it ¡even ¡possible?

  14. The FHE Challenge Make it simpler. Simplified basic scheme [vDGHV10,BV11a] - Under similar assumptions. Make it more secure. ? Make it practical. Optimizations [SV10,SS10,GH10]

  15. FHE without Ideals [BV11b] Linear algebra instead of polynomial rings Assumption: Apx. short vector in arbitrary lattices (via LWE). Shortest-vector Problem (SVP): Fundamental algorithmic problem – extensively studied. [LLL82,K86,A97,M98,AKS03,MR04,MV10]

  16. FHE without Ideals [BV11b] Linear algebra instead of polynomial rings Assumption: Apx. short vector in arbitrary lattices (via LWE). • Basic scheme: noisy linear equations over ℤ � . – Ciphertext is a linear function 𝑑(𝑦) s.t. 𝑑 𝑡𝑙 ≈ 𝑛 . – Add/multiply functions for homomorphism. – Multiplication raises degree ⇒ use relinearization . • Bootstrapping: Use dimension-modulus reduction to shrink ciphertexts. • Concurrently [GH11]: Ideal Simpler: straightforward presentation. lattice based scheme without • More secure: based on a standard assumption. squashing. • Efficiency improvements.

  17. FHE without Ideals Follow-ups: • [BGV12] : Improved parameters. – Even better security. – Improved ¡efficiency ¡in ¡ring ¡setting ¡using ¡“batching”. – Batching without ideals in [BGH13]. • [B12] : Improved security. – Security based on classical lattice assumptions. – Explained in blog post [BB12]. Various optimizations, applications and implementations: [LNV11, GHS12a, GHS12b, GHS12c, GHPS12, AJLTVW12, LTV12, DSPZ12, ¡FV12, ¡GLN12, ¡BGHWW12,HW13 ¡…]

  18. The ¡“Approximate ¡Eigenvector” ¡ Method [GSW13] Ciphertexts = Matrix Same assumption and keys as before – ciphertexts are different • Basic scheme: Approximate eigenvector over ℤ � . – Ciphertext is a matrix 𝐷 s.t. 𝐷 ⋅ 𝑡𝑙 ≈ 𝑛 ⋅ 𝑡𝑙 . – Add/multiply matrices for homomorphism*. • Bootstrapping: Same as previous schemes. • Simpler: straightforward presentation. • New ¡and ¡exciting ¡applications ¡“for ¡free”! ¡IB -FHE, AB-FHE. • Same security as [BGV12, B12]. • Unclear about efficiency: some advantages, some drawbacks.

  19. Sequentialization [BV14] What is the best way to evaluate a product of 𝑙 numbers? Sequential Parallel X X c 1 X vs. X X c 2 X c 1 c 2 c 3 c 4 c 3 c 4 Conventional wisdom Actually better (if done right)

  20. Sequentialization [BV14] Barrington’s ¡Theorem ¡[B86]: Every depth 𝑒 computation can be transformed into a width-5 depth 4 � branching program . A sequential model of computation • Better security – breaks barrier of [BGV12, B12,GSW13]. • Using dimension-modulus reduction (from [BV11b]) ⇒ same hardness assumption as non homomorphic encryption. • Short ciphertexts.

  21. FHE Over the Integers [DGHV09,CMNT11,CNT12,CCKLLTY13,CLT14] Parallel line of work: Similar construction using different assumptions. “Approximate ¡GCD” ¡Problem: ≅ similar to 1D lattice Ciphertexts = Number • Basic operations more straightforward details will not be discussed • Analogues ¡for ¡“batching”, ¡“scale ¡invariance”. in this course • Noise control more complicated. • Assumption less standard.

  22. Implementations • HElib (IBM/NYU) – Ring-LWE (ideal-lattice) scheme of [BGV12], optimizations of [GHS12a] – Most recent results [HS14a,HS14b] – https://github.com/shaih/HElib • hcrypt project – FHE over the integers [DGHV09] – https://hcrypt.com • “Stanford ¡FHE” – LWE scheme of [B12] with optimizations – http://cs.stanford.edu/~dwu4/fhe.html • Unpublished code – Ring-LWE implementation of [GHS12b]. – Over the integers implementation of [CCKLLTY13].

  23. Efficiency Standard benchmark: AES128 circuit Implementations of [BGV12] by [GHS12c] ≈ 5 sec/input 2-years ago it was 5 min/input, and in 2010 it was 5 min/ gate [GH10] Limiting factors: • Circuit representation. • Bootstrapping. • Key size. ⇒ ¡ To be practical, we need to improve the theory.

Recommend


More recommend