Code Monkey home page Code Monkey logo

homomorphic-implementors-toolkit's Introduction

Homomorphic Implementor's Toolkit

HIT provides tools to simplify the process of designing homomorphic circuits for the CKKS homomorphic encryption scheme. This library is intended to further research in homomorphic encryption. Users must be aware of the security issues surrounding the deployment of CKKS homomorphic encryption; see SECURITY.md for details. This branch of the HIT repository uses the Microsoft SEAL homomorphic encryption library as a backend. See the lattigo-backend branch for a version of HIT based on Lattigo.

Build Status:

  • Ubuntu 18.04 GCC 9 Build Status
  • Ubuntu 18.04 Clang 10 Build Status

Table of Contents

Introduction

Homomorphic encryption is a special type of encryption scheme which enables computation of arbitrary functions on encrypted data. To evaluate a function f, a developer must implement f as a circuit F using only the "native" operation supported by the underlying homomorphic encryption scheme. Libraries which implement homomorphic encryption provide an API for these native operations which can be used to create homomorphic circuits. Creating a circuit also requires tracking ciphertext metadata throughout the computation such as ciphertext level, degree, and scale. This becomes infeasible for all but the smallest circuits.

Evaluators

HIT simplifies this process by providing an abstract homomorphic evaluation API that allows a circuit to be written once, but evaluated in many different ways, including:

  • Homomorphic evalaution: This is the basic evaluation strategy provided by a generic homomorphic encryption library. This branch of HIT uses the Microsoft SEAL homomorphic encryption library to evaluate circuits on encrypted inputs.

  • Count the number of operations in the circuit. Homomorphic operations are expensive to compute, and it is useful to know how changes to the circuit affect the number of operations being performed.

  • Compute the multiplicative depth of a circuit. The multiplicative depth of a homomorphic circuit is the maximum number of multiplications along any path through the circuit. This circuit property is the most important factor in the efficiency of circuit evaluation. Computing the depth of a circuit by hand requires tedious tracking of ciphertext metadata; HIT provides a programmatic way to compute circuit depth. Knowing the depth of a circuit is also important when selecting cryptosystem paramters for homomorphic evaluation.

  • Estimate the CKKS scale parameter. CKKS homomorphic encryption has a scale parameter, which controls the precision of the homomorphic computation. It can be difficult to know what value to use for the scale parameter. By running the circuit on representative input, HIT helps developers choose an appropriate value for this parameter.

  • Evaluate the circuit on plaintexts. Evaluating a homomorphic circuit can give unexpected results for several reasons. One of the most basic is that the circuit does not compute the desired function (e.g., a constant is incorrect, or it uses a multiplication instead of an addition). We can verify the correctness of the circuit by evaluating the circuit on plaintexts: if we get the expected result, we can eliminate the basic circuit as a souce of error.

  • Evaluate the circuit on plaintext and ciphertext input simultaneously: If the circuit gives the expected result on plaintexts but fails on encrypted inputs, the problem is related to details of homomorphic encryption. For example:

    • CKKS ciphertexts have a limited capacity. If a plaintext value exceeds this capacity, the ciphertext overflows, and the plaintext is lost.
    • CKKS is an approximate homomorphic encryption scheme. It's possible that the error incurred during CKKS encryption and homomorphic operations is too great.

    By running the plaintext and ciphertext computations in parallel, HIT can compare the results after each step and help the developer understand where the computation is failing.

  • Track explicit rotations required by the circuit. This is useful in order to obtain a minimal set of rotation keys required by the circuit when generating keys for homomorphic evaluation. Note that bootstrapping implicitly uses rotation/Galois keys, but this evaluator only tracks explicit rotations (i.e., calls to rotateLeft or rotateRight). Bootstrapping keys are automatically generated when parameters support bootstrapping and additional Galois keys are generated as needed for bootstrapping.

Linear Algebra API

Developing a homomorphic circuit requires a scheme to encode function inputs as CKKS ciphertexts. Depending on the complexity of the encoding scheme, a developer may end up writing many "assembly" instructions: higher level instructions composed of native instructions that operate on encoded plaintexts. HIT provides this type of API for linear algebra operations based on the framework described in this paper. Using this API, it is easy for a developer to create a circuit for a function based on linear algebra. It handles encoding of linear algebra objects, and provides high-level "assembly" instructions for linear algebra operations.

CKKS Parameters

Homomorphic encryption schemes require many parameters which interact in complex ways to affect security. HIT helps developers by exposing APIs that are oriented towards the computation. First, HIT helps developers get some basic parameter requirements based on the circuit, such as the circuit depth and estimated scale. Based on these circuit parameters, HIT selects HE parameters which meet the desired computation requirements and also provide adequate security by default. When using the homomorphic evaluator, HIT targets 128-bit security by default. However, this limits parameters to those standardized in http://homomorphicencryption.org/white_papers/security_homomorphic_encryption_white_paper.pdf. Since some applications will require larger parameters, users can use non-standard parameters at their own risk with the use_standard_params=false flag when creating CKKS parameters.

Deploying a Homomorphic Function

A homomorphic function is typcially deployed in a client/server model:

   Client                                       Server
   ------                                       ------

Generate Keys

Encode and Encrypt Data

Transmit encrypted data,
parameters, and public     ---------->
keys to server
                                         Evaluate the target circuit
                                         on the encrypted inputs

                           <----------   Transmit circuit outputs (ciphertexts)
                                         back to the client
Use the private key to
decrypt the circuit
outputs

HIT provides serialization and deserialization of CKKS parameters and encrypted objects to facilitate the deployment of homomorphic functions. See examples/example_5_serialization.cpp for a detailed example of how HIT can be used to as part of the client and server in this model.

Homomorphic encryption schemes satisfy semantic security, but not CCA security. In particular, this means that ciphertexts serialized by HIT are unauthenticated. Thus in the model above, the channel between the client and server MUST be authenticated, though additional encryption is not necessary.

An additional consideration is that a client who wishes for a server to evaluate a particular function f cannot be sure that the server actually performed the correct computation on the data. The client must trust that the server evaluates a correct circuit for the target function.

Building HIT

Prerequisites

Tools

HIT requires CMake 3.12 or later and either GCC-9 or Clang-10. We recommend using Clang, as SEAL is optimized for Clang. We recommend the ninja build system.

Libraries

We recommend installing the Google Protocol Buffers library and protoc compiler (Ubuntu: libprotobuf-dev and protobuf-compiler) and Boost's math library (Ubuntu: libboost-math-dev). If these dependencies are not found on the system, HIT's build system will download and build its own versions, which takes additional time.

Ubuntu 18.04

The HIT docker scripts include a complete script to install all the necessary dependencies in Ubuntu 18.04.

Building HIT with CMake

git clone https://github.com/awslabs/homomorphic-implementors-toolkit.git
cd homomorphic-implementors-toolkit
cmake . -Bbuild -GNinja
ninja -Cbuild

By default, only the HIT library is built. To build the examples, use cmake . -Bbuild -GNinja -DHIT_BUILD_EXAMPLES=ON; see BUILDING for more details.

Integrating HIT

HIT is easy to integrate as a dependency into a homomorphic application. We recommend using CMake's add_subdirectory command to add the HIT source directory to the build. To link against HIT, use the target aws-hit.

See INCORPORATING for more details.

Using HIT

Most of the HIT headers are provided by including "hit/hit.h".

When running code that uses HIT, you can control the output with the Google Log (GLog) library. In HIT, logging is primarily controlled by the VLOG level:

  • To see only critical security warnings and errors, define the environment variable GLOG_v=0 or use the command line argument --v=0
  • To see evaluation output, define the environment variable GLOG_v=1 or use the command line argument --v=1
  • To see verbose evaluation output, define the environment variable GLOG_v=2 or use the command line argument --v=2

See the GLog documentation for more information: https://hpc.nih.gov/development/glog.html

As an example, we will set the log level to 2 to show most output:

export GLOG_v=2
export GLOG_log_dir="/tmp/hit_log"
ninja run_hit_example

Examples

We recommend reading through the detailed examples which demonstrate how to use the features described above. For those unfamiliar with homomorphic encryption topics, we also recommend reading through the Microsoft SEAL examples.

Citing HIT

Please use the following BibTeX entry to cite HIT:

@misc{aws-hit,
    title = {Homomorphic Implementor's Toolkit},
    howpublished = {\url{https://github.com/awslabs/homomorphic-implementors-toolkit}},
    month = dec,
    year = 2020,
    note = {Amazon Web Services},
    key = {HIT}
}

Contributing Changes

CONTRIBUTING.md has details on how to contribute to this project.

homomorphic-implementors-toolkit's People

Contributors

amazon-auto avatar bryce-shang avatar crockeea avatar salusasecondus avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

homomorphic-implementors-toolkit's Issues

Benchmark logs are hard to read

The logging statements were originally intended to be displayed in the console. We move to GLog, but the log formatting is still designed for console. Benchmark outputs are particularly hard to read. In the console, we would print out the action, followed by "...", then perform the action, and then print the elapsed time on the same console line. However, when we moved to GLog, the timing now goes in a new log entry. Moreover, indentations are lost, which makes the GLog output harder to read than the console output. We should carefully look through the log messages and update them to have clear output in GLog.

Parameterize ciphertexts with an evaluator

Ciphertexts are designed to be used with a single evaluator: they are encrypted via an evaluator, which packs the right information into the CKKSCiphertext object (either a plaintxt, a ciphertext, both, or neither).

This was brought up in a security review (how can we prevent accidentally sending a plaintext to an untrusted party), and it's also a problem in ciphertext deserialization: we don't know when to expect a raw_pt or seal_ct in a serialized object. For example, if we are trying to load a ciphertext for use with the Homomorphic evaluator, but the serialized object doesn't contain a SEAL ciphertext, then that should be an error. Currently, we happily load that ciphertext, and it will result in something horrible at runtime (most likely a SEAL error).

Linear Algebra serialization

We need to add protobuf serialization for the linear algebra API.

We need serialization and deserialization for EncryptedMatrix, EncryptedRowVector, and EncryptedColVector, and probably EncodingUnit.

Check Metadata in HomomorphicEval tests

Ciphertext metadata should now be correct when using the homomorphic evaluator, but the tests don't currently check this. We should update the unit tests to validate the metadata with this evaluator.

Give options for simpler evaluation API

Currently, operations require inputs to be at specific levels, and outputs must sometimes be relinearized and or rescaled depending on the operation. Keeping track of all this is difficult, and it results in messy circuit implementations. It would be pretty easy to fix this situation for the LinearAlgebra API: we could add two boolean flags to the class constructor auto_level and auto_maintenance. The first flag would allow you to pass in CTs of arbitrary levels to all API functions, and the API would reduce the inputs to the appropriate level prior to doing the operation. The second flag would automatically apply relinearization and rescaling if needed. It's less clear how we could achieve the same features in the base evaluator class in a clean way.

It's worth keeping these as options rather than always automatically handling these two tasks: for HE levels, managing it yourself forces you to understand what's happening in the circuit. I've found several bugs by being forced to manage this myself. For maintenance operations, it's not always optimal from a performance or noise perspective to automatically apply these operations. Even though it can be a pain to track what needs to be done, it can increase performance or reduce noise to do it manually.

Document SEAL memory management

Because HIT uses SEAL, it inherits SEAL's memory management. In tests and benchmarks, SEAL seems to be acquiring large quantities of memory, but never releasing it. I've investigated this with SEAL (microsoft/SEAL#241), but didn't make progress. I tried all of the suggested techniques for the application tests, but memory usage was actually worse compared to using the default global memory manager.

In the end, I was able to get SEAL to release memory by setting seal::MemoryManager::SwitchProfile(make_unique<seal::MMProfNew>()); before running unit tests, but according to SEAL, this memory manager "should only be used in special cases". It's not clear what these are, or what problems this memory manager might cause: it did not impact the runtime of the unit tests, and it dramatically reduced memory usage when I used it.

It would be good if we understood the SEAL memory managers and how to use them so that we could add some notes in HIT.

Cohesive Evaluators

Right now, we have three different concepts: CKKSInstance, Evaluators, and LinearAlgebra. These all do different things and work in different ways. We should have a more cohesive approach to this.

A homomorphic encryption scheme has several operations:
-keygen
-encrypt
-decrypt
-homomorphic operations

Right now, we have keygen, encrypt, and decrypt functionality in CKKSInstance, and operations in Evaluators. However, LinearAlgebra uses has its own encryption and decryption API in addition to operation. Reviewing the CKKSInstance` API, it's clear that it is the problem. In particular, many functions have case statements (depending on the evaluator) or dynamic casts. We can solve all of this by killing CKKSInstance and moving its functionality into the Evaluator API. Then all evaluators have a consistent API.

The proposal:

  1. Remove all encryption and decryption from CKKSInstance, and instead put an encrypt and decrypt function in the Evaluator API, and have each concrete evaluator define their own implementation.
  2. Remove all serialization functionality from CKKSInstance and move it to the evaluator API.
  3. Remove all keygen functionality from CKKSInstance and move it to the evaluator API.
  4. Rename the evaluator API to CKKSInstance and each evaluator to DepthFinderInstance or similar.

Just a few advantages:

  • We can have special functions that only occur in certain evaluators (e.g. getPlaintext()), eliminating many sources of runtime errors.
  • All evaluators have a consistent API (keygen, encrypt, decrypt, serialize, deserialize, and operations), which are all evaluator-specific
  • Remove switch statements or dynamic casts in CKKSInstance
  • Easier to get right since there are fewer ways to generate a runtime error

Remove the ability to serialize a plaintext

We should remove repeated double raw_pt = 4; // raw (unscaled) plaintext encrypted in the ciphertext; only non-empty from the ciphertext protobuf object so that it's harder for users to do something insecure.

Any debugging that the user wants to do can be done locally (without serialization), so this doesn't seem to be necessary from a functionality perspective.

Validate Protobuf inputs

We should add validation when parsing protobuf objects to ensure valid values, e.g., non-negative depths, non-empty lists, etc.

Polish UI

Right now, I basically tailor all output for the test I'm running at the moment. There's no way to quickly disable this output, pipe it to log files/etc, or change the verbosity. You get what I want.

Xianrui suggests to provide a way to enable/disable key generation time and other currently-always-on console output. This includes the timing output in lrTrainV*.

Disable Unit Tests by Default

Currently, unit tests are built by default and automatically run when build is complete (without interaction from the user). The addition of the LinearAlgebra API results in tests taking at least one minute, and up to 10 minutes, depending on the machine. While the tests are running,
[0/1] Linking CXX executable ../../bin/Release/hit-unit-test
is displayed, so it isn't obvious that tests are being run (it just looks like the build is hanging at the linking stage).

I propose to

  • Disable BUILD_HIT_TESTING by default
  • Disable running the tests automatically, even when they are built
  • Adding a note in the README about how to build and run the tests
  • This will require updating the CI script

Add support for symmetric CKKS

SEAL supports symmetric CKKS encryption, and it can improve performance and reduce bandwidth compared to the asymmetric version we support today. We should support both options.

Get customer feedback on logging experience

Currently, the implementation of logging and the description in the README tries to get users to use a single GLOG flag to control output. We agreed to revisit this with user feedback to see if users are confused by this, or if they would prefer some other implementation (e.g., one which uses a single INFO level so that we can use GLOG's INFO/WARNING/ERROR/FATAL levels instead of VLOG) or a description which includes using two different GLOG flags to control output.

Open TODOs

example_4_linearalgebra: link to paper

Add Mixed-Unit API to LinearAlgebra API

Expand the LinearAlgebra API to include the mixed-unit API described in the paper. In certain applications, these can enable much more efficient operations.

Simplify Logging

Currently, we are using two different logging concepts: VLOG and LOG(level). These are controlled by separate logging levels, and it isn't easy for a user to know what is logged at each level. We need a cohesive strategy which hopefully uses a single log API.

Add Linear Algebra DSL

As I'm writing the paper, it's become more clear how all of these encoding functions should work. In particular, the library needs another layer of abstraction in the form of "encrypted matrix", rather than just "ciphertext". The reason is that a matrix may be encrypted as one or more ciphertexts, but linear algebra operations should know how to deal with an encrypted matrix (no matter how many ciphertexts are involved) rather than making the programmer deal with each individual ciphertext in linear algebra operations.

De-duplicate evaluation keys

With Lattigo v2.1.1, the Lattigo BootstrappingKey struct is opaque, yet it contains many of the evaluation keys needed by most circuits. The result is that we have to generate keys twice, serialize them twice, store them in memory twice, and transmit them to the server twice, all of which is very expensive. See tuneinsight/lattigo#137.

It appears this may get fixed in the next release of Lattigo, in which case I propose the following:
If parameters support bootstrapping, only generate bootstrapping keys. Add in additional rotation keys as needed, using the SEAL-branch API for accepting rotations. Add a latticpp API to extract relinearization and rotation keys from the bootstrapping keys to avoid duplicating them.

Improve ciphertext serialization

We should be able to serialize ciphertexts in two ways.

  1. As a standalone ciphertext. This means the ciphertext should include its HE parameters. The use case for this serialization method is sending a single ciphertext over the wire.
  2. As a raw ciphertext, without HE parameters. This gives an efficient serialization method for settings where we need to serialize many ciphertexts, all of which have the same parameters. For example, in the linear algebra API, we need to serialize a matrix which has a two dimensional array of ciphertexts. It's a waste to have them all store metadata, so the matrix itself should store HE parameters, along with a list of raw ciphertexts.
  3. This also means we need a standalone Proto object for HE parameters.

Thus the Proto structure is:

  • HE parameters (we have this)
  • Raw ciphertext (SEAL ciphertext + level, scale, and plaintext)
  • "Normal" ciphertext (HE parameters + raw ciphertext)

Add `save` API to ciphertexts and linear algebra objects

Currently, these objects just have a serialize API, which requires a second step of writing the protobuf object to a stream. We can unify these tasks with a save API, which makes the user experience consistent between saving instance parameters and encrypted objects.

Consider using stronger parameter identification method

Currently, HIT just uses ciphertext level to identify compatible ciphertexts. However, this isn't really enough: ciphertexts have to be with respect to the same parameters (like moduli) and keys to be compatible. SEAL captures this notion with params_id. We'd like to avoid being coupled tightly to SEAL if possible, but it might also be nice to have additional safety checks in place.

Rethink ScaleEstimator with Bootstrapping

  1. It's not clear that DebugEval needs a ScaleEstimator instance at all. Can it be removed completely?
  2. ScaleEstimator might not make sense when bootstrapping is used. In particular, we should carefully think about what it means to be at a low ciphertext level mid-circuit, since ScaleEstimator uses plaintext norm in combination with ciphertext level to determine the estimated scale.

Add alternate option for matrix/matrix multiplication

Currently, the API to compute AB takes A^T and B, and performs 3f multiplications where f is the height of A.
Another algorithm is to take A and B^T and perform 3*h multiplications, where h is the width of B. This could be more efficient depending on the exact matrix dimensions.

Example fails on Lattigo branch

Example 3 fails on the lattigo branch. The problem is apparently related to the magnitude of the plaintext, (it can be fixed by setting plaintext_inf_norm to 2), but this isn't a problem with SEAL.

Stricter Evaluation API

SEAL's evaluation API is a bit too lenient, which makes HIT's APIs equally lenient.

For example, SEAL multiplication allows inputs where one or more ciphertexts is not linear, but it's impossible to relinearize such a ciphertext (at least without using an unknown-to-me SEAL API for generating more relinearization keys).

Similarly, rescale_to_next permits ciphertexts with nominal scale, which results in a ciphtext with scale ~0, which is bad.

Our documentation explains what properties the input ciphertexts should have, but we don't actually check for it. In most cases, a bad input results in a SEAL error (which is fine), but when it doesn't, the user can get stuck in a situation they don't know how to get out of. It would be nice if HIT enforced a stricter API that prevented users from calling functions on inputs which don't throw a SEAL error but which are probably not intended.

Distinguish between internal errors and user errors

Currently all errors use invalid_argument and don't specify whether it is an internal error (i.e., bug) or user error. For an HIT user, it would be valuable to know the difference so that they know whether to report a bug or fix their code.

Make evaluators thread-safe

Only the homomorphic evaluator supports parallel evaluation. In particular, it would be nice if the debug evaluator also supported parallelism, because the tests are very slow when we have to use this evaluator in serial.

Threading issue in Lattigo branch

HomomorphicEval contains several "getters" for thread_safe_ptrs. These getters currently create a new stateful Lattigo object on the condition if (backend_encoder.get() == nullptr || !(backend_encoder->params == context->params)). There is a comment that attempts to explain this condition, but we have recently determined that the reasoning in the comment is in correct, and that we in fact do not understand the thread safety issue that this condition resolves (in practice). Therefore, we need to do additional investigation to understand what's really going on here.

In more detail: if I remove the second part of the condition (the first part is not in question), the multi-threaded unit tests (like LinearAlgebra.MatrixMatrixMul_Row_Major fail (when run with many other tests, not in isolation) because the parameters in, e.g., the Lattigo evaluator do not match the parameters in the HIT HomomorphicEval evaluator. My explanation for this was that thread_safe_ptrs are globally attached to a thread only, and independent of the object that holds the pointer, but I recently discovered that this is incorrect. Therefore, we do not understand why the unit tests can result in this situation of mismatched parameters.

fatal error: This file was generated by an older version of protoc

I have LLVM-Clang on macOS

/usr/local/Cellar/llvm/16.0.6/bin/clang++ -v                                                                         ─╯
Homebrew clang version 16.0.6
Target: x86_64-apple-darwin22.5.0
Thread model: posix
InstalledDir: /usr/local/Cellar/llvm/16.0.6/bin

CMake command works fine
cmake . -Bbuild -GNinja -DHIT_BUILD_EXAMPLES=ON -DCMAKE_CXX_COMPILER=/usr/local/Cellar/llvm/16.0.6/bin/clang++

I have protobuf installed

protoc --version                                                                                                     ─╯
libprotoc 23.3

But ninja build fails

ninja -Cbuild                                                                                                        ─╯
ninja: Entering directory `build'
[1/25] Building CXX object src/CMakeFiles/aws_hit_obj.dir/hit/api/ciphertext.cpp.o
FAILED: src/CMakeFiles/aws_hit_obj.dir/hit/api/ciphertext.cpp.o 
/usr/local/Cellar/llvm/16.0.6/bin/clang++ -DGFLAGS_IS_A_DLL=0 -DGLOG_CUSTOM_PREFIX_SUPPORT -I/Users/devharsh/Downloads/homomorphic-implementors-toolkit/build/src/../protobuf -I/Users/devharsh/Downloads/homomorphic-implementors-toolkit/build/protobuf/hit/protobuf -I/Users/devharsh/Downloads/homomorphic-implementors-toolkit/src -I/Users/devharsh/Downloads/homomorphic-implementors-toolkit/src/hit -isystem /Users/devharsh/Downloads/homomorphic-implementors-toolkit/build/third-party/include/SEAL-4.1 -isystem /usr/local/include -isystem /Users/devharsh/Downloads/homomorphic-implementors-toolkit/third-party/tbb/src/include -O3 -DNDEBUG -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk -std=c++17 -Wall -Werror -Wformat=2 -Wwrite-strings -Wvla -fvisibility=hidden -fno-common -funsigned-char -Wextra -Wunused -Wcomment -Wchar-subscripts -Wuninitialized -Wunused-result -Wfatal-errors -Wmissing-declarations -Wmissing-field-initializers -Wshadow -Wpedantic -Wno-sign-compare -MD -MT src/CMakeFiles/aws_hit_obj.dir/hit/api/ciphertext.cpp.o -MF src/CMakeFiles/aws_hit_obj.dir/hit/api/ciphertext.cpp.o.d -o src/CMakeFiles/aws_hit_obj.dir/hit/api/ciphertext.cpp.o -c /Users/devharsh/Downloads/homomorphic-implementors-toolkit/src/hit/api/ciphertext.cpp
In file included from /Users/devharsh/Downloads/homomorphic-implementors-toolkit/src/hit/api/ciphertext.cpp:4:
In file included from /Users/devharsh/Downloads/homomorphic-implementors-toolkit/src/hit/api/ciphertext.h:7:
/Users/devharsh/Downloads/homomorphic-implementors-toolkit/build/src/../protobuf/hit/protobuf/ciphertext.pb.h:17:2: fatal error: This file was generated by an older version of protoc which is
#error This file was generated by an older version of protoc which is
 ^
1 error generated.

Add API to test whether a given Galois key is present

When loading stored keys from disk, we don't know which shifts are allowed by the deserialized rotation keys. We should add an API to test whether a given rotation is supported by a set of Galois keys so that higher-level code can verify that keys loaded from disk have the necessary rotation keys.

Add TBB to HIT

Efficient linear algebra operations require parallelism, which requires TBB. This works well in HELR, but we need to treat TBB as a first-class dependency like GLog/GTest/etc.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.