[ANN] SEAL.jl: Fully homomorphic encryption with the BFV and CKKS schemes

SEAL.jl is a Julia package that wraps the SEAL library for homomorphic encryption. Homomorphic encryption allows to perform numerical operations directly on encrypted data without having to decrypt the data first, process it, and then re-encrypt the result.

The package supports the Brakerski/Fan-Vercauteren (BFV) scheme for exact integer arithmetic and the Cheon-Kim-Kim-Song (CKKS, also known as HEAAN in literature) scheme for approximate arithmetic with real and complex numbers. Our goal is to expose the homomorphic encryption capabilitites of SEAL in a (mostly) intuitive and Julian way.

Currently, SEAL.jl supports all operations that are used in the examples 1 through 5 of the SEAL library. This includes

  • encoding/decoding of raw data
  • encryption/decryption
  • basic arithmetic operation: addition, multiplication
  • rotation
  • relinearization and rescaling
  • modulus switching

for both the BFV and CKKS schemes.

While most relevant functionality of the SEAL library is already supported in SEAL.jl, there are a few areas where more work is needed, and where community contributions are especially welcome:

  • Add missing API implementations
  • Add the remaining two examples 6_serialization and 7_performance
  • Document all examples
  • Complete missing docstrings

But will it work with Flux? :slight_smile:

Maybe too much to hope for, but it just would be so awesome - generic code couldn’t get much more generic than that …

https://github.com/JuliaCrypto/ToyFHE.jl/blob/master/examples/encrypted_mnist/infer.jl actually already uses Flux. Because Flux is so flexible and can basically integrate with any julia code, this soiuldn’t really be difficult for SEAL.jl.


As you can see, everything in SEAL.jl is still mighty fresh, and I haven’t tried using it with Flux yet (but as @simeonschaub pointed out, I also don’t see a reason why it wouldn’t work).

However, one of the plans for the future is to make SEAL.jl more user-friendly by hiding some of the implementation details behind a Julian interface. We would still keep the one-to-one correspondence to the SEAL C++ library intact for full flexibility, but add a convenience layer on top of it to allow writing expressions like cipher3 = cipher1 * cipher2. Furthermore, there is already an idea floating around to introduce something like a base package for fully homomorphic encryption that exposes multiple HE backends (such as ToyFHE.jl and SEAL.jl) through a common interface. Ideas, discussions & contributions welcome!


This is what makes Julia (and the community) so amazing!