Design and Implementation of a Homomorphic ... - Researcher
Design and Implementation of a Homomorphic ... - Researcher
Design and Implementation of a Homomorphic ... - Researcher
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
void addAllMatrices(FHESecKey& sKey, long keyID=0);<br />
For i = keyID, generate key-switching matrices W [s i (X t ) ⇒ s i (X)] for all t ∈ Z ∗ m.<br />
void add1DMatrices(FHESecKey& sKey, long keyID=0);<br />
For i = keyID, generate key-switching matrices W [s i (X ge ) ⇒ s i (X)] for every generator g <strong>of</strong><br />
Z ∗ m/ 〈2〉 with order ord(g), <strong>and</strong> every exponent 0 < e < ord(g). Also if the order <strong>of</strong> g in Z ∗ m is<br />
not the same as its order in Z ∗ m/ 〈2〉, then generate also the matrices W [s i (X g−e ) ⇒ s i (X)]<br />
(cf. Section 2.4).<br />
We note that these matrices are enough to implement all the automorphisms that are needed<br />
for the data-movement routines from Section 4.<br />
void addSome1DMatrices(FHESecKey& sKey, long bound=100,long keyID=0);<br />
For i = keyID, we generate just a subset <strong>of</strong> the matrices that are generated by add1DMatrices,<br />
so that each <strong>of</strong> the automorphisms X ↦→ X ge can be implemented by at most two steps (<strong>and</strong><br />
similarly for X ↦→ X g−e for generators whose orders in Z ∗ m <strong>and</strong> Z ∗ m/ 〈2〉 are different). In<br />
other words, we ensure that the graph G i (cf. Section 3.2.2) has a path <strong>of</strong> length at most 2<br />
from g e to 1 (<strong>and</strong> also from g −e to 1 for g’s <strong>of</strong> different orders).<br />
In more details, if ord(g) ≤ bound then we generate all the matrices W [s i (X ge ) ⇒ s i (X)]<br />
(or W [s i (X g−e ) ⇒ s i (X)]) just like in add1DMatrices. When ord(g) > bound, however, we<br />
generate only O( √ ord(g)) matrices for this generator: Denoting B g = ⌈ √ ord(g)⌉, for every<br />
0 < e < B g let e ′ = e · B g mod m, then we generate the matrices W [s i (X ge ) ⇒ s i (X)] <strong>and</strong><br />
W [s i (X ge′ ) ⇒ s i [(X)]. In addition, ] if if g has a different order in Z ∗ m <strong>and</strong> Z ∗ m/ 〈2〉 then we<br />
generate also W s i (X g−e′ ) ⇒ s i (X) .<br />
void addFrbMatrices(FHESecKey& sKey, long keyID=0);<br />
For i = keyID, generate key-switching matrices W [s i (X 2e ) ⇒ s i (X)] for 0 < e < d where d is<br />
the order <strong>of</strong> 2 in Z ∗ m.<br />
4 The Data-Movement Layer<br />
At the top level <strong>of</strong> our library, we provide some interfaces that allow the application to manipulate<br />
arrays <strong>of</strong> plaintext values homomorphically. The arrays are translated to plaintext polynomials using<br />
the encoding/decoding routines provided by PAlgebraModTwo/PAlgebraMod2r (cf. Section 2.5),<br />
<strong>and</strong> then encrypted <strong>and</strong> manipulated homomorphically using the lower-level interfaces from the<br />
crypto layer.<br />
4.1 The classes EncryptedArray <strong>and</strong> EncryptedArrayMod2r<br />
These classes present the plaintext values to the application as either a linear array (with as many<br />
entries as there are elements in Z ∗ m/ 〈2〉), or as a multi-dimensional array corresponding to the<br />
structure <strong>of</strong> the group Z ∗ m/ 〈2〉. The difference between EncryptedArray <strong>and</strong> EncryptedArrayMod2r<br />
is that the former is used when the plaintext-space modulus is 2, while the latter is used when it is<br />
2 r for some r > 1. Another difference between them is that EncryptedArray supports also plaintext<br />
values in binary extension fields F 2 n, while EncryptedArrayMod2r only support integer plaintext<br />
values from Z 2 r. This is reflected in the constructor for these types: For EncryptedArray we have<br />
the constructor<br />
29