HElib: src/Ctxt.h File Reference

HElib 1.0 Implementing Homomorphic Encryption

- Main Page
- Classes
- Files

- File List
- File Members

All Classes Files Functions Variables Friends Pages
Classes | Functions
Ctxt.h File Reference

Declerations of a BGV-type cipehrtext and key-switching matrices. More...

`#include <vector>`
`#include <NTL/xdouble.h>`
`#include "DoubleCRT.h"`

Go to the source code of this file.

## Classes
class | SKHandle
| A handle, describing the secret-key element that "matches" a part, of the form s^r(X^t). More...
class | CtxtPart
| One entry in a ciphertext vector. More...
class | Ctxt
| A Ctxt object holds a single cipehrtext. More...

## Functions
ostream & | operator<< (ostream &s, const SKHandle &handle)
istream & | operator>> (istream &s, CtxtPart &p)
ostream & | operator<< (ostream &s, const CtxtPart &p)
IndexSet | baseSetOf (const Ctxt &c)
void | CheckCtxt (const Ctxt &c, const char *label)

## Detailed Description

Declerations of a BGV-type cipehrtext and key-switching matrices.

A ciphertext is a vector of "ciphertext parts", each part consists of a polynomial (element of polynomial ring R_Q) and a "handle" describing the secret-key polynomial that this part multiplies during decryption. For example:

- A "canonical" ciphertext has two parts, the first part multiplies 1 and the second multiplies the "base" secret key s.
- When you multiply two canonical ciphertexts you get a 3-part ciphertext, with parts corresponding to 1, s, and s^2.
- When you apply automorphism X->X^t to a generic ciphertext, then
  - the part corresponding to 1 still remains wrt 1
  - every other part corresponding to some s' will now be corresponding to the polynomial s'(X^t) mod Phi_m(X)

This type of representation lets you in principle add ciphertexts that are defined with respect to different keys:

- For parts of the two cipehrtexts that point to the same secret-key polynomial, you just add the two Double-CRT polynomials
- Parts in one ciphertext that do not have counter-part in the other cipehrtext will just be included in the result intact. For example, you have the ciphertexts C1 = (a relative to 1, b relative to s) C2 = (u relative to 1, v relative to s(X^3)) Then their sum will be C1+C2 = (a+u relative to 1, b relative to s, v relative to s(X^3))

Similarly, in principle you can also multiply arbitrary cipehrtexts, even ones that are defined with respect to different keys, and the result will be defined with respect to the tensor product of the two keys.

The current implementation is more restrictive, however. It requires that a ciphertext has one part wrt 1, that for every r>=1 there is at most one part wrt to s^r(X^t) (for some t), and that the r's are consecutive. For example you cannot have parts wrt (1,s,s^3) without having a part wrt s^2.

It follows that you can only add/multiply ciphertexts if one of the two lists of handles is a prefix of the other. For example, one can add a ciphertext wrt (1,s(X^2)) to another wrt (1,s(X^2),s^2(X^2)), but not to another ciphertext wrt (1,s).