Presentation is loading. Please wait.

Presentation is loading. Please wait.

China Summer School on Lattices and Cryptography Craig Gentry and Shai Halevi June 3, 2014 Somewhat Homomorphic Encryption.

Similar presentations


Presentation on theme: "China Summer School on Lattices and Cryptography Craig Gentry and Shai Halevi June 3, 2014 Somewhat Homomorphic Encryption."— Presentation transcript:

1 China Summer School on Lattices and Cryptography Craig Gentry and Shai Halevi June 3, 2014 Somewhat Homomorphic Encryption

2 Part 1: Homomorphic Encryption: Background, Applications, Limitations

3 Computing on Encrypted Data Can we delegate the processing of data, without giving away access to it. Example App:Cloud computing Safe to store your data in the cloud unencrypted??

4 Encrypted Cloud Computing Alice Server (Cloud) (Input: data x, secret key sk) “I want 1) the cloud to process my data 2) even though it is encrypted. Enc pk [ f(x) ] Enc pk (x) function f f(x) Run Eval[ f, Enc pk (x) ] = Enc pk [f(x)] The special sauce! For security parameter λ, Eval’s running should be Time(f) ∙ poly( λ ) This could be encrypted too. Delegation: Should cost less for Alice to encrypt x and decrypt f(x) than to compute f(x) herself.

5 Homomorphic Encryption (HE)  Procedures: KeyGen, Encrypt, Decrypt, Eval  Correctness: For any function f in “admissible” family F: c 1 ← Enc pk (m 1 ) … c t ← Enc pk (m t ) c ← Eval pk (f, c 1, …, c t ) Dec sk (c) = f(m 1, …, m t )  Semantic Security: same as for basic encryption

6 Homomorphic Encryption Somewhat Homomorphic Encryption (SWHE): “Somewhat” means it works for some functions f Enc[f(x)] Enc[x] f Eval  Pre-2009 schemes were somewhat homomorphic.  Analogous to a glovebox with “clumsy” gloves.

7 Homomorphic Encryption Fully Homomorphic Encryption (FHE) [RAD78, Gen09]: “Fully” means it works for all functions f Enc[f(x)] Enc[x] f Eval

8 A way to delegate processing of your data, without giving away access to it.  Fully Homomorphic Encryption (FHE):  Arbitrary processing  But computationally expensive.  Somewhat Homomorphic Encryption (SWHE):  Limited processing  Cheaper computationally. Homomorphic Encryption Basics

9 An Analogy: Alice’s Jewelry Store  Alice wants workers to assemble raw materials into jewelry  But Alice is worried about theft: She wants workers to process raw materials without having access.  Alice puts raw materials in locked glovebox.  Workers assemble jewelry inside glovebox, using the gloves.  Alice unlocks box to get “results”.

10 Functionality

11  Forget encryption for a moment…  How does your computer compute a function?  Basically, by working on bits, 1’s and 0’s.  Using bit operations – for example,  AND(b 1,b 2 )=1 if b 1 =b 2 =1 ; otherwise, equals 0. AND(b 1,b 2 )= b 1 × b 2.  XOR(b 1,b 2 )=0 if b 1 =b 2 ; equals 1 if b 1 ≠b 2. XOR(b 1,b 2 )= b 1 +b 2 (modulo 2) Processing (Unencrypted) Data

12  {ADD,MULT} are Turing-complete (over any ring).  Take any (classically) efficiently computable function.  Express it as a poly-size circuit of ADD and MULT gates.  Circuits vs. Turing machines (about the same):  Circuit size = O(T f log T f ) T f = time to compute f on a TM Computing General Functions

13  Let b denote a valid encryption of bit b. Let’s Do This Encrypted…

14  Let b denote a valid encryption of bit b.  Suppose we have a (homomorphic) encryption scheme with public functions E-ADD, E-MULT where: for any b 1 and b 2.  Then we can AND and XOR encrypted bits.  Proceeding bit-wise, we can compute any function on encrypted data. Let’s Do This Encrypted… E-MULT( b 1,b 2 ) = b 1 x b 2 E-ADD(b 1,b 2 ) = b 1 +b 2

15 Security

16  Semantic security: For any m 0 ≠ m 1, (pk, Enc pk (m 0 ))  (pk, Enc pk (m 1 ))   means indistinguishable by efficient algorithms.  Any semantically secure encryption scheme must be probabilistic – i.e., many ciphertexts per plaintext. Security of Homomorphic Encryption

17  Cloud stores my encrypted files: pk, Enc pk (f 1 ),…, Enc pk (f n ).  Later, I want f 3, but want to hide “3” from cloud.  I send Enc pk (3) to the cloud.  Cloud runs Eval pk (F, Enc pk (3), Enc pk (f 1 ),…, Enc pk (f n )), where F(n, {files}) is the function that outputs the nth file.  It sends me the (encrypted) file f 3.  Paradox?: Can’t the cloud “see” it is sending the 3 rd encrypted file? By comparing the stored value Enc pk (f 3 ) to the ciphertext it sends? HE Security: A Paradox? Resolution of paradox: Semantic security implies:  Many encryptions of f 3,  Hard to tell when two ciphertexts encrypt the same thing.

18 Limitations

19  Obfuscation:  I give the cloud an “encrypted” program Enc(P).  For any input x, cloud can compute Enc(P)(x) = P(x).  Cloud learns “nothing” about P, except {x i,P(x i )}.  Difference between obfuscation and FHE:  In FHE, cloud computes Enc(P(x)), and it can’t decrypt to get P(x).  Barak et al: “On the (Im)possibility of Obfuscating Programs”  Certain types of obfuscation are impossible.  Garg et al: “Candidate Indistinguishability Obfuscation and Functional Encryption for All Circuits”  Certain types of obfuscation seem possible (we have schemes). FHE Doesn’t Do Obfuscation

20  Circuits vs. RAMs:  Circuits are powerful: Circuit-size ≈ TM complexity.  But random-access machines compute some functions much faster than a TM or circuit (Binary search)  Can’t do “random access” on encrypted data without leaking some information (not surprising)  What we can do:  Oblivious RAM: But this is a very interactive protocol between client and server where server can’t tell what client is computing  Use Obfuscation to do ORAM: Intuitively, obfuscation allows addresses in memory to be revealed “noninteractively”. FHE Doesn’t Do RAM

21  Multi-Key FHE  Different clients encrypt data under different FHE keys.  Later, cloud “combines” data encrypted under different keys: Enc pk1,…,pkt (f(m 1,…,m t )) ← Eval(pk 1,…pk t,f,c 1,…c t ).  FHE doesn’t do this “automatically”.  But, “On-the-fly Multiparty Computation on the Cloud via Multikey FHE”:  There is a scheme that does this. FHE Doesn’t Do Multi-Key

22 Part 2: Somewhat Homomorphic Encryption Constructions

23 A Toy HE Scheme (from American Scientist magazine)  Encryption: Double the plaintext. x → 2x  Decryption: Halve the ciphertext. x → x/2

24  Each ciphertext has some noise that hides the message.  Think: “hidden” error correcting codes…  If error is small, Alice can use knowledge of “hidden” code to remove the noise.  If noise is large, decryption is hopeless even for Alice. Noisy Ciphertexts

25 The van Dijk, Gentry, Halevi, Vaikuntanathan scheme Somewhat Homomorphic Encryption over the Integers

26  KeyGen: Secret key = large odd integer n. Public key: Integers q 1 n+2r 1, …, q t n+2r t with |r i | ¿ n. (These are encryptions of 0.)  Encrypt: Add a random subset of the encryptions of 0 to get a “random” encryption of 0. Then add the message m in {0,1}. c = n( Σ i in S q i ) + 2( Σ i in S r i ) + m.  Decrypt: Compute [c] n = m+smalleven. ([c] n denotes c mod n.) Then, reduce mod 2 to get m.  ADD and MULT: Output sum or product of ciphertexts. SWHE with Integers Main Idea Encryptions of 0 are something small and even modulo a secret integer.

27  Reduction:  If “approximate gcd” problem is hard, then the scheme is semantically secure.  Approximate GCD Problem:  Given many a i = e i + q i ∙n (approx multiples of n), output n. Security of SWHE with Integers

28  ADD: c = c 1 + c 2.  Noise of c is [c] n = [c mod n] = sum of noises [c 1 ] n and [c 2 ] n.  Unless this sum is bigger than n (decryption error).  MULT: c = c 1 ∙ c 2.  Noise [c] n is product of noises, unless product > n. (q 1 n+e 1 ) ∙ (q 2 n+e 2 ) = (q 1 q 2 n+q 1 e 2 +e 1 q 2 )n + e 1 e 2.  Function f: c = f(c 1,…,c t ).  Noise [c] n = f([c 1 ] n,…,[c t ] n ) – i.e., f applied to noises.  Rough approximation: Noise magnitude increases exponentially with degree of f. The Noise Problem

29  Ciphertexts must be large to let noise “room to grow”.  Noise grows exponentially with degree. Bit-length of noise grows linearly with degree.  Ciphertext size grows linearly with degree. The Noise Problem Hurts Efficiency. Why?

30 Focusing on the Gentry-Sahai-Waters scheme. (Brakerski and Vaikuntanathan were the first to construct HE based on LWE.) Somewhat Homomorphic Encryption Based on LWE

31 Recall Regev’s Encryption Scheme

32 Properties of Regev’s Scheme

33 Homomorphic ADD in Regev

34 Homomorphic MULT in Regev

35 Matrix Version of Regev (1 st Attempt)

36 Ciphertext Matrix Message Eigenvalue Secret Key Eigenvector Homomorphisms in Error-Free Setting

37 Homomorphisms with Error New Noise

38 Controlling the Noise New Noise

39 How to Flatten Ciphertexts

40

41

42 Flattening Ciphertexts Repeatedly

43 KeyGen, Encrypt, and Decrypt

44 Security Based on LWE

45 Summary of GSW HE Scheme

46 ? Thank You! Questions? ? TIME EXPIRED

47 111011 E-ADD 100010 111011 01100111101100100100010001 b denotes an encryption of bit b. Step 1: Match string against subsequences of file Bit-wise encrypted file E-ZeroString(100010) = 0 (not the zero string! not a match!) E-ZeroString function itself can be computed from basic bit operations. Encrypted String Matching

48 Bit-wise encrypted file 01100111101100100100010001 111011 00000010 E-OR(00000010…) = 1 (string is in the encrypted file!) b denotes an encryption of bit b. Step 2: Aggregate info about the subsequences E-OR can also be computed from basic bit operations. Encrypted String Matching

49 Learning with Errors (LWE) Problem

50 Generalization of Error-Free Scheme (which is also insecure)  Ciphertexts live in a ring R C.  Plaintexts live in a ring R P.  Decryption is a ring homomorphism Dec sk : R C → R P.  Homomorphic Eval operations: + and · in R C.  Call it the “Hidden Ring Homomorphism Approach”  Security: Ideal membership problem  Is challenge ciphertext in the ideal of encryptions of 0?

51 Polly Cracker [FK93]: Ciphertexts in a multivariate polynomial ring  KeyGen: Secret sk = some point ( s 1, …, s t ) 2 Z q t. Public key: Polynomials {f i (x 1,…,x t )} s.t. f i (s 1,…,s t )=0 mod q.  Encrypt: From {f i }, generate random poly g s.t. g(s 1,…,s t ) = 0 mod q. Ciphertext is c(x 1,…,x t ) = μ + g(x 1,…,x t ) mod q.  Decrypt: Evaluate ciphertext at the secret: c(s 1,…,s t ) = μ mod q.  ADD and MULT: Output sum or product of ciphertext polys.  Security: Distinguish whether c has common root with the f i ’s.

52  Collect lots of encryptions {c i } of 0. They form an ideal.  The coefficient vectors of the c i ’s generate a lattice L. Compute Hermite Normal Form (HNF) of L.  Coefficient vectors must be only polynomially long  Else, the scheme is inefficient  Linear algebra attack on semantic security:  To distinguish whether c encrypts 0 or 1, reduce it modulo HNF(L): the result will be 0 only if m = 0.  Ideal membership problem is easy in this case. Polly Cracker Attack

53 Attack on Eigenvector Scheme  Encryptions of 0 live in a subspace  C · v = 0 · v = 0 mod q  Linear algebra attack on semantic security:  To distinguish whether C encrypts 0 or 1, check whether C is in the subspace of encryptions of 0.  Ideal membership problem is easy once again.

54 Identity-Based FHE (IBFHE)

55 IBE → IBFHE Compiler: What It Needs

56 IBE → IBFHE Compiler: Construction

57 Attribute-Based FHE (ABFHE)

58 Compiler: GVW ABE → ABFHE


Download ppt "China Summer School on Lattices and Cryptography Craig Gentry and Shai Halevi June 3, 2014 Somewhat Homomorphic Encryption."

Similar presentations


Ads by Google