Feature request ⚡

Many parts of the library can be parallelized easily using Rayon and would probably increase performance tenfold.

Feature request ⚡

Allow other security levels.

Is your feature request related to a problem? 😧

Currently, a single parameter-set is returned when creating encryption parameters. There should be different security levels available.

Describe the solution you'd like 😄

A way to create a different parameter set, if only discrete sets are allowed, the following would be satisfactory:

use tfhe::{Parameters, SecurityLevel, generate_keys};
let default_parameters = Parameters::default(); // Standard security level (highest possible)
let bit128_parameters = Parameters::with(SecurityLevel::Bit128); // 128-bit security
let bit80_parameters = Parameters::with(SecurityLevel::Bit80); // A lower, 80-bit security level
let keys = generate_keys(bit80_parameters);
...

Feature request ⚡

Is your feature request related to a problem? 😧

The tests need cleanup, some tests can be merged, and performance can be improved by caching generated keys (as long as the key generation is tested properly).

Describe the solution you'd like 😄

These two tests can be merged as key generation happens twice, without any need for it. They also test the same functionality:

Feature request ⚡

Is your feature request related to a problem? 😧

Creating circuits using functions for boolean gates is difficult and manual labour. There could easily be APIs for parsing some DSL and creating circuits for you. At least some prebuilt circuits such as an 8-bit adder. Additionally, common types represented as ciphertexts could be created, such as Uint8.

Describe the solution you'd like 😄

Some sort of easier way of creating programs using the library. Some functionality to parse a binary circuit language would be helpful. A compiler for converting Rust or LLVM to circuits would be even better.

Describe alternatives 🤷‍♂️

Possible solutions could be:

• A parser for converting binary circuit formats to the encrypted form. E.g. some subset of Verilog or similar.
• A compiler for converting Rust to circuits
• A DSL for writing circuits.
• Some predefined built-in primitive types. E.g. Uint8, Int8, etc. with associated common methods / structures, e.g. 8-bit adder, encrypted comparison circuit, etc.

Feature request ⚡

Is your feature request related to a problem? 😧

As of now, the public API is a bit of a mess. Many things that should not be public are public, and all modules are public. Functions, methods, types, traits, etc. should be at the lowest visibility level unless required to be public.

Additionally, there is no good structure to the API. Encryption, decryption and key generation is in the bootstrapping-module instead of some encryption module or preferably as part of the prelude or exposed at the root-level.

Describe the solution you'd like 😄

An expected public API structure could look something like:

• tfhe - Exposes encrypt, decrypt, generate_keys
  • encryption - Contains definitions for and exposes encrypt, decrypt and generate_keys
  • bootstrapping - Exposes the bootstrap-method (currently named tfhe_bootstrap which is unnecessary`
  • gates - Exposing all homomorphic gates, which should be named xor instead of boots_xor unless there are any name conflicts. Alternatively, gates could contain all gates without bootstrapping applied, and another module called bootstrapped_gates or perhaps in bootstrapping could contain gates which are bootstrapped. To give the user flexibility to choose between bootstrapped gates and bootstrapped circuits.

That's it. It does not need to be any more than that.

Describe alternatives 🤷‍♂️

There are probably alternatives to this structure. Some say that https://github.com/dalek-cryptography/curve25519-dalek has a nice API, but I am unsure how this relates to this kind of a library which has more functionality.

The bootstrapping functionality could be done more elegant than feature flags. Currently, the bootstrapping function is exposed even when the bootstrapping-feature is disabled, which is confusing. It would at least make sense to only expose it when the feature is enabled, but a better approach would be something like the structure described in the previous section.