Faster Homomorphic Linear Transformations in HElib Shai Halevi - - PowerPoint PPT Presentation

Faster Homomorphic Linear Transformations in HElib

Shai Halevi (IBM) Victor Shoup (IBM & NYU)

Fully Homomorphic Encryption allows for arbitrary computation on encrypted data In this talk, the focus is on linear transformations . . . more specifically, applying a fixed, public linear transformation to a vector encrypted in the BGV (Brakerski-Gentry-Vaikuntanathan) cryptosystem We present new algorithms and their implementation in HElib We get speed ups of up to ≈ 75× One important application: bootstrapping ➪ in Chen and Han’s new bootstrapping algorithm (Eurocrypt 2018), most of the time is spent performing a change of basis ➪ speed up of up to ≈ 6× for bootstrapping as a whole

Fully Homomorphic Encryption allows for arbitrary computation on encrypted data In this talk, the focus is on linear transformations . . . more specifically, applying a fixed, public linear transformation to a vector encrypted in the BGV (Brakerski-Gentry-Vaikuntanathan) cryptosystem We present new algorithms and their implementation in HElib We get speed ups of up to ≈ 75× One important application: bootstrapping ➪ in Chen and Han’s new bootstrapping algorithm (Eurocrypt 2018), most of the time is spent performing a change of basis ➪ speed up of up to ≈ 6× for bootstrapping as a whole

Fully Homomorphic Encryption allows for arbitrary computation on encrypted data In this talk, the focus is on linear transformations . . . more specifically, applying a fixed, public linear transformation to a vector encrypted in the BGV (Brakerski-Gentry-Vaikuntanathan) cryptosystem We present new algorithms and their implementation in HElib We get speed ups of up to ≈ 75× One important application: bootstrapping ➪ in Chen and Han’s new bootstrapping algorithm (Eurocrypt 2018), most of the time is spent performing a change of basis ➪ speed up of up to ≈ 6× for bootstrapping as a whole

Fully Homomorphic Encryption allows for arbitrary computation on encrypted data In this talk, the focus is on linear transformations . . . more specifically, applying a fixed, public linear transformation to a vector encrypted in the BGV (Brakerski-Gentry-Vaikuntanathan) cryptosystem We present new algorithms and their implementation in HElib We get speed ups of up to ≈ 75× One important application: bootstrapping ➪ in Chen and Han’s new bootstrapping algorithm (Eurocrypt 2018), most of the time is spent performing a change of basis ➪ speed up of up to ≈ 6× for bootstrapping as a whole

Fully Homomorphic Encryption allows for arbitrary computation on encrypted data In this talk, the focus is on linear transformations . . . more specifically, applying a fixed, public linear transformation to a vector encrypted in the BGV (Brakerski-Gentry-Vaikuntanathan) cryptosystem We present new algorithms and their implementation in HElib We get speed ups of up to ≈ 75× One important application: bootstrapping ➪ in Chen and Han’s new bootstrapping algorithm (Eurocrypt 2018), most of the time is spent performing a change of basis ➪ speed up of up to ≈ 6× for bootstrapping as a whole

Fully Homomorphic Encryption allows for arbitrary computation on encrypted data In this talk, the focus is on linear transformations . . . more specifically, applying a fixed, public linear transformation to a vector encrypted in the BGV (Brakerski-Gentry-Vaikuntanathan) cryptosystem We present new algorithms and their implementation in HElib We get speed ups of up to ≈ 75× One important application: bootstrapping ➪ in Chen and Han’s new bootstrapping algorithm (Eurocrypt 2018), most of the time is spent performing a change of basis ➪ speed up of up to ≈ 6× for bootstrapping as a whole

Fully Homomorphic Encryption allows for arbitrary computation on encrypted data In this talk, the focus is on linear transformations . . . more specifically, applying a fixed, public linear transformation to a vector encrypted in the BGV (Brakerski-Gentry-Vaikuntanathan) cryptosystem We present new algorithms and their implementation in HElib We get speed ups of up to ≈ 75× One important application: bootstrapping ➪ in Chen and Han’s new bootstrapping algorithm (Eurocrypt 2018), most of the time is spent performing a change of basis ➪ speed up of up to ≈ 6× for bootstrapping as a whole

Fully Homomorphic Encryption allows for arbitrary computation on encrypted data In this talk, the focus is on linear transformations . . . more specifically, applying a fixed, public linear transformation to a vector encrypted in the BGV (Brakerski-Gentry-Vaikuntanathan) cryptosystem We present new algorithms and their implementation in HElib We get speed ups of up to ≈ 75× One important application: bootstrapping ➪ in Chen and Han’s new bootstrapping algorithm (Eurocrypt 2018), most of the time is spent performing a change of basis ➪ speed up of up to ≈ 6× for bootstrapping as a whole

BGV encryption R = Z[X]/(n(X)) Plaintext space: Rp := R/pR (p = small prime) Ciphertext space: Rq := R/qR (n, p, q pairwise coprime) Ciphertext: ¯ c ∈ R2×1

q

Secret key: ¯ s = (1, s1) ∈ R2×1

q

, where s1 has small norm Decryption: 〈¯ s, ¯ c〉 = pε

• “noise”

+m

BGV encryption R = Z[X]/(n(X)) Plaintext space: Rp := R/pR (p = small prime) Ciphertext space: Rq := R/qR (n, p, q pairwise coprime) Ciphertext: ¯ c ∈ R2×1

q

Secret key: ¯ s = (1, s1) ∈ R2×1

q

, where s1 has small norm Decryption: 〈¯ s, ¯ c〉 = pε

• “noise”

+m

BGV encryption R = Z[X]/(n(X)) Plaintext space: Rp := R/pR (p = small prime) Ciphertext space: Rq := R/qR (n, p, q pairwise coprime) Ciphertext: ¯ c ∈ R2×1

q

Secret key: ¯ s = (1, s1) ∈ R2×1

q

, where s1 has small norm Decryption: 〈¯ s, ¯ c〉 = pε

• “noise”

+m

BGV encryption R = Z[X]/(n(X)) Plaintext space: Rp := R/pR (p = small prime) Ciphertext space: Rq := R/qR (n, p, q pairwise coprime) Ciphertext: ¯ c ∈ R2×1

q

Secret key: ¯ s = (1, s1) ∈ R2×1

q

, where s1 has small norm Decryption: 〈¯ s, ¯ c〉 = pε

• “noise”

+m

BGV encryption R = Z[X]/(n(X)) Plaintext space: Rp := R/pR (p = small prime) Ciphertext space: Rq := R/qR (n, p, q pairwise coprime) Ciphertext: ¯ c ∈ R2×1

q

Secret key: ¯ s = (1, s1) ∈ R2×1

q

, where s1 has small norm Decryption: 〈¯ s, ¯ c〉 = pε

• “noise”

+m

BGV encryption R = Z[X]/(n(X)) Plaintext space: Rp := R/pR (p = small prime) Ciphertext space: Rq := R/qR (n, p, q pairwise coprime) Ciphertext: ¯ c ∈ R2×1

q

Secret key: ¯ s = (1, s1) ∈ R2×1

q

, where s1 has small norm Decryption: 〈¯ s, ¯ c〉 = pε

• “noise”

+m

Representation of ciphertext space Rq Coefficient representation DoubleCRT representation

• q = q1 · · · qℓ, where each q is a small prime such that Zq contains nth roots of

unity

• A polynomial in Rq is reduced modulo each q, and then evaluated at the

primitive nth roots of unity in Zq

Addition of ciphertexts in DoubleCRT representation takes linear time . . . so does multiplication by a constant Switching between DoubleCRT and coefficient representations: somewhat expensive (requires CRT and FFT)

Representation of ciphertext space Rq Coefficient representation DoubleCRT representation

• q = q1 · · · qℓ, where each q is a small prime such that Zq contains nth roots of

unity

• A polynomial in Rq is reduced modulo each q, and then evaluated at the

primitive nth roots of unity in Zq

Addition of ciphertexts in DoubleCRT representation takes linear time . . . so does multiplication by a constant Switching between DoubleCRT and coefficient representations: somewhat expensive (requires CRT and FFT)

Representation of ciphertext space Rq Coefficient representation DoubleCRT representation

• q = q1 · · · qℓ, where each q is a small prime such that Zq contains nth roots of

unity

• A polynomial in Rq is reduced modulo each q, and then evaluated at the

primitive nth roots of unity in Zq

Addition of ciphertexts in DoubleCRT representation takes linear time . . . so does multiplication by a constant Switching between DoubleCRT and coefficient representations: somewhat expensive (requires CRT and FFT)

Representation of ciphertext space Rq Coefficient representation DoubleCRT representation

• q = q1 · · · qℓ, where each q is a small prime such that Zq contains nth roots of

unity

• A polynomial in Rq is reduced modulo each q, and then evaluated at the

primitive nth roots of unity in Zq

Addition of ciphertexts in DoubleCRT representation takes linear time . . . so does multiplication by a constant Switching between DoubleCRT and coefficient representations: somewhat expensive (requires CRT and FFT)

Representation of ciphertext space Rq Coefficient representation DoubleCRT representation

• q = q1 · · · qℓ, where each q is a small prime such that Zq contains nth roots of

unity

• A polynomial in Rq is reduced modulo each q, and then evaluated at the

primitive nth roots of unity in Zq

Addition of ciphertexts in DoubleCRT representation takes linear time . . . so does multiplication by a constant Switching between DoubleCRT and coefficient representations: somewhat expensive (requires CRT and FFT)

Representation of ciphertext space Rq Coefficient representation DoubleCRT representation

• q = q1 · · · qℓ, where each q is a small prime such that Zq contains nth roots of

unity

• A polynomial in Rq is reduced modulo each q, and then evaluated at the

primitive nth roots of unity in Zq

Addition of ciphertexts in DoubleCRT representation takes linear time . . . so does multiplication by a constant Switching between DoubleCRT and coefficient representations: somewhat expensive (requires CRT and FFT)

Multiplication and Key Switching Multiplying two ciphertexts in DoubleCRT representation takes linear time But . . . we get a ciphertext defined with respect to a different secret key So . . . we include an encryption of this other key under the original key in the public parameters (called a “key switching matrix”) Using this, we can convert the product ciphertext to an equivalent

• ne under the original key

Key switching is expensive: ☞ conversions between coefficient and DoubleCRT representations

Multiplication and Key Switching Multiplying two ciphertexts in DoubleCRT representation takes linear time But . . . we get a ciphertext defined with respect to a different secret key So . . . we include an encryption of this other key under the original key in the public parameters (called a “key switching matrix”) Using this, we can convert the product ciphertext to an equivalent

• ne under the original key

Key switching is expensive: ☞ conversions between coefficient and DoubleCRT representations

Multiplication and Key Switching Multiplying two ciphertexts in DoubleCRT representation takes linear time But . . . we get a ciphertext defined with respect to a different secret key So . . . we include an encryption of this other key under the original key in the public parameters (called a “key switching matrix”) Using this, we can convert the product ciphertext to an equivalent

• ne under the original key

Key switching is expensive: ☞ conversions between coefficient and DoubleCRT representations

Multiplication and Key Switching Multiplying two ciphertexts in DoubleCRT representation takes linear time But . . . we get a ciphertext defined with respect to a different secret key So . . . we include an encryption of this other key under the original key in the public parameters (called a “key switching matrix”) Using this, we can convert the product ciphertext to an equivalent

• ne under the original key

Key switching is expensive: ☞ conversions between coefficient and DoubleCRT representations

Multiplication and Key Switching Multiplying two ciphertexts in DoubleCRT representation takes linear time But . . . we get a ciphertext defined with respect to a different secret key So . . . we include an encryption of this other key under the original key in the public parameters (called a “key switching matrix”) Using this, we can convert the product ciphertext to an equivalent

• ne under the original key

Key switching is expensive: ☞ conversions between coefficient and DoubleCRT representations

Plaintext space structure Chinese Remainder Theorem: Rp = Zp[X]/(n(X)) ∼ =

h

• =1

Zp[X]/(ƒ(X)) where n(X) =

h

=1 ƒ(X)

Each ƒ irreducible of degree d = order of p mod n So we have Rp ∼ = (GF(pd))h [dh = ϕ(n)] We can view plaintext space as GF(pd), and we can work on vectors

• f h plaintext “slots” in parallel

Reminiscent of vectorized or SIMD computation

Plaintext space structure Chinese Remainder Theorem: Rp = Zp[X]/(n(X)) ∼ =

h

• =1

Zp[X]/(ƒ(X)) where n(X) =

h

=1 ƒ(X)

Each ƒ irreducible of degree d = order of p mod n So we have Rp ∼ = (GF(pd))h [dh = ϕ(n)] We can view plaintext space as GF(pd), and we can work on vectors

• f h plaintext “slots” in parallel

Reminiscent of vectorized or SIMD computation

Plaintext space structure Chinese Remainder Theorem: Rp = Zp[X]/(n(X)) ∼ =

h

• =1

Zp[X]/(ƒ(X)) where n(X) =

h

=1 ƒ(X)

Each ƒ irreducible of degree d = order of p mod n So we have Rp ∼ = (GF(pd))h [dh = ϕ(n)] We can view plaintext space as GF(pd), and we can work on vectors

• f h plaintext “slots” in parallel

Reminiscent of vectorized or SIMD computation

Plaintext space structure Chinese Remainder Theorem: Rp = Zp[X]/(n(X)) ∼ =

h

• =1

Zp[X]/(ƒ(X)) where n(X) =

h

=1 ƒ(X)

Each ƒ irreducible of degree d = order of p mod n So we have Rp ∼ = (GF(pd))h [dh = ϕ(n)] We can view plaintext space as GF(pd), and we can work on vectors

• f h plaintext “slots” in parallel

Reminiscent of vectorized or SIMD computation

Plaintext space structure Chinese Remainder Theorem: Rp = Zp[X]/(n(X)) ∼ =

h

• =1

Zp[X]/(ƒ(X)) where n(X) =

h

=1 ƒ(X)

Each ƒ irreducible of degree d = order of p mod n So we have Rp ∼ = (GF(pd))h [dh = ϕ(n)] We can view plaintext space as GF(pd), and we can work on vectors

• f h plaintext “slots” in parallel

Reminiscent of vectorized or SIMD computation

Some useful automorphisms Each j ∈ Z∗

n defines an automorphism on Rp that sends X → Xj

Homomorphic evaluation: just apply X → Xj directly to Rq ☞ easy . . . but it requires “key switching” This gives us a set of “rotations” that allow us to move data between “slots”

Some useful automorphisms Each j ∈ Z∗

n defines an automorphism on Rp that sends X → Xj

Homomorphic evaluation: just apply X → Xj directly to Rq ☞ easy . . . but it requires “key switching” This gives us a set of “rotations” that allow us to move data between “slots”

Some useful automorphisms Each j ∈ Z∗

n defines an automorphism on Rp that sends X → Xj

Homomorphic evaluation: just apply X → Xj directly to Rq ☞ easy . . . but it requires “key switching” This gives us a set of “rotations” that allow us to move data between “slots”

A simplified (but not very typical) setting: p ≡ 1 (mod n) =⇒ n(X) splits completely over Zp We have: Rp = Zp[X]/(n(X)) ∼ = GF(p)h where h = ϕ(n) via the isomorphism [ƒ(X) mod n(X)] → [ƒ(ω)]∈Z∗

n

where ω ∈ Z∗

p is a primitive nth root of unity

The automorphism X → Xj sends [ƒ(ω)]∈Z∗

n → [ƒ(ωj)]∈Z∗ n

So the data in slot j moves to slot 

A simplified (but not very typical) setting: p ≡ 1 (mod n) =⇒ n(X) splits completely over Zp We have: Rp = Zp[X]/(n(X)) ∼ = GF(p)h where h = ϕ(n) via the isomorphism [ƒ(X) mod n(X)] → [ƒ(ω)]∈Z∗

n

where ω ∈ Z∗

p is a primitive nth root of unity

The automorphism X → Xj sends [ƒ(ω)]∈Z∗

n → [ƒ(ωj)]∈Z∗ n

So the data in slot j moves to slot 

A simplified (but not very typical) setting: p ≡ 1 (mod n) =⇒ n(X) splits completely over Zp We have: Rp = Zp[X]/(n(X)) ∼ = GF(p)h where h = ϕ(n) via the isomorphism [ƒ(X) mod n(X)] → [ƒ(ω)]∈Z∗

n

where ω ∈ Z∗

p is a primitive nth root of unity

The automorphism X → Xj sends [ƒ(ω)]∈Z∗

n → [ƒ(ωj)]∈Z∗ n

So the data in slot j moves to slot 

A simplified (but not very typical) setting: p ≡ 1 (mod n) =⇒ n(X) splits completely over Zp We have: Rp = Zp[X]/(n(X)) ∼ = GF(p)h where h = ϕ(n) via the isomorphism [ƒ(X) mod n(X)] → [ƒ(ω)]∈Z∗

n

where ω ∈ Z∗

p is a primitive nth root of unity

The automorphism X → Xj sends [ƒ(ω)]∈Z∗

n → [ƒ(ωj)]∈Z∗ n

So the data in slot j moves to slot 

General case: the available rotations are determined by the group structure of Z∗

n /〈p〉

Structure theorem: Z∗

n /〈p〉 ∼

= Zn1 × · · · × Znk, where n+1 | n for each  Example: suppose Z∗

n /〈p〉 ∼

= Z3 × Z3 We have 9 slots arranged in a 3 × 3 array:

  1 2 3 4 5 6 7 8  

We can rotate all the rows (simultaneously) by any amount, or all the columns simultaneously by any amount More generally: we have a k-dimensional hypercube, with rotations in each dimension

General case: the available rotations are determined by the group structure of Z∗

n /〈p〉

Structure theorem: Z∗

n /〈p〉 ∼

= Zn1 × · · · × Znk, where n+1 | n for each  Example: suppose Z∗

n /〈p〉 ∼

= Z3 × Z3 We have 9 slots arranged in a 3 × 3 array:

  1 2 3 4 5 6 7 8  

We can rotate all the rows (simultaneously) by any amount, or all the columns simultaneously by any amount More generally: we have a k-dimensional hypercube, with rotations in each dimension

General case: the available rotations are determined by the group structure of Z∗

n /〈p〉

Structure theorem: Z∗

n /〈p〉 ∼

= Zn1 × · · · × Znk, where n+1 | n for each  Example: suppose Z∗

n /〈p〉 ∼

= Z3 × Z3 We have 9 slots arranged in a 3 × 3 array:

  1 2 3 4 5 6 7 8  

We can rotate all the rows (simultaneously) by any amount, or all the columns simultaneously by any amount More generally: we have a k-dimensional hypercube, with rotations in each dimension

General case: the available rotations are determined by the group structure of Z∗

n /〈p〉

Structure theorem: Z∗

n /〈p〉 ∼

= Zn1 × · · · × Znk, where n+1 | n for each  Example: suppose Z∗

n /〈p〉 ∼

= Z3 × Z3 We have 9 slots arranged in a 3 × 3 array:

  1 2 3 4 5 6 7 8  

We can rotate all the rows (simultaneously) by any amount, or all the columns simultaneously by any amount More generally: we have a k-dimensional hypercube, with rotations in each dimension

General case: the available rotations are determined by the group structure of Z∗

n /〈p〉

Structure theorem: Z∗

n /〈p〉 ∼

= Zn1 × · · · × Znk, where n+1 | n for each  Example: suppose Z∗

n /〈p〉 ∼

= Z3 × Z3 We have 9 slots arranged in a 3 × 3 array:

  1 2 3 4 5 6 7 8  

We can rotate all the rows (simultaneously) by any amount, or all the columns simultaneously by any amount More generally: we have a k-dimensional hypercube, with rotations in each dimension

General case: the available rotations are determined by the group structure of Z∗

n /〈p〉

Structure theorem: Z∗

n /〈p〉 ∼

= Zn1 × · · · × Znk, where n+1 | n for each  Example: suppose Z∗

n /〈p〉 ∼

= Z3 × Z3 We have 9 slots arranged in a 3 × 3 array:

  1 2 3 4 5 6 7 8  

We can rotate all the rows (simultaneously) by any amount, or all the columns simultaneously by any amount More generally: we have a k-dimensional hypercube, with rotations in each dimension

The main topic: computing GF(pd)-linear maps Input: an encrypted vector  with h slots in GF(pd) Output: L(), for some fixed, public GF(pd)-linear map L

• Equivalently: M, where M ∈ GF(pd)h×h

The main topic: computing GF(pd)-linear maps Input: an encrypted vector  with h slots in GF(pd) Output: L(), for some fixed, public GF(pd)-linear map L

• Equivalently: M, where M ∈ GF(pd)h×h

An obvious approach: Example: h = 3   11 12 13 21 22 23 31 32 33     1 2 3   =   11 21 31  1 +   12 22 32  2 +   13 23 33  3 =   111 211 311   +   122 222 322   +   133 233 333   Requires a “multibroadcast”:

  1 2 3   →     1 1 1   ,   2 2 2   ,   3 3 3    

• can be done using O(h)

rotations/mul-by-const

• overkill

An obvious approach: Example: h = 3   11 12 13 21 22 23 31 32 33     1 2 3   =   11 21 31  1 +   12 22 32  2 +   13 23 33  3 =   111 211 311   +   122 222 322   +   133 233 333   Requires a “multibroadcast”:

  1 2 3   →     1 1 1   ,   2 2 2   ,   3 3 3    

• can be done using O(h)

rotations/mul-by-const

• overkill

An obvious approach: Example: h = 3   11 12 13 21 22 23 31 32 33     1 2 3   =   11 21 31  1 +   12 22 32  2 +   13 23 33  3 =   111 211 311   +   122 222 322   +   133 233 333   Requires a “multibroadcast”:

  1 2 3   →     1 1 1   ,   2 2 2   ,   3 3 3    

• can be done using O(h)

rotations/mul-by-const

• overkill

A better idea: Cannon [1969], Bernstein [2008] Example: h = 3   11 12 13 21 22 23 31 32 33     1 2 3   =   111 222 333   +   122 233 311   +   133 211 322   The constants C0 = (11, 22, 33), C1 = (12, 23, 31), C2 = (13, 21, 32) constructed using CRT and converted to DoubleCRT . . . as a pre-computation Total cost: h rotations (expensive), h mul-by-const (cheap)

A better idea: Cannon [1969], Bernstein [2008] Example: h = 3   11 12 13 21 22 23 31 32 33     1 2 3   =   111 222 333   +   122 233 311   +   133 211 322   The constants C0 = (11, 22, 33), C1 = (12, 23, 31), C2 = (13, 21, 32) constructed using CRT and converted to DoubleCRT . . . as a pre-computation Total cost: h rotations (expensive), h mul-by-const (cheap)

A better idea: Cannon [1969], Bernstein [2008] Example: h = 3   11 12 13 21 22 23 31 32 33     1 2 3   =   111 222 333   +   122 233 311   +   133 211 322   The constants C0 = (11, 22, 33), C1 = (12, 23, 31), C2 = (13, 21, 32) constructed using CRT and converted to DoubleCRT . . . as a pre-computation Total cost: h rotations (expensive), h mul-by-const (cheap)

A better idea: Cannon [1969], Bernstein [2008] Example: h = 3   11 12 13 21 22 23 31 32 33     1 2 3   =   111 222 333   +   122 233 311   +   133 211 322   The constants C0 = (11, 22, 33), C1 = (12, 23, 31), C2 = (13, 21, 32) constructed using CRT and converted to DoubleCRT . . . as a pre-computation Total cost: h rotations (expensive), h mul-by-const (cheap)

A better idea: Cannon [1969], Bernstein [2008] Example: h = 3   11 12 13 21 22 23 31 32 33     1 2 3   =   111 222 333   +   122 233 311   +   133 211 322   The constants C0 = (11, 22, 33), C1 = (12, 23, 31), C2 = (13, 21, 32) constructed using CRT and converted to DoubleCRT . . . as a pre-computation Total cost: h rotations (expensive), h mul-by-const (cheap)

A better idea: Cannon [1969], Bernstein [2008] Example: h = 3   11 12 13 21 22 23 31 32 33     1 2 3   =   111 222 333   +   122 233 311   +   133 211 322   The constants C0 = (11, 22, 33), C1 = (12, 23, 31), C2 = (13, 21, 32) constructed using CRT and converted to DoubleCRT . . . as a pre-computation Total cost: h rotations (expensive), h mul-by-const (cheap)

An even better idea: baby-step/giant-step Let ρ() denote rotation of  by  positions We want to compute L() =

• ∈[h] C · ρ() for constants C0, . . . , Ch−1

Observation: ρ is an automorphism on the plaintext space Rp L() =

• ∈[h]

C · ρ() =

• j∈[ƒ]
• k∈[g]

Cj+ƒk · ρj+ƒk(), where ƒ, g ≈

• h

=

• k∈[g]

ρƒk

j∈[ƒ]

C′

j+ƒk · ρj()

• ,

where C′

j+ƒk := ρ−ƒk(Cj+ƒk)

An even better idea: baby-step/giant-step Let ρ() denote rotation of  by  positions We want to compute L() =

• ∈[h] C · ρ() for constants C0, . . . , Ch−1

Observation: ρ is an automorphism on the plaintext space Rp L() =

• ∈[h]

C · ρ() =

• j∈[ƒ]
• k∈[g]

Cj+ƒk · ρj+ƒk(), where ƒ, g ≈

• h

=

• k∈[g]

ρƒk

j∈[ƒ]

C′

j+ƒk · ρj()

• ,

where C′

j+ƒk := ρ−ƒk(Cj+ƒk)

An even better idea: baby-step/giant-step Let ρ() denote rotation of  by  positions We want to compute L() =

• ∈[h] C · ρ() for constants C0, . . . , Ch−1

Observation: ρ is an automorphism on the plaintext space Rp L() =

• ∈[h]

C · ρ() =

• j∈[ƒ]
• k∈[g]

Cj+ƒk · ρj+ƒk(), where ƒ, g ≈

• h

=

• k∈[g]

ρƒk

j∈[ƒ]

C′

j+ƒk · ρj()

• ,

where C′

j+ƒk := ρ−ƒk(Cj+ƒk)

An even better idea: baby-step/giant-step Let ρ() denote rotation of  by  positions We want to compute L() =

• ∈[h] C · ρ() for constants C0, . . . , Ch−1

Observation: ρ is an automorphism on the plaintext space Rp L() =

• ∈[h]

C · ρ() =

• j∈[ƒ]
• k∈[g]

Cj+ƒk · ρj+ƒk(), where ƒ, g ≈

• h

=

• k∈[g]

ρƒk

j∈[ƒ]

C′

j+ƒk · ρj()

• ,

where C′

j+ƒk := ρ−ƒk(Cj+ƒk)

An even better idea: baby-step/giant-step Let ρ() denote rotation of  by  positions We want to compute L() =

• ∈[h] C · ρ() for constants C0, . . . , Ch−1

Observation: ρ is an automorphism on the plaintext space Rp L() =

• ∈[h]

C · ρ() =

• j∈[ƒ]
• k∈[g]

Cj+ƒk · ρj+ƒk(), where ƒ, g ≈

• h

=

• k∈[g]

ρƒk

j∈[ƒ]

C′

j+ƒk · ρj()

• ,

where C′

j+ƒk := ρ−ƒk(Cj+ƒk)

An even better idea: baby-step/giant-step Let ρ() denote rotation of  by  positions We want to compute L() =

• ∈[h] C · ρ() for constants C0, . . . , Ch−1

Observation: ρ is an automorphism on the plaintext space Rp L() =

• ∈[h]

C · ρ() =

• j∈[ƒ]
• k∈[g]

Cj+ƒk · ρj+ƒk(), where ƒ, g ≈

• h

=

• k∈[g]

ρƒk

j∈[ƒ]

C′

j+ƒk · ρj()

• ,

where C′

j+ƒk := ρ−ƒk(Cj+ƒk)

Baby-step/giant-step algorithm:

• 1. for each j ∈ [ƒ]: compute j ← ρj()

// baby steps

• 2. for each k ∈ [g]: compute k ←
• j∈[ƒ] C′

j+ƒk · j

• 3. compute  ←
• k∈[g] ρƒk(k)

// giant steps Cost:

• Step 1: ≈
• h rotations
• Step 2: ≈ h mul-by-const
• Step 3: ≈
• h rotations

Baby-step/giant-step algorithm:

• 1. for each j ∈ [ƒ]: compute j ← ρj()

// baby steps

• 2. for each k ∈ [g]: compute k ←
• j∈[ƒ] C′

j+ƒk · j

• 3. compute  ←
• k∈[g] ρƒk(k)

// giant steps Cost:

• Step 1: ≈
• h rotations
• Step 2: ≈ h mul-by-const
• Step 3: ≈
• h rotations

Baby-step/giant-step algorithm:

• 1. for each j ∈ [ƒ]: compute j ← ρj()

// baby steps

• 2. for each k ∈ [g]: compute k ←
• j∈[ƒ] C′

j+ƒk · j

• 3. compute  ←
• k∈[g] ρƒk(k)

// giant steps Cost:

• Step 1: ≈
• h rotations
• Step 2: ≈ h mul-by-const
• Step 3: ≈
• h rotations

Baby-step/giant-step algorithm:

• 1. for each j ∈ [ƒ]: compute j ← ρj()

// baby steps

• 2. for each k ∈ [g]: compute k ←
• j∈[ƒ] C′

j+ƒk · j

• 3. compute  ←
• k∈[g] ρƒk(k)

// giant steps Cost:

• Step 1: ≈
• h rotations
• Step 2: ≈ h mul-by-const
• Step 3: ≈
• h rotations

An even more better idea(?)

• r . . . “if 2
• h rotations are good, then a single rotation is better”

Anatomy of a homomorphic rotation

We want to apply a rotation ρ to an encrypted vector  The ciphertext is a pair (c0, c1) ∈ R2×1

q

A) Raw automorphism step (cheap): c′

j ← ρ(cj) for j = 0,1

B) Key Switching, part 1 – break into digits (expensive): decompose c′

1 as c′ 1 =

• k d′

kRk, where the Rk’s are integer

constants and each “digit” d′

k has small norm ☞ requires DoubleCRT/coefficient conversion

C) Key Switching, part 2 – apply key switching matrix (cheap): compute the ciphertext (c′

0 + c′′ 0 , c′′ 1 ), where c′′ j =

• k d′

kAjk and the

Ajk’s are pre-computed DoubleCRT objects

An even more better idea(?)

• r . . . “if 2
• h rotations are good, then a single rotation is better”

Anatomy of a homomorphic rotation

We want to apply a rotation ρ to an encrypted vector  The ciphertext is a pair (c0, c1) ∈ R2×1

q

A) Raw automorphism step (cheap): c′

j ← ρ(cj) for j = 0,1

B) Key Switching, part 1 – break into digits (expensive): decompose c′

1 as c′ 1 =

• k d′

kRk, where the Rk’s are integer

constants and each “digit” d′

k has small norm ☞ requires DoubleCRT/coefficient conversion

C) Key Switching, part 2 – apply key switching matrix (cheap): compute the ciphertext (c′

0 + c′′ 0 , c′′ 1 ), where c′′ j =

• k d′

kAjk and the

Ajk’s are pre-computed DoubleCRT objects

An even more better idea(?)

• r . . . “if 2
• h rotations are good, then a single rotation is better”

Anatomy of a homomorphic rotation

We want to apply a rotation ρ to an encrypted vector  The ciphertext is a pair (c0, c1) ∈ R2×1

q

A) Raw automorphism step (cheap): c′

j ← ρ(cj) for j = 0,1

B) Key Switching, part 1 – break into digits (expensive): decompose c′

1 as c′ 1 =

• k d′

kRk, where the Rk’s are integer

constants and each “digit” d′

k has small norm ☞ requires DoubleCRT/coefficient conversion

C) Key Switching, part 2 – apply key switching matrix (cheap): compute the ciphertext (c′

0 + c′′ 0 , c′′ 1 ), where c′′ j =

• k d′

kAjk and the

Ajk’s are pre-computed DoubleCRT objects

An even more better idea(?)

• r . . . “if 2
• h rotations are good, then a single rotation is better”

Anatomy of a homomorphic rotation

We want to apply a rotation ρ to an encrypted vector  The ciphertext is a pair (c0, c1) ∈ R2×1

q

A) Raw automorphism step (cheap): c′

j ← ρ(cj) for j = 0,1

B) Key Switching, part 1 – break into digits (expensive): decompose c′

1 as c′ 1 =

• k d′

kRk, where the Rk’s are integer

constants and each “digit” d′

k has small norm ☞ requires DoubleCRT/coefficient conversion

C) Key Switching, part 2 – apply key switching matrix (cheap): compute the ciphertext (c′

0 + c′′ 0 , c′′ 1 ), where c′′ j =

• k d′

kAjk and the

Ajk’s are pre-computed DoubleCRT objects

An even more better idea(?)

• r . . . “if 2
• h rotations are good, then a single rotation is better”

Anatomy of a homomorphic rotation

We want to apply a rotation ρ to an encrypted vector  The ciphertext is a pair (c0, c1) ∈ R2×1

q

A) Raw automorphism step (cheap): c′

j ← ρ(cj) for j = 0,1

B) Key Switching, part 1 – break into digits (expensive): decompose c′

1 as c′ 1 =

• k d′

kRk, where the Rk’s are integer

constants and each “digit” d′

k has small norm ☞ requires DoubleCRT/coefficient conversion

C) Key Switching, part 2 – apply key switching matrix (cheap): compute the ciphertext (c′

0 + c′′ 0 , c′′ 1 ), where c′′ j =

• k d′

kAjk and the

Ajk’s are pre-computed DoubleCRT objects

An even more better idea(?)

• r . . . “if 2
• h rotations are good, then a single rotation is better”

Anatomy of a homomorphic rotation

We want to apply a rotation ρ to an encrypted vector  The ciphertext is a pair (c0, c1) ∈ R2×1

q

A) Raw automorphism step (cheap): c′

j ← ρ(cj) for j = 0,1

B) Key Switching, part 1 – break into digits (expensive): decompose c′

1 as c′ 1 =

• k d′

kRk, where the Rk’s are integer

constants and each “digit” d′

k has small norm ☞ requires DoubleCRT/coefficient conversion

C) Key Switching, part 2 – apply key switching matrix (cheap): compute the ciphertext (c′

0 + c′′ 0 , c′′ 1 ), where c′′ j =

• k d′

kAjk and the

Ajk’s are pre-computed DoubleCRT objects

An even more better idea(?)

• r . . . “if 2
• h rotations are good, then a single rotation is better”

Anatomy of a homomorphic rotation

We want to apply a rotation ρ to an encrypted vector  The ciphertext is a pair (c0, c1) ∈ R2×1

q

A) Raw automorphism step (cheap): c′

j ← ρ(cj) for j = 0,1

B) Key Switching, part 1 – break into digits (expensive): decompose c′

1 as c′ 1 =

• k d′

kRk, where the Rk’s are integer

constants and each “digit” d′

k has small norm ☞ requires DoubleCRT/coefficient conversion

C) Key Switching, part 2 – apply key switching matrix (cheap): compute the ciphertext (c′

0 + c′′ 0 , c′′ 1 ), where c′′ j =

• k d′

kAjk and the

Ajk’s are pre-computed DoubleCRT objects

An even more better idea(?)

• r . . . “if 2
• h rotations are good, then a single rotation is better”

Anatomy of a homomorphic rotation

We want to apply a rotation ρ to an encrypted vector  The ciphertext is a pair (c0, c1) ∈ R2×1

q

A) Raw automorphism step (cheap): c′

j ← ρ(cj) for j = 0,1

B) Key Switching, part 1 – break into digits (expensive): decompose c′

1 as c′ 1 =

• k d′

kRk, where the Rk’s are integer

constants and each “digit” d′

k has small norm ☞ requires DoubleCRT/coefficient conversion

C) Key Switching, part 2 – apply key switching matrix (cheap): compute the ciphertext (c′

0 + c′′ 0 , c′′ 1 ), where c′′ j =

• k d′

kAjk and the

Ajk’s are pre-computed DoubleCRT objects

The idea: re-factor this three step process ✸ Basically, just swap steps (A) and (B), using the fact that ρ is an automorphism that does not change the norm by very much A’) Key Switching, part 1 – break into digits (expensive): decompose the original c1 as c1 =

• k dkRk

B’) Raw automorphism step (cheap): c′

0 ← ρ(c0) and d′ k ← ρ(dk)

for each k C) Key Switching, part 2 – apply key switching matrix (cheap): exactly the same as above: compute (c′

0 + c′′ 0 , c′′ 1 ), where

c′′

j =

• k d′

kAjk

Why is this better? . . . we can perform step (A’) just once for many rotations ρ

The idea: re-factor this three step process ✸ Basically, just swap steps (A) and (B), using the fact that ρ is an automorphism that does not change the norm by very much A’) Key Switching, part 1 – break into digits (expensive): decompose the original c1 as c1 =

• k dkRk

B’) Raw automorphism step (cheap): c′

0 ← ρ(c0) and d′ k ← ρ(dk)

for each k C) Key Switching, part 2 – apply key switching matrix (cheap): exactly the same as above: compute (c′

0 + c′′ 0 , c′′ 1 ), where

c′′

j =

• k d′

kAjk

Why is this better? . . . we can perform step (A’) just once for many rotations ρ

The idea: re-factor this three step process ✸ Basically, just swap steps (A) and (B), using the fact that ρ is an automorphism that does not change the norm by very much A’) Key Switching, part 1 – break into digits (expensive): decompose the original c1 as c1 =

• k dkRk

B’) Raw automorphism step (cheap): c′

0 ← ρ(c0) and d′ k ← ρ(dk)

for each k C) Key Switching, part 2 – apply key switching matrix (cheap): exactly the same as above: compute (c′

0 + c′′ 0 , c′′ 1 ), where

c′′

j =

• k d′

kAjk

Why is this better? . . . we can perform step (A’) just once for many rotations ρ

The idea: re-factor this three step process ✸ Basically, just swap steps (A) and (B), using the fact that ρ is an automorphism that does not change the norm by very much A’) Key Switching, part 1 – break into digits (expensive): decompose the original c1 as c1 =

• k dkRk

B’) Raw automorphism step (cheap): c′

0 ← ρ(c0) and d′ k ← ρ(dk)

for each k C) Key Switching, part 2 – apply key switching matrix (cheap): exactly the same as above: compute (c′

0 + c′′ 0 , c′′ 1 ), where

c′′

j =

• k d′

kAjk

Why is this better? . . . we can perform step (A’) just once for many rotations ρ

The idea: re-factor this three step process ✸ Basically, just swap steps (A) and (B), using the fact that ρ is an automorphism that does not change the norm by very much A’) Key Switching, part 1 – break into digits (expensive): decompose the original c1 as c1 =

• k dkRk

B’) Raw automorphism step (cheap): c′

0 ← ρ(c0) and d′ k ← ρ(dk)

for each k C) Key Switching, part 2 – apply key switching matrix (cheap): exactly the same as above: compute (c′

0 + c′′ 0 , c′′ 1 ), where

c′′

j =

• k d′

kAjk

Why is this better? . . . we can perform step (A’) just once for many rotations ρ

The idea: re-factor this three step process ✸ Basically, just swap steps (A) and (B), using the fact that ρ is an automorphism that does not change the norm by very much A’) Key Switching, part 1 – break into digits (expensive): decompose the original c1 as c1 =

• k dkRk

B’) Raw automorphism step (cheap): c′

0 ← ρ(c0) and d′ k ← ρ(dk)

for each k C) Key Switching, part 2 – apply key switching matrix (cheap): exactly the same as above: compute (c′

0 + c′′ 0 , c′′ 1 ), where

c′′

j =

• k d′

kAjk

Why is this better? . . . we can perform step (A’) just once for many rotations ρ

We call this idea “hoisting” (optimizing compilers are said to “hoist” invariant computations out of a loop) So . . . given an encryption of  we can compute an encryption of ρ() for  ∈ [h] with just one expensive step and h cheap steps Application to matrix multiplication:

• n the one hand . . . faster than the basic method (which takes h

rotations)

• n the other hand . . . may be slower than the BS/GS method for

large h but on the other hand . . . we can combine hoisting and BS/GS

baby steps: for each j ∈ [ƒ] compute j ← ρj() hoist out these rotations save a factor of 2 (2

• h −→
• h rotations)

We call this idea “hoisting” (optimizing compilers are said to “hoist” invariant computations out of a loop) So . . . given an encryption of  we can compute an encryption of ρ() for  ∈ [h] with just one expensive step and h cheap steps Application to matrix multiplication:

• n the one hand . . . faster than the basic method (which takes h

rotations)

• n the other hand . . . may be slower than the BS/GS method for

large h but on the other hand . . . we can combine hoisting and BS/GS

baby steps: for each j ∈ [ƒ] compute j ← ρj() hoist out these rotations save a factor of 2 (2

• h −→
• h rotations)

We call this idea “hoisting” (optimizing compilers are said to “hoist” invariant computations out of a loop) So . . . given an encryption of  we can compute an encryption of ρ() for  ∈ [h] with just one expensive step and h cheap steps Application to matrix multiplication:

• n the one hand . . . faster than the basic method (which takes h

rotations)

• n the other hand . . . may be slower than the BS/GS method for

large h but on the other hand . . . we can combine hoisting and BS/GS

baby steps: for each j ∈ [ƒ] compute j ← ρj() hoist out these rotations save a factor of 2 (2

• h −→
• h rotations)

We call this idea “hoisting” (optimizing compilers are said to “hoist” invariant computations out of a loop) So . . . given an encryption of  we can compute an encryption of ρ() for  ∈ [h] with just one expensive step and h cheap steps Application to matrix multiplication:

• n the one hand . . . faster than the basic method (which takes h

rotations)

• n the other hand . . . may be slower than the BS/GS method for

large h but on the other hand . . . we can combine hoisting and BS/GS

baby steps: for each j ∈ [ƒ] compute j ← ρj() hoist out these rotations save a factor of 2 (2

• h −→
• h rotations)

We call this idea “hoisting” (optimizing compilers are said to “hoist” invariant computations out of a loop) So . . . given an encryption of  we can compute an encryption of ρ() for  ∈ [h] with just one expensive step and h cheap steps Application to matrix multiplication:

• n the one hand . . . faster than the basic method (which takes h

rotations)

• n the other hand . . . may be slower than the BS/GS method for

large h but on the other hand . . . we can combine hoisting and BS/GS

baby steps: for each j ∈ [ƒ] compute j ← ρj() hoist out these rotations save a factor of 2 (2

• h −→
• h rotations)

We call this idea “hoisting” (optimizing compilers are said to “hoist” invariant computations out of a loop) So . . . given an encryption of  we can compute an encryption of ρ() for  ∈ [h] with just one expensive step and h cheap steps Application to matrix multiplication:

• n the one hand . . . faster than the basic method (which takes h

rotations)

• n the other hand . . . may be slower than the BS/GS method for

large h but on the other hand . . . we can combine hoisting and BS/GS

baby steps: for each j ∈ [ƒ] compute j ← ρj() hoist out these rotations save a factor of 2 (2

• h −→
• h rotations)

We call this idea “hoisting” (optimizing compilers are said to “hoist” invariant computations out of a loop) So . . . given an encryption of  we can compute an encryption of ρ() for  ∈ [h] with just one expensive step and h cheap steps Application to matrix multiplication:

• n the one hand . . . faster than the basic method (which takes h

rotations)

• n the other hand . . . may be slower than the BS/GS method for

large h but on the other hand . . . we can combine hoisting and BS/GS

baby steps: for each j ∈ [ƒ] compute j ← ρj() hoist out these rotations save a factor of 2 (2

• h −→
• h rotations)

We call this idea “hoisting” (optimizing compilers are said to “hoist” invariant computations out of a loop) So . . . given an encryption of  we can compute an encryption of ρ() for  ∈ [h] with just one expensive step and h cheap steps Application to matrix multiplication:

• n the one hand . . . faster than the basic method (which takes h

rotations)

• n the other hand . . . may be slower than the BS/GS method for

large h but on the other hand . . . we can combine hoisting and BS/GS

baby steps: for each j ∈ [ƒ] compute j ← ρj() hoist out these rotations save a factor of 2 (2

• h −→
• h rotations)

We call this idea “hoisting” (optimizing compilers are said to “hoist” invariant computations out of a loop) So . . . given an encryption of  we can compute an encryption of ρ() for  ∈ [h] with just one expensive step and h cheap steps Application to matrix multiplication:

• n the one hand . . . faster than the basic method (which takes h

rotations)

• n the other hand . . . may be slower than the BS/GS method for

large h but on the other hand . . . we can combine hoisting and BS/GS

baby steps: for each j ∈ [ƒ] compute j ← ρj() hoist out these rotations save a factor of 2 (2

• h −→
• h rotations)

See paper for more details and other improvements: ➪ More efficient handling of “problematic” dimensions in the hypercube ➪ Saving space: drastic reduction in the number of “key switching matrices” without too much loss in speed Questions?

See paper for more details and other improvements: ➪ More efficient handling of “problematic” dimensions in the hypercube ➪ Saving space: drastic reduction in the number of “key switching matrices” without too much loss in speed Questions?

See paper for more details and other improvements: ➪ More efficient handling of “problematic” dimensions in the hypercube ➪ Saving space: drastic reduction in the number of “key switching matrices” without too much loss in speed Questions?

See paper for more details and other improvements: ➪ More efficient handling of “problematic” dimensions in the hypercube ➪ Saving space: drastic reduction in the number of “key switching matrices” without too much loss in speed Questions?