Representing contexts

[ots22]

The other part of the input to a program is an object representing the other input data to the HE library (there would be a context type for each library).

It represents the interface to the library for evaluating a gate in our circuit representation.

Does the context object take care of library-specific optimizations to the circuit?

[adriagascon]

This white paper that came out from the homomorphic encryption standarisation workshop would be helpful here.

They talk about a cryptographic context:

The Cryptographic Context captures the state of homomorphic encryption/evaluation session, instructs the compiler how to generate a circuit, and further determines the cryptographic library that provides the instruction set

I think we should all read that document, as they also define a assembly language for homomorphic encryption, described generally as:

Circuit Description information, which includes information on the circuits being executed; these circuits can be hand-constructed, or output by tools such as a homomorphic encryption circuit compiler. These circuits include low-level calls to library functions, and can be to some extent library-specific for optimizations.

[ots22]

Just a sketch, but one possible approach would be something like this, where the compilation step is performed outside of the context.

// Base class - abstract interface to each library
class Context {

    // add eight bit numbers
    virtual ? add8(?,?);

};

class ClearContext : public Context {

    add8() {
        // just add them...
    }

};

class TFHEContext : public Context {

    add8() {
        // expand into eight individual bits and combine with an adder circuit
    }

};

class Compiler {
public:
    CircuitEvaluator compile(const Context & ctx, const Circuit & circ)
    {
        // for each gate in the circuit, build
    }
};

class CircuitEvaluator {
public:
        void eval(const Array &inputs, Array &output, double& time);
}

[ots22]

Alternatively, compile could be a method of each context concrete type:

// Base class - abstract interface to each library
class Context {

    // add eight bit numbers
    virtual ? add8(?,?);
    virtual CircuitEvaluator compile(const Context & ctx, const Circuit & circ);

};

class ClearContext : public Context {

    add8() {
        // just add them...
    }

    // each Context concrete class provides its own compile
    // method, which can perform any library-specific
    // optimization.
    CircuitEvaluator compile() {
        // ...
    }
};

class TFHEContext : public Context {

    add8() {
        // expand into eight individual bits and combine with an adder circuit
    }
    CircuitEvaluator compile() {
        // ...
    }
};

[ots22]

The first case seems simpler to implement to me, but the second case possibly opens up some more library specific optimization opportunities.

[adriagascon]

We could do the later and define compile in the superclass Context right? That would give us your first proposal and the ability to overwrite the compile function if necessary.

In any case, I think we should go with the first option initially, which is simpler.

[ots22]

What should the name be? "Context" or "HELibrary" or something else?

[ots22]

"CryptoContext"

[nbarlowATI]

From the "API White Paper" http://homomorphicencryption.org/white_papers/API_homomorphic_encryption_white_paper.pdf what they call "Cryptographic Context" has:

• Scheme ID - identify the homomorphic scheme e.g. BGV or FV
• Scheme independent parameters - e.g. RLWE parameters, plaintext parameters
• Scheme dependent parameters.

So I think their idea of a Cryptographic context is a bit different to what we were thinking - rather than something that holds a load of data, including some about what scheme is being used, we have talked about having a concrete class for each library, that actually handles the translation from a gate in the circuit into a function call to the library..