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

Part 1: Homomorphic Encryption: Background, Applications, Limitations

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??

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.

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

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.

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

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

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”.

Functionality

 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

 {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

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

 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

Security

 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

 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.

Limitations

 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

 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

 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

Part 2: Somewhat Homomorphic Encryption Constructions

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

 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

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

 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.

 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

 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

 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?

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

Recall Regev’s Encryption Scheme

Properties of Regev’s Scheme

Homomorphic ADD in Regev

Homomorphic MULT in Regev

Matrix Version of Regev (1 st Attempt)

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

Homomorphisms with Error New Noise

Controlling the Noise New Noise

How to Flatten Ciphertexts

Flattening Ciphertexts Repeatedly

KeyGen, Encrypt, and Decrypt

Security Based on LWE

Summary of GSW HE Scheme

? Thank You! Questions? ? TIME EXPIRED

E-ADD 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

Bit-wise encrypted file E-OR( …) = 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

Learning with Errors (LWE) Problem

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?

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.

 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

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.

Identity-Based FHE (IBFHE)

IBE → IBFHE Compiler: What It Needs

IBE → IBFHE Compiler: Construction

Attribute-Based FHE (ABFHE)

Compiler: GVW ABE → ABFHE