Design & Implementation of Homomorphic-

Encryption Library*

* Partially sponsored by IARPA SPAR

* Partially sponsored by DARPA PROCEED

We implemented [BGV’12], with optimizations from [GHS’12]◦ Working over polynomials rings ◦ Security based on ring-LWE (+circular security)◦ Packed ciphertexts using polynomial CRT [SV’11]◦ Polynomials represented in “Double-CRT” format

is are integer factors of q are polynomial factors of modulo q

◦ Assorted other optimizations

The Cryptosystem

PAlgebraStructure of Zm*

PAlgebraTwo/2rplaintext-slot algebra

NumbThmiscellaneous

utilities

CModuluspolynomials mod

p

Math

SingleCRT/DoubleCRTpolynomial arithmetic

FHEKeyGen/Enc/Dec

CtxtCiphertext operations

Cry

pto

EncryptedArray/EncrytedArrayMod2rRouting plaintext slots

IndexSet/IndexMap

Indexing utilities

FH

Econ

text

para

mete

rs

bluesteinFFT/IFFT

timing

KeySwitchingMatrices for key-

switching

Box Diagram of the Library

A ciphertext encrypts an array of values◦ Either bits, elements of GF(2n), or integers mod 2r

Array size determined by other parameters◦ Intended depth of circuits & security parameter◦ E.g., 378, 600, 682, 720, 1285, …

Homomorphic operations include:◦ Element-wise addition/subtraction, multiplication◦ Addition/subtraction, multiplication by constants◦ Cyclic/non-cyclic shifts

◦ Also SELECT(A1,A2, pattern)= patternA1 + (1-pattern)A2

User Perspective

Security parameter=80, circuit width=4 arrays

(*)

(*) maybe similar work to homomorphic AES◦ If true, ~12x speedup on our previous implementation

[CRYPTO 2012]

Performance

Circuit “depth” Array size Time (hrs:min:sec)

7 224 0:00:38

14 480 0:02:49

35 512 0:19:05

70 720 3:01:51

84 2048 5:24:47

Various optimizations and design choices1. Representing plaintext algebra (§2.4, §2.5)

2. Double-CRT representation of polynomials(§2.8)

3. Ciphertexts as “generic” vectors (§3.1.1-§3.1.3)

4. Dynamic noise estimate (§3.1.4)

5. Key-switching optimizations (§3.1.6)

6. Which key-switching matrices to generate (§3.3)

7. Implementation of rotation/shifts (§4.1) Here I will only talk about 3 & 4

Under the Hood

§ The section numbers correspond to the design & implementation document

The library handles several cipehrtext “types”◦ A “canonical” ciphertext is a pair (c0,c1)

Decryption is , with s the secret key

◦ After multiplication we have a triple (c0,c1,c2) Decryption is

◦ After “automorphism” we have (c0,c1) Decryption is ,

Also, we may have more than one secret key Need a unified interface to handle them all

Ciphertexts as “Generic” Vectors

A ciphertext in the library is a vector of parts◦ A part consists of polynomial & “handle”

Handle points to the secret key that should multiply this part on decryption◦ Handle consists of three integers H=()

I.e., this polynomial is to be multiplied by

◦ H points to the constant iff ◦ H points to a “base secret key” iff

Ciphertext-Parts & Handles

Using handles makes for a flexible design◦ Easy to manipulate ciphertexts, just by handling

one part at a time In principle, a ciphertext can have arbitrary

many parts with arbitrary distinct handles◦ But we scarcely support handles with both ◦ or handles that name different secret keys

By convention, the 1st part in any ciphertext always points to the constant 1

Ciphertext-Parts & Handles (cont.)

Multiplying ◦ We first “multiply the handles”, where:

If then , if then If both , and and then Else abort

◦ Then we output

Adding a part to a ciphertext ◦ If contains a part with the same handle,

then replace it by ◦ Else just append the part to

Applying to ◦ Output

Ciphertext-Part Arithmetic

Multiplication via tensoring◦ Output

Addition ◦ Add all the parts of to

Applying to ◦ Apply to all the parts of

Key-switching, modulus-switching also applied to each part separately◦ Key-switching transforms with or into a canonical

pair

Ciphertext Operations

The “noise” in a ciphertext is the polynomial ◦ Computed during decryption before reduction mod

2 The “magnitude” of is the norm of the

vector ◦ is the principle complex m’th root of unity, ◦ This vector is the canonical embedding of

Each ciphertext carries a “noise estimate”

Noise Estimation

Thinking of as random variables, estimate heuristically the expected value

Each ciphertext can be written as ◦ Where and the ’s are small

So (without reduction modulo q), and If the and are independent, we have

◦ We estimate , separately

Noise Estimation (cont.)

is usually a “rounding error” polynomial◦ Coefficients are heuristically uniform in [-1,+1]◦ So , hence

, and for every :◦ is a magnitude-one complex constant◦ is a 0-mean random-variable with variance

Hence

Estimating

Recall that for some r,t,i◦ does not change the noise magnitude◦ is chosen at random with coefficients

and a fixed Hamming weight (e.g. ) So we need to estimate for a random

Hamming-weight- polynomial ◦ For , each to see that ◦ For , we get

Proof is nontrivial Assuming that We mainly use r=2,3

Estimating

A freshly-encrypted ciphertext comes with some noise estimate

The estimate evolves during computation We use it to decide when to do modulus-

switching Also the application can use it to know if it

should expect a decryption error

Noise Estimation (cont.)

We have the basic BGV implementation more or less done

Evaluate nontrivial circuits in a few minutes, and even complex circuits in just a few hours

Amenable to massive parallelism

Summary