Shai Halevi discusses new ways to protect cloud data and security. Presented at "New Techniques for Protecting Cloud Data and Security" organized by the New York Technology Council.

1. COMPUTING ON ENCRYPTED DATA
Shai Halevi, IBM Research
January 5, 2012

2. Computing on Encrypted Data
I want to delegate processing of my data,
without giving away access to it.

3. Computing on Encrypted Data
• Wouldn’t it be nice to be able to…
– Encrypt my data before sending to the cloud
– While still allowing the cloud to
search/sort/edit/… this data on my behalf
– Keeping the data in the cloud in encrypted form
• Without needing to ship it back and forth to be
decrypted

4. Computing on Encrypted Data
• Wouldn’t it be nice to be able to…
– Encrypt my queries to the cloud
– While still allowing the cloud to process them
– Cloud returns encrypted answers
• that I can decrypt

5. Outsourcing Computation Privately
“I want to delegate the computation to the cloud,
“I wantthe cloud the computation to the cloud”
but to delegate shouldn’t see my input”
Enc(x) f
Enc[f(x)]
Client Server/Cloud
(Input: x) (Function: f)

6. Outsourcing Computation Privately
$skj#hS28ksytA@ …

7. Outsourcing Computation Privately
$kjh9*mslt@na0
&maXxjq02bflx
m^00a2nm5,A4.
pE.abxp3m58bsa
(3saM%w,snanba
nq~mD=3akm2,A
Z,ltnhde83|3mz{n
dewiunb4]gnbTa*
kjew^bwJ^mdns0

8. Privacy Homomorphisms
• Rivest-Adelman-Dertouzos 1978
Plaintext space P Ciphertext space C
x1 x2 ci  Enc(xi) c1 c2
y  Dec(d)
y d
Example: RSA_encrypt(e,N)(x) = xe mod N
• x1e x x2e = (x1 x x2) e mod N
“Somewhat Homomorphic”: can compute some
functions on encrypted data, but not all

9. “Fully Homomorphic” Encryption
• Encryption for which we can compute arbitrary
functions on the encrypted data
Enc(x) Eval f
Enc(f(x))
• Another example: private information retrieval
i Enc(i) A[1 … n]
Enc(A[i])

10. HOW TO DO IT?

11. Step 1: Boolean Circuit for f
• Every function can be constructed from
Boolean AND, OR, NOT
– Think of building it from hardware gates
• For any two bits b1, b2 (both 0/1 values)
– NOT b1 = 1 – b1
– b1 AND b2 = b1 b2
– b1 OR b2 = b1+b2– b1 b2
• If we can do +, – , x, we can do everything

12. Step 2: Encryption Supporting ,
• Open Problem for over 30 years
• Gentry 2009: first plausible scheme
– Security relies on hard problems in integer lattices
• Several other schemes in last two years
Fully homomorphic encryption
is possible

13. HOW MUCH DOES IT COST?

14. Performance
• A little slow…
• First working implementation in mid-2010,
½ -hour to compute a single AND gate
– 13-14 orders of magnitude slowdown
vs. computing on non-encrypted data
• A faster “dumbed down” version
– Can only evaluate “very simple functions”
– About ½-second for an AND gate

15. Performance
• Underlying “somewhat homomorphic” scheme
• PK is 2 integers, SK is one integer
Dimension KeyGen Enc Dec / AND
(amortized)
2048 1.25 sec 60 millisec 23 millisec
Small
800,000-bit
integers
Medium
8192 10 sec 0.7 sec 0.12 sec
3,200,000-bit
integers
32768 95 sec 5.3 sec 0.6 sec
Large
13,000,000-bit
integers

16. Performance
• Fully homomorphic scheme
Dimension KeyGen PK size AND
2048 40 sec 70 MByte 31 sec
Small
800,000-bit
integers
Medium
8192 8 min 285 MByte 3 min
3,200,000-bit
integers
32768 2 hours 2.3 GByte 30 min
Large
13,000,000-bit
integers

17. Performance
• A little slow…
• Butler Lampson: “I don’t think we’ll see
anyone using Gentry’s solution in our
lifetimes *…+” – Forbes, Dec-19, 2011

18. New Stuff
• New techniques suggested during 2011
• Promise ~3 orders of magnitude improvement
vs. Gentry’s original scheme
– Implementations on the way
• Still very expensive, but maybe suitable for
some niche applications
• Computing “simple functions” using these
tools may be realistic

19. WHAT CAN I USE?

20. Things we can already use today
• Sometimes simple functions is all we need
– Statistics, simple keyword match, etc.
• Interactive solutions are sometime faster
– vs. the single round trip of Homomorphic Enc
• Great efficiency gains when settling for
weaker notions of secrecy
– “Order preserving encryption”
– MIT’s CryptDB (onion encryption)

21. QUESTIONS?

22. BACKUP SLIDES

23. Limitations of function-as-circuit
• Some performance optimizations are ruled out
• Example: Binary search
– log(n) steps to find element in an n-element array
– But circuit must be of size ~n
• Example: private information retrieval
– Non-encrypted access with one lookup
– But encrypted access must touch all entries
• Else you leak information (element is not in i’th entry)
• Only data-oblivious computation is possible

24. The [Gentry 2009] blueprint
Evaluate any function in four “easy” steps
• Step 1: Encryption from linear ECCs
– Additive homomorphism Error-Correcting Codes
• Step 2: ECC lives inside a ring
– Also multiplicative homomorphism
– But only for a few operations (low-degree poly’s)
• Step 3: Bootstrapping
– Few ops (but not too few)  any number of ops
• Step 4: Everything else
– “Squashing” and other fun activities

25. Step 1: Encryption from Linear ECCs
• For “random looking” codes, hard to
distinguish close/far from code
• Many cryptosystems built on this hardness
– E.g., *McEliece’78, AD’97, GGH’97, R’03,…+

26. Step 1: Encryption from Linear ECCs
• KeyGen: choose a “random” Code
– Secret key: “good representation” of Code
• Allows correction of “large” errors
– Public key: “bad representation” of Code
• Can generate “random code-words”
• Hard to distinguish close/far from the code
• Enc(0): a word close to Code
• Enc(1): a random word
– Far from Code (with high probability)

27. Example: Integers mod p [vDGHV 2010]
p N
• Code determined by a secret integer p
– Codewords: multiples of p
• Good representation: p itself
• Bad representation: ri << p
– N = pq, and also many xi = pqi + ri
• Enc(0): subset-sum(xi’s)+r mod N
– r is new noise, chosen by encryptor
• Enc(1): random integer mod N

28. A Different Input Encoding
p N
xi = pqi + ri
• Both Enc(0), Enc(1) close to the code
– Enc(0): distance to code is even Plaintext encoded
– Enc(1): distance to code is odd in the “noise”
– Security unaffected when p is odd
• In our example of integers mod p:
– Enc(b) = 2(r+subset-sum(xi’s)) + b mod N
= p + 2(r+subset-sum(ri’s))+b
much smaller
than p/2
– Dec(c) = (c mod p) mod 2

29. Additive Homomorphism
• c1+c2 = (codeword1+codeword2)
+ (2r1+b1)+(2r2+b2 )
– codeword1+codeword2 Code
– (2r1+b1)+(2r2+b2 )=2(r1+r2)+b1+b2 is still small
• If 2(r1+r2)+b1+b2 < min-dist/2, then
dist(c1+c2, Code) = 2(r1+r2)+b1+b2
 dist(c1+c2, Code) b1+b2 (mod 2)
• Additively-homomorphic while close to Code

30. Step 2: Code Lives in a Ring
• What happens when multiplying in Ring:
– c1∙c2 = (codeword1+2r1+b1)∙(codeword2+2r2+b2)
= codeword1∙X + Y∙codeword2
+ (2r1+b1)∙(2r2+b2) Code is an ideal
• If:
– codeword1∙X + Y∙codeword2 Code
– (2r1+b1)∙(2r2+b2) < min-dist/2
Product in Ring of
• Then small elements is small
– dist(c1c2, Code) = (2r1+b1)∙(2r2+b2) = b1∙b2 mod 2

31. Example: Integers mod p [vDGHV 2010]
p N
xi = pqi + ri
• Secret-key is p, public-key is N and the xi’s
• ci = Encpk(bi) = 2(r+subset-sum(xi’s)) + b mod N
= kip + 2ri+bi
– Decsk(ci) = (ci mod p) mod 2
• c1+c2 mod N = (k1p+2r1+b1)+(k2p+2r2+b2) – kqp
= k’p + 2(r1+r2) + (b1+b2)
• c1c2 mod N = (k1p+2r1+b1)(k2p+2r2+b2) – kqp
= k’p + 2(2r1r2+r1b2+r2b1)+b1b2
• Additive, multiplicative homomorphism
– As long as noise < p/2

32. Summary Up To Now
• We need a linear error-correcting code C
– With “good” and “bad” representations
– C lives inside an algebraic ring R
– C is an ideal in R
– Sum, product of small elements in R is still small
• Can find such codes in Euclidean space
– Often associated with lattices
• Then we get a “somewhat homomorphic”
encryption, supporting low-degree polynomials
– Homomorphism while close to the code

33. Step 3: Bootstrapping
• So far, can evaluate low-degree polynomials
x1 P
x2
… P(x1, x2 ,…, xt)
xt

34. Step 3: Bootstrapping
• So far, can evaluate low-degree polynomials
x1 P
x2
… P(x1, x2 ,…, xt)
xt
• Can eval y=P(x1,x2…,xn) when xi’s are “fresh”
• But y is an “evaluated ciphertext”
– Can still be decrypted
– But eval Q(y) will increase noise too much
• “Somewhat Homomorphic” encryption (SWHE)

35. Step 3: Bootstrapping
• So far, can evaluate low-degree polynomials
x1 P
x2
… P(x1, x2 ,…, xt)
xt
• Bootstrapping to handle higher degrees
– We have a noisy evaluated ciphertext y
– Want to get another y with less noise

36. Step 3: Bootstrapping
• For ciphertext c, consider Dc(sk) = Decsk(c)
– Hope: Dc( ) is a low-degree polynomial in sk
• Include in the public key also Encpk(sk)
c y
Requires
“circular
Dc security”
sk1
sk2 c’ Dc(sk)
…
= Decsk(c) = y
skn
• Homomorphic computation applied only to the
“fresh” encryption of sk

37. Step 3: Bootstrapping
• Similarly define Mc ,c (sk) = Decsk(c1)∙Decsk(c1)
1 2
y1 y2
c1 c2
sk1 Mc1,c2
c’
sk2
Mc1,c2(sk)
…
= Decsk(c1) x Decsk(c2) = y1 x y2
skn
• Homomorphic computation applied only to the
“fresh” encryption of sk

38. Step 4: Everything Else
• Cryptosystems from *G’09, vDGHV’10, BG’11a]
cannot handle their own decryption
• Tricks to “squash” the decryption
procedure, making it low-degree
– Nontrivial, requires putting more information
about the secret key in the public key
– Requires yet another assumption, namely hardness
of the Sparse-Subset-Sum Problem (SSSP)
– I will not talk about squashing here