Computing on Encrypted data

C
OMPUTING

ON

E
NCRYPTED

DATA

Shai

Halevi
, IBM Research

January 5, 2012

I want to
delegate
processing

of my data,

without
giving away
access

to it.

Computing on Encrypted Data

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

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

Outsourcing Computation Privately

Client

Server/Cloud

(Input:
x
)

(Function:
f
)

“I want to delegate the computation to the cloud”

“I want to delegate the computation to the cloud,

but the cloud shouldn’t see my input”

Enc
[
f
(
x
)
]

Enc(
x
)

f

$skj#hS28ksytA@ …

Outsourcing Computation Privately

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

Example
:
RSA_encrypt
(
e
,
N
)
(
x
) =
x
e

mod
N


•
x
1
e

x
x
2
e

=
(
x
1

x
x
2
)

e

mod
N

“Somewhat
Homomorphic
”: can compute some
functions on encrypted data, but not all

Privacy
Homomorphisms


Plaintext space
P

Ciphertext space
C

x
1

x
2

c
i



Enc(
x
i
)

c
1

c
2

*

#

y

d

y



Dec(
d
)

•
Rivest
-
Adelman
-
Dertouzos

1978

“Fully
Homomorphic
” Encryption

•
Encryption for which we can compute
arbitrary
functions

on the encrypted data




•
Another example: private information retrieval

Enc
(
f
(
x
)
)

Enc(
x
)

Eval

f

Enc
(
A[
i
]
)

Enc
(
i
)

i

A[1 …
n
]

H
OW

TO

DO

IT
?

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 b
1
, b
2

(both 0/1 values)

–
NOT b
1

= 1
–

b
1

–
b
1

AND b
2

= b
1

b
2

–
b1 OR b2 = b
1
+
b
2
–

b
1

b
2

•
If we can do +,
–

, x, we can do everything

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

H
OW

MUCH

DOES

IT

COST
?

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

–
C
an only evaluate “very simple functions”

–
About ½
-
second for an AND gate

•
Underlying “somewhat
homomorphic
” scheme

•
PK
is 2 integers, SK is one
integer

Dimension

KeyGen

Enc
(amortized)

Dec / AND

2048

800,000
-
bit
integers

1.25 sec

60
millisec

23
millisec

8192

3,200,000
-
bit
integers

10 sec

0.7 sec

0.12 sec

32768

13,000,000
-
bit
integers

95 sec

5.3 sec

0.6 sec

Large Medium Small

Performance

Dimension

KeyGen

PK size

AND

2048

800,000
-
bit
integers

40 sec

70

MByte

31 sec

8192

3,200,000
-
bit
integers

8 min

285
MByte

3 min

32768

13,000,000
-
bit
integers

2

hours

2.3
GByte

30 min

Large Medium Small

Performance

•
Fully
homomorphic

scheme

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


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

W
HAT

C
AN

I
USE
?

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)


Q
UESTIONS
?

BACKUP

SLIDES

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

Evaluate any function in four “easy” steps

•
Step 1: Encryption from linear ECCs

–
Additive homomorphism

•
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

The [Gentry 2009] blueprint

Error
-
Correcting Codes

•
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,…]

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)

Step 1
: Encryption from Linear ECCs

•
Code determined by a secret integer
p

–
Codewords
: multiples of
p

•
Good representation:
p

itself

•
Bad representation:

–
N

=
pq
, and also many
x
i

=
pq
i

+
r
i

•
Enc
(0): subset
-
sum(
x
i
’s)+
r

mod
N

–
r
is new noise, chosen by
encryptor

•
Enc
(1): random integer mod
N

Example: Integers mod


p

[
vDGHV

2010]

r
i

<<

p

p

N

•
Both Enc(0), Enc(1) close to the code

–
Enc(0): distance to code is even

–
Enc(1): distance to code is odd

–
Security unaffected when p is odd


•
In our example of integers mod
p
:

–
Enc(
b
) = 2(
r
+subset
-
sum
(
x
i
’s
)
)

+
b

mod
N



=
k
p

+ 2(
r
+subset
-
sum
(
r
i
’s
)
)+
b


–
Dec(
c
) = (
c

mod
p
) mod 2

A Different Input Encoding

N

p

x
i

=
pq
i

+
r
i

much smaller
than p/2

Plaintext encoded

in the “noise”

•
c
1
+c
2

=
(codeword
1
+
codeword
2
)


+
(
2
r
1
+b
1
)
+
(2
r
2
+b
2
)

–
codeword
1
+
codeword
2



Code

–
(2
r
1
+b
1
)
+
(
2
r
2
+b
2
)
=2
(
r
1
+r
2
)
+b
1
+b
2
is still small

•
If
2
(
r
1
+r
2
)
+b
1
+b
2

< min
-
dist/2, then

dist
(
c
1
+c
2
,
Code
) =
2
(
r
1
+r
2
)
+b
1
+b
2




dist(
c
1
+c
2
,
Code
)


b
1
+
b
2

(
mod
2)

•
Additively
-
homomorphic

while close to
Code

Additive Homomorphism

Product in
Ring

of
small elements is small

•
What happens when multiplying in
Ring
:

–
c
1
∙
c
2

= (codeword
1
+2
r
1
+
b
1
)∙(codeword
2
+2
r
2
+
b
2
)

= codeword
1
∙
X

+
Y
∙codeword
2


+
(
2
r
1
+
b
1
)∙(
2
r
2
+
b
2
)

•
If:

–
codeword
1
∙
X

+
Y
∙codeword
2


Code

–

(
2
r
1
+
b
1
)∙(
2
r
2
+
b
2
)

< min
-
dist/2

•
Then

–
dist(
c
1
c
2
,
Code
) = (
2
r
1
+
b
1
)∙(
2
r
2
+
b
2
) =
b
1
∙
b
2

mod 2

Step 2:
Code

Lives in a
Ring

Code

is
an
ideal

•
Secret
-
key is
p
, public
-
key is
N

and the
x
i
’s

•
c
i

=
Enc
pk
(
b
i
) = 2(
r
+subset
-
sum
(
x
i
’s
)
)

+
b

mod
N





=
k
i
p

+ 2
r
i
+
b
i

–
Dec
sk
(
c
i
)
= (
c
i

mod
p
) mod 2

•
c
1
+
c
2

mod
N

=
(
k
1
p
+2
r
1
+
b
1
)+
(
k
2
p
+2
r
2
+
b
2
)
–

kqp





=
k
’
p

+ 2(
r
1
+
r
2
) + (
b
1
+
b
2
)

•
c
1
c
2

mod
N

= (
k
1
p
+2
r
1
+
b
1
)
(
k
2
p
+2
r
2
+
b
2
)
–

kqp





=
k
’
p

+
2(2
r
1
r
2
+
r
1
b
2
+
r
2
b
1
)
+
b
1
b
2

•
Additive, multiplicative homomorphism

–
A
s long as noise <
p
/2


Example: Integers mod


p

[
vDGHV

2010]

x
i

=
pq
i

+
r
i

N

p

•
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

Summary Up To Now

Step 3: Bootstrapping

P(
x
1
,
x
2
,
…
,
x
t
)

x
1

…

x
2

x
t

P

•
So far, can evaluate low
-
degree polynomials

•
So far, can evaluate low
-
degree polynomials

•
Can
eval

y
=
P
(
x
1
,x
2
…,
x
n
)

when
x
i
’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)

Step 3: Bootstrapping

x
1

…

x
2

x
t

P

P(
x
1
,
x
2
,
…
,
x
t
)

•
So far, can evaluate low
-
degree polynomials

•
Bootstrapping to handle higher degrees

–
We have a noisy evaluated
ciphertext

y

–
Want to get another y with less noise

Step 3: Bootstrapping

x
1

…

x
2

x
t

P

P(
x
1
,
x
2
,
…
,
x
t
)

•
For
ciphertext

c
, consider
D
c
(
sk
) =
Dec
sk
(
c
)

–
Hope:
D
c
(
*
)

is a low
-
degree polynomial in
sk

•
Include in the public key also
Enc
pk
(
sk
)






•
Homomorphic

computation applied only to the
“fresh” encryption of
sk

Step 3: Bootstrapping

D
c

y

sk
1

sk
2

sk
n

…

c

D
c
(
sk
)

=
Dec
sk
(
c
) =
y

c’

Requires
“
circular
security
”

sk
1

sk
2

sk
n

…

•
Similarly define
M
c
1
,c
2
(
sk
) =
Dec
sk
(
c
1
)∙
Dec
sk
(
c
1
)








•
Homomorphic

computation applied only to the
“fresh” encryption of
sk

Step 3: Bootstrapping

M
c
1
,c
2

y
2

sk
1

sk
2

sk
n

…

c
2

M
c
1
,
c
2
(
sk
)

=
Dec
sk
(
c
1
)
x
Dec
sk
(
c
2
) =
y
1

x

y
2

c’

y
1

c
1

sk
1

sk
2

sk
n

…

•
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

Step 4: Everything Else