Design & Implementation of Homomorphic -Encryption Library*

1. Design & Implementation of Homomorphic-Encryption Library* * Partially sponsored by IARPA SPAR * Partially sponsored by DARPA PROCEED

2. The Cryptosystem • 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

3. Box Diagram of the Library EncryptedArray/EncrytedArrayMod2r Routing plaintext slots KeySwitching Matrices for key-switching FHE KeyGen/Enc/Dec Ctxt Ciphertext operations FHEcontext parameters Crypto SingleCRT/DoubleCRT polynomial arithmetic PAlgebraTwo/2r plaintext-slot algebra CModulus polynomials mod p IndexSet/IndexMap Indexing utilities Math bluestein FFT/IFFT PAlgebra Structure of Zm* NumbTh miscellaneous utilities timing

4. User Perspective • 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) = patternA1 + (1-pattern)A2

5. Performance • Security parameter=80, circuit width=4 arrays (*) (*) maybe similar work to homomorphic AES • If true, ~12x speedup on our previous implementation [CRYPTO 2012]

6. Under the Hood • Various optimizations and design choices • Representing plaintext algebra (§2.4, §2.5) • Double-CRT representation of polynomials(§2.8) • Ciphertexts as “generic” vectors (§3.1.1-§3.1.3) • Dynamic noise estimate (§3.1.4) • Key-switching optimizations (§3.1.6) • Which key-switching matrices to generate (§3.3) • Implementation of rotation/shifts (§4.1) • Here I will only talk about 3 & 4 § The section numbers correspond to the design & implementation document

7. Ciphertexts as “Generic” Vectors • 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

8. Ciphertext-Parts & Handles • 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

9. Ciphertext-Parts & Handles (cont.) • 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

10. Ciphertext-Part Arithmetic • 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

11. Ciphertext Operations • 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

12. Noise Estimation • 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”

13. Noise Estimation (cont.) • 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

14. Estimating • 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

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

16. Noise Estimation (cont.) • 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

17. Summary • 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