Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transition from SEAL v3.5 to v3.6 #12

Closed
6 of 17 tasks
sloede opened this issue Feb 27, 2021 · 1 comment
Closed
6 of 17 tasks

Transition from SEAL v3.5 to v3.6 #12

sloede opened this issue Feb 27, 2021 · 1 comment
Labels
enhancement New feature or request

Comments

@sloede
Copy link
Member

sloede commented Feb 27, 2021

According to the SEAL v3.6.0 release notes, there were a number of changes that either introduced new features or (potentially) break the existing API. Therefore, at least all explicitly mentioned major changes should be verified manually in SEAL.jl to make sure that the Julia wrapper is up to date again.

Major API Changes

  • All C++ enum labels are consistently in lowercase. Most importantly, scheme_type::BFV and scheme_type::CKKS are changed to scheme_type::bfv and scheme_type::ckks.
  • Changed seal::SEAL_BYTE to seal::seal_byte; all uppercase names are used only for preprocessor macros.
  • Removed BatchEncoder API for encoding and decoding Plaintext objects inplace. This is because a Plaintext object with slot-data written into the coefficients is (confusingly) not valid to be used for encryption.
  • Removed IntegerEncoder and BigUInt classes. IntegerEncoder results in inefficient homomorphic evaluation and lacks sane correctness properties, so it was basically impossible to use in real applications. The BigUInt class was only used by the IntegerEncoder.
  • All Encryptor::encrypt variants have now two overloads: one that takes a Ciphertext out-parameter, and one that returns a Serializable.
  • Changed the names of the public key generation functions to clearly express that a new key is created each time, e.g., KeyGenerator::create_public_key.
  • Removed the KeyGenerator::relin_keys_local and KeyGenerator::galois_keys_local functions.
    These were poorly named and have been replaced with overloads of KeyGenerator::create_relin_keys and KeyGenerator::create_galois_keys that take an out-parameter of type RelinKeys or GaloisKeys.
  • Renamed IntArray to DynArray (dynamic array) and removed unnecessary limitations on the object type template parameter.
  • Added public API for modular reduction to the Modulus class.
  • Added API for creating DynArray and Plaintext objects from a gsl::spanstd::uint64_t (C++) or IEnumerable (C#).

Minor API Changes

  • Added std::hash implementation for EncryptionParameters (in addition to parms_id_type) so it is possible to create e.g. std::unordered_map of EncryptionParameters.
  • Added API to UniformRandomGeneratorFactory to find whether the factory uses a default seed and to retrieve that seed.
  • Added const overloads for DynArray::begin and DynArray::end.
  • Added a Shake256PRNG and Shake256PRNGFactory classes.
    Renamed BlakePRNG class to Blake2xbPRNG, and BlakePRNGFactory class to Blake2xbPRNGFactory.
  • Added a serializable UniformRandomGeneratorInfo class that represents the type of an extendable output function and a seed value.
  • Added native/src/seal/version.h defining a struct SEALVersion.
    This is used internally to route deserialization logic to correct functions depending on loaded SEALHeader version.

Other

  • Added seal::util::DWTHandler and seal::util::Arithmetic class templates that unify the implementation of FFT (used by CKKSEncoder) and NTT (used by polynomial arithmetic).
@sloede sloede added the enhancement New feature or request label Feb 27, 2021
@sloede
Copy link
Member Author

sloede commented Mar 4, 2021

I will close this with the current status. If a user is interested in one of the new features, just create an issue and we will add it here.

@sloede sloede closed this as completed Mar 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant