Git Product home page Git Product logo

openfheorg / openfhe-development Goto Github PK

View Code? Open in Web Editor NEW
612.0 14.0 160.0 9.25 MB

This is the development repository for the OpenFHE library. The current (stable) version is v1.1.4 (released on March 8, 2024).

License: BSD 2-Clause "Simplified" License

CMake 0.80% Makefile 0.01% C++ 97.83% C 1.24% Shell 0.10% Dockerfile 0.02%
cpp cryptography homomorphic-encryption homomorphic-encryption-library fully-homomorphic-encryption lattice privacy fhe secure-multiparty-computation

openfhe-development's Introduction

OpenFHE - Open-Source Fully Homomorphic Encryption Library

Fully Homomorphic Encryption (FHE) is a powerful cryptographic primitive that enables performing computations over encrypted data without having access to the secret key. OpenFHE is an open-source FHE library that includes efficient implementations of all common FHE schemes:

  • Brakerski/Fan-Vercauteren (BFV) scheme for integer arithmetic
  • Brakerski-Gentry-Vaikuntanathan (BGV) scheme for integer arithmetic
  • Cheon-Kim-Kim-Song (CKKS) scheme for real-number arithmetic (includes approximate bootstrapping)
  • Ducas-Micciancio (DM/FHEW), Chillotti-Gama-Georgieva-Izabachene (CGGI/TFHE), and Lee-Micciancio-Kim-Choi-Deryabin-Eom-Yoo (LMKCDEY) schemes for evaluating Boolean circuits and arbitrary functions over larger plaintext spaces using lookup tables

OpenFHE also includes the following multiparty extensions of FHE:

  • Threshold FHE for BGV, BFV, and CKKS schemes
  • Interactive bootstrapping for Threshold CKKS
  • Proxy Re-Encryption for BGV, BFV, and CKKS schemes

OpenFHE also supports switching between CKKS and FHEW/TFHE to evaluate non-smooth functions, e.g., comparison, using FHEW/TFHE functional bootstrapping.

OpenFHE supports any GNU C++ compiler version 9 or above and clang C++ compiler version 10 or above. To achieve the best runtime performance, we recommend following the guidelines outlined in building OpenFHE for best performance.

Links and Resources

Installation

Refer to our General Installation Information: readthedocs for more information

Or refer to the following for your specific operating system:

Code Examples

To get familiar with the main API of OpenFHE, we recommend looking at the code of the following examples:

  1. FHE for arithmetic over integers (BFV):
    1. Simple Code Example
    2. Simple Code Example with Serialization
  2. FHE for arithmetic over integers (BGV):
    1. Simple Code Example
    2. Simple Code Example with Serialization
  3. FHE for arithmetic over real numbers (CKKS):
    1. Simple Code Example
    2. Advanced Code Example
    3. Advanced Code Example for High-Precision CKKS
    4. Arbitrary Smooth Function Evaluation
    5. Simple CKKS Bootstrapping Example
    6. Advanced CKKS Bootstrapping Example
    7. Double-Precision (Iterative) Bootstrapping Example
  4. FHE for Boolean circuits and larger plaintext spaces (FHEW/TFHE):
    1. Simple Code Example with Symmetric Encryption
    2. Simple Code Example with PKE
    3. Evaluation of Multi-Input Gates
    4. Code with JSON serialization
    5. Code with Binary Serialization
    6. Large-Precision Comparison
    7. Small-Precison Arbitrary Function Evaluation
  5. Scheme Switching:
    1. Examples with Scheme Switching between CKKS and FHEW/TFHE
  6. Threshold FHE:
    1. Code Example for BGV, BFV, and CKKS
    2. Simple Interactive Bootstrapping Example
    3. Interactive Bootstrapping after Chebyshev Approximation
    4. Code Example for BFV with 5 parties

Main API

Code of Conduct

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

OpenFHE is a community-driven open source project developed by a diverse group of contributors. The OpenFHE leadership has made a strong commitment to creating an open, inclusive, and positive community. Please read our Code of Conduct for guidance on how to interact with others in a way that makes our community thrive.

Call for Contributions

We welcome all contributions including but not limited to:

  • reporting issues
  • addressing bugs big or small. We label issues to help you filter them to your skill level.
  • documentation changes
  • talks and seminars using OpenFHE

How to Cite OpenFHE

To cite OpenFHE in academic papers, please use the following BibTeX entry

@misc{OpenFHE,
      author = {Ahmad Al Badawi and Jack Bates and Flavio Bergamaschi and David Bruce Cousins and Saroja Erabelli and Nicholas Genise and Shai Halevi and Hamish Hunt and Andrey Kim and Yongwoo Lee and Zeyu Liu and Daniele Micciancio and Ian Quah and Yuriy Polyakov and Saraswathy R.V. and Kurt Rohloff and Jonathan Saylor and Dmitriy Suponitsky and Matthew Triplett and Vinod Vaikuntanathan and Vincent Zucca},
      title = {OpenFHE: Open-Source Fully Homomorphic Encryption Library},
      howpublished = {Cryptology ePrint Archive, Paper 2022/915},
      year = {2022},
      note = {\url{https://eprint.iacr.org/2022/915}},
      url = {https://eprint.iacr.org/2022/915}
}

or, alternatively (WAHC@CCS'22 version),

@inproceedings{10.1145/3560827.3563379,
      author = {Al Badawi, Ahmad and Bates, Jack and Bergamaschi, Flavio and Cousins, David Bruce and Erabelli, Saroja and Genise, Nicholas and Halevi, Shai and Hunt, Hamish and Kim, Andrey and Lee, Yongwoo and Liu, Zeyu and Micciancio, Daniele and Quah, Ian and Polyakov, Yuriy and R.V., Saraswathy and Rohloff, Kurt and Saylor, Jonathan and Suponitsky, Dmitriy and Triplett, Matthew and Vaikuntanathan, Vinod and Zucca, Vincent},
      title = {OpenFHE: Open-Source Fully Homomorphic Encryption Library},
      year = {2022},
      publisher = {Association for Computing Machinery},
      address = {New York, NY, USA},
      url = {https://doi.org/10.1145/3560827.3563379},
      doi = {10.1145/3560827.3563379},
      booktitle = {Proceedings of the 10th Workshop on Encrypted Computing \& Applied Homomorphic Cryptography},
      pages = {53-63},
      numpages = {11},
      location = {Los Angeles, CA, USA},
      series = {WAHC'22}
}

Acknowledgments

Distribution Statement "A" (Approved for Public Release, Distribution Unlimited). This work is supported in part by DARPA through HR0011-21-9-0003 and HR0011-20-9-0102. The views, opinions, and/or findings expressed are those of the author(s) and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government.

openfhe-development's People

Contributors

anbestephen avatar andreea-alexandru avatar bquast avatar caesaretos avatar davidbrucecousins avatar dsuponitskiy avatar dsuponitskiy-duality avatar enum-class avatar ericastor avatar fboemer avatar iquah1 avatar jbates-duality avatar jsaylor-dualitytech avatar kimandrik avatar mctriplett avatar pascoec avatar raindropfamily avatar reneroliveira avatar sararv22 avatar sarojaduality avatar yongwoo-lee-ccl avatar yspolyakov avatar yuriy-polyakov 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  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  avatar  avatar  avatar  avatar

openfhe-development's Issues

Improve CKKS bootstrapping precision for FLEXIBLEAUTOEXT

Currently the parameters for approximating the modular reduction using the sine wave in the 64-bit scenario are tailored for FLEXIBLEAUTO. A better precision can be achieved for FLEXIBLEAUTOEXT if a different (larger) ratio of q/m is used.

MultiHopPreTest Fails with BGV moduli estimates in FixedAuto

Some MULTIHOP_PRE_TESTs fail at times with the new moduli estimates in FixedAuto. The moduli estimates are located in bgvrns-parametergeneration.cpp. As a workaround, we currently estimate the keySwitchingNoise to use numPrimes + 1, resulting in larger moduli than necessary. This test fails when we use numPrimes.

Incorrect documentation for PKE/keyswitching

  1. Keyswitching documentation is stale for keyswitch-bv.h and keyswitch-hybrid.h. They seem to reference the documentation for the base class?

  2. Can someone confirm if the documentation of keyswitch-BV.cpp and keyswitch-hybrid.cpp and keyswitch-rns.cppare correct? They all have the same documentation discussing CKKS?


/*
  CKKS scheme implementation
 */

 /*
Description:

This code implements RNS variants of the Cheon-Kim-Kim-Song scheme.

The CKKS scheme is introduced in the following paper:
- Jung Hee Cheon, Andrey Kim, Miran Kim, and Yongsoo Song. Homomorphic
encryption for arithmetic of approximate numbers. Cryptology ePrint Archive,
Report 2016/421, 2016. https://eprint.iacr.org/2016/421.

 Our implementation builds from the designs here:
 - Marcelo Blatt, Alexander Gusev, Yuriy Polyakov, Kurt Rohloff, and Vinod
Vaikuntanathan. Optimized homomorphic encryption solution for secure genomewide
association studies. Cryptology ePrint Archive, Report 2019/223, 2019.
https://eprint.iacr.org/2019/223.
 - Andrey Kim, Antonis Papadimitriou, and Yuriy Polyakov. Approximate
homomorphic encryption with reduced approximation error. Cryptology ePrint
Archive, Report 2020/1118, 2020. https://eprint.iacr.org/2020/
1118.
 */
  1. Can I get a quick blurb about keyswitch-bv and keyswitch-hybrid? I don't know enough to comment on them or write documentation up.

eval-flooring shows incorrect result

See the example below

bin/examples/binfhe/eval-flooring
Generating the bootstrapping keys...
Completed the key generation.
Homomorphically round down the input by 2 bits.
Input: 12. Expected: 3. Evaluated = 1

Cannot Serialize Relinearization Key

When I want to serialize the EvalMultKey or EvalAutomorphismKey exactly like in "simple-real-numbers-serial.cpp" I get this error :

libc++abi: terminating with uncaught exception of type cereal::Exception: Trying to save an unregistered polymorphic type (lbcrypto::EvalKeyRelinImpl<lbcrypto::DCRTPolyImpl<bigintdyn::mubintvec<bigintdyn::ubint > > >).
Make sure your type is registered with CEREAL_REGISTER_TYPE and that the archive you are using was included (and registered with CEREAL_REGISTER_ARCHIVE) prior to calling CEREAL_REGISTER_TYPE.
If your type is already registered and you still see this error, you may need to use CEREAL_REGISTER_DYNAMIC_INIT.

Refactor "class Serializable"

  1. In Serializable: implement virtual SerializedObjectName() to return the correct type name of any object derived from Serializable and remove all other implementations of SerializedObjectName().
  2. In Serializable: implement static SerializedVersion() and remove all other implementations of SerializedVersion()
  3. Make sure that:
  • all classes having save() and load() implemented are derived from Serializable
  • the version number is checked in every load() function (as some classes miss a. or b. or both of them)

OpenFHE does not compile for NATIVE_SIZE=32

The following error is generated:

[ 12%] Building CXX object src/core/CMakeFiles/coreobj.dir/lib/lattice/trapdoor-poly-impl.cpp.o
error: use of undeclared identifier 'Mul128'
                sum[j] += Mul128(a, b);
                          ^
[ 13%] Building CXX object src/core/CMakeFiles/coreobj.dir/lib/lattice/trapdoor.cpp.o
In file included from /home/ypolyakov/git/openfhe-development/src/core/lib/lattice/hal/default/dcrtpoly-impl.cpp:36:
/home/ypolyakov/git/openfhe-development/src/core/lib/lattice/hal/default/dcrtpoly.cpp:1757:27: error: use of undeclared identifier 'Mul128'
                sum[j] += Mul128(a, b);
                          ^
1 error generated.
make[2]: *** [src/core/CMakeFiles/coreobj.dir/build.make:180: src/core/CMakeFiles/coreobj.dir/lib/lattice/hal/default/dcrtpoly.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/home/ypolyakov/git/openfhe-development/src/core/lib/lattice/hal/default/dcrtpoly.cpp:1763:39: error: use of undeclared identifier 'BarrettUint128ModUint64'
            partPl.m_vectors[j][ri] = BarrettUint128ModUint64(sum[j], pj.ConvertToInt(), precomputed.modpBarrettMu[j]);
                                      ^
/home/ypolyakov/git/openfhe-development/src/core/lib/lattice/hal/default/dcrtpoly-impl.cpp:50:16: note: in instantiation of member function 'lbcrypto::DCRTPolyImpl<bigintfxd::BigVectorFixedT<bigintfxd::BigIntegerFixedT<unsigned int, 3500> > >::FastExpandCRTBasisPloverQ' requested here
template class DCRTPolyImpl<M2Vector>;
               ^
In file included from /home/ypolyakov/git/openfhe-development/src/core/lib/lattice/hal/default/dcrtpoly-impl.cpp:36:
/home/ypolyakov/git/openfhe-development/src/core/lib/lattice/hal/default/dcrtpoly.cpp:1763:39: error: use of undeclared identifier 'BarrettUint128ModUint64'
            partPl.m_vectors[j][ri] = BarrettUint128ModUint64(sum[j], pj.ConvertToInt(), precomputed.modpBarrettMu[j]);
                                      ^
/home/ypolyakov/git/openfhe-development/src/core/lib/lattice/hal/default/dcrtpoly-impl.cpp:52:16: note: in instantiation of member function 'lbcrypto::DCRTPolyImpl<bigintdyn::mubintvec<bigintdyn::ubint<unsigned int> > >::FastExpandCRTBasisPloverQ' requested here
template class DCRTPolyImpl<M4Vector>;
               ^
3 errors generated.
make[2]: *** [src/core/CMakeFiles/coreobj.dir/build.make:167: src/core/CMakeFiles/coreobj.dir/lib/lattice/hal/default/dcrtpoly-impl.cpp.o] Error 1
[ 13%] Linking CXX static library ../../../lib/libbenchmark.a
[ 13%] Built target benchmark
make[1]: *** [CMakeFiles/Makefile2:571: src/core/CMakeFiles/coreobj.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

Key management

  • Merge evalSumKeyMap, evalAutomorphismKeyMap

  • Need a logic on which keys should be serialized/deserialized depending on which functionalities we want to support

  • Need flags on which functionalities currently are supported

  • If some keys are missing, we can use other keys to evaluate the desired rotation.

Fails to compile on macOS

Even by following the instructions for macOS, openfhe fails to compile on macOS (M2 chip). See below for the error that seems due to a deprecated member.

[ 20%] Building CXX object src/core/CMakeFiles/core_tests.dir/unittest/UnitTestSerialize.cpp.o
In file included from /Users/tancrede/git/openfhe-development/src/core/unittest/UnitTestSerialize.cpp:49:
In file included from /Users/tancrede/git/openfhe-development/src/core/include/utils/serial.h:67:
In file included from /Users/tancrede/git/openfhe-development/third-party/cereal/include/cereal/archives/json.hpp:62:
/Users/tancrede/git/openfhe-development/third-party/cereal/include/cereal/external/rapidjson/document.h:102:19: error: 'iterator<std::random_access_iterator_tag, rapidjson::GenericMember<rapidjson::UTF8<>, rapidjson::MemoryPoolAllocator<>>>' is deprecated [-Werror,-Wdeprecated-declarations]
    : public std::iterator<std::random_access_iterator_tag
                  ^
/Users/tancrede/git/openfhe-development/third-party/cereal/include/cereal/external/rapidjson/document.h:548:22: note: in instantiation of template class 'rapidjson::GenericMemberIterator<false, rapidjson::UTF8<>, rapidjson::MemoryPoolAllocator<>>' requested here
    typedef typename GenericMemberIterator<false,Encoding,Allocator>::Iterator MemberIterator;  //!< Member iterator for iterating in object.
                     ^
/Users/tancrede/git/openfhe-development/third-party/cereal/include/cereal/archives/json.hpp:440:15: note: in instantiation of template class 'rapidjson::GenericValue<rapidjson::UTF8<>>' requested here
      typedef JSONValue::ConstMemberIterator MemberIterator;
              ^
/Library/Developer/CommandLineTools/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__iterator/iterator.h:27:29: note: 'iterator<std::random_access_iterator_tag, rapidjson::GenericMember<rapidjson::UTF8<>, rapidjson::MemoryPoolAllocator<>>>' has been explicitly marked deprecated here
struct _LIBCPP_TEMPLATE_VIS _LIBCPP_DEPRECATED_IN_CXX17 iterator
                            ^
/Library/Developer/CommandLineTools/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__config:1066:39: note: expanded from macro '_LIBCPP_DEPRECATED_IN_CXX17'
#  define _LIBCPP_DEPRECATED_IN_CXX17 _LIBCPP_DEPRECATED
                                      ^
/Library/Developer/CommandLineTools/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__config:1043:48: note: expanded from macro '_LIBCPP_DEPRECATED'
#    define _LIBCPP_DEPRECATED __attribute__ ((deprecated))
                                               ^

Operations Ciphertext +/-/* Plaintext without decoding the Plaintext

In LeveledSHECKKSRNS class several operations: ciphertext +/-/* plaintext are implemented using workaround.
First we decode the plaintext and then encode again with the proper depth/level.

Instead, we can treat a plaintext as a "dummy" ciphertext, and do all operations in a same way as ciphertext * ciphertext.

P.S. we also can redefine the Plaintext to smth like PlainCiphertext. And define a Plaintext to be not depend on depth/level, and instead Plaintext will be

  • NativePoly (mod t) = InvNTT(integer message vector (mod t) ) for BGV/BFV
  • vector = InvFFTSpecial(double message vector) for CKKS

Apply bugfixes from PALISADE v1.11.7

Mismatch in multiplying DCRTPolys

When the exception in DCRTPolyImpl::Times is enabled, it gets triggered during CKKS bootstrapping. See example below. Need to fix the root cause and reenable the exception.

bin/examples/pke/ckks-bootstrap
SecretKeyDist: UNIFORM_TERNARY
p = 59
n = 4096
# slots = 2048
log2 q = 1948
log2 q*p = 2608
dim1 = [ 0 0 ]
level budget = [ 4 4 ]

Linear transform precomputation time: 1.72 s

Automorphism key generation time: 2.175 s
ciphertext number of slots: 2048

Number of levels before bootstrapping: 1
terminate called after throwing an instance of 'lbcrypto::math_error'
  what():  /home/ypolyakov/git/openfhe-development/src/core/lib/lattice/hal/default/dcrtpoly.cpp:914 tower size mismatch; cannot multiply
Aborted (core dumped)

Corrupt results on reusing a BinFHEContext

If we construct a BinFHEContext and LWEPrivateKey pair:

cc.GenerateBinFHEContext(kSecurityLevel);
sk = cc.KeyGen();
cc.BTKeyGen(sk);

then attempt to clear them both using:

cc.ClearBTKeys();
sk.reset();

and then re-generate the pair, we seem to get corrupt results for all BinFHE operations.

To reproduce: install bazelisk, unzip openfhe-bug.zip, and then run bazelisk test -c opt //:cleanup_and_run_test inside the resulting folder.

Alternatively, the actual test is a single file (cleanup_and_run_test.cc), so any build system that can handle a dependency on gtest and OpenFHE should work.

Public key generation is slower when the HYBRID key switching method is used

GetParamsPK() uses extended basis for the HYBRID mode. This is needed to support the PRE functionality. Currently this extended basis mode is used for all HYBRID scenarios, not just those involving PRE.

Once the PRE changes by @sararv22 are merged, the PRE mode data member can be used to restrict the use of the extended basis to HYBRID + PRE scenarios only.

The use of extended basis increases the KeyGen runtime and slightly increases the public key encryption for all cases when the HYBRID key switching method is used.

The changes for the implementation of GetParamsPK() need to be made rlw-cryptoparameters.h.

@kimandrik @sarojaduality

CoefPackedEncoding in BFV with q - abs(value)

In the EncodeVec function of the CoefPackedEncoding, when encoding negative values, we encode t - abs(value), where t is the plaintext modulus. Before, we used q - abs(value), where q is the ciphertext modulus because this has less noise. Why does using q fail with the noise improvement when using Q/t instead of Delta?

Optimize TimesQovert in dcrtpoly.cpp (used for BFV encryption)

The following two optimizations can be applied

  1. Currently we do extra multiplications by [-Q] mod t. We should be able to do it only for a single NativePoly rather than a full DCRTPoly. The message mod t will be the same for all RNS towers because t < q_i. However, it is complicated to implement in OpenFHE because at this point we already have a DCRTPoly, with negative values being different in different towers.
  2. We should also use an in-place operator for Times.

gcc12 complains about use-after-free

This line

seems to explicitly use a variable after freeing it. I'm not a C++ expert, but this is causing build failures in GCC 12.

Repro steps: clone this repo and follow the instructions in the Makefile

 build git:(main)  $ make
-- Copied demoData files
[  0%] Built target third-party
[  0%] Building CXX object src/core/CMakeFiles/coreobj.dir/lib/lattice/be2-poly-impl.cpp.o
[  0%] Building CXX object src/core/CMakeFiles/coreobj.dir/lib/lattice/be4-poly-impl.cpp.o
[  1%] Building CXX object src/core/CMakeFiles/coreobj.dir/lib/lattice/be6-poly-impl.cpp.o
[  1%] Building CXX object src/core/CMakeFiles/coreobj.dir/lib/lattice/benative-poly-impl.cpp.o
[  1%] Building CXX object src/core/CMakeFiles/coreobj.dir/lib/lattice/dgsampling.cpp.o
[  2%] Building CXX object src/core/CMakeFiles/coreobj.dir/lib/lattice/elemparamfactory.cpp.o
[  2%] Building CXX object src/core/CMakeFiles/coreobj.dir/lib/lattice/elemparams.cpp.o
[  2%] Building CXX object src/core/CMakeFiles/coreobj.dir/lib/lattice/field2n.cpp.o
[  3%] Building CXX object src/core/CMakeFiles/coreobj.dir/lib/lattice/hal/default/dcrtpoly-impl.cpp.o
In file included from /home/jkun/openfhe-development/src/core/include/math/discretegaussiangenerator.h:77,
                 from /home/jkun/openfhe-development/src/core/include/lattice/ilelement.h:42,
                 from /home/jkun/openfhe-development/src/core/include/lattice/hal/dcrtpoly-interface.h:52,
                 from /home/jkun/openfhe-development/src/core/include/lattice/hal/default/dcrtpoly.h:51,
                 from /home/jkun/openfhe-development/src/core/include/lattice/hal/default/lat-backend-default.h:39,
                 from /home/jkun/openfhe-development/src/core/include/lattice/lat-hal.h:42,
                 from /home/jkun/openfhe-development/src/core/lib/lattice/hal/default/dcrtpoly.cpp:39,
                 from /home/jkun/openfhe-development/src/core/lib/lattice/hal/default/dcrtpoly-impl.cpp:36:
/home/jkun/openfhe-development/src/core/include/math/distributiongenerator.h: In static member function ‘static lbcrypto::PRNG& lbcrypto::PseudoRandomNumberGenerator::GetPRNG()’:
/home/jkun/openfhe-development/src/core/include/math/distributiongenerator.h:132:26: error: pointer ‘mem’ used after ‘void free(void*)’ [-Werror=use-after-free]
  132 |                 uint32_t counter = reinterpret_cast<long long>(mem);  // NOLINT
      |                          ^~~~~~~
/home/jkun/openfhe-development/src/core/include/math/distributiongenerator.h:131:21: note: call to ‘void free(void*)’ here
  131 |                 free(mem);
      |                 ~~~~^~~~~
cc1plus: all warnings being treated as errors
make[2]: *** [src/core/CMakeFiles/coreobj.dir/build.make:188: src/core/CMakeFiles/coreobj.dir/lib/lattice/hal/default/dcrtpoly-impl.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:551: src/core/CMakeFiles/coreobj.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

advanced-real-numbers-128 demo is not working

The output:

===== HybridKeySwitchingDemo1 =============
CKKS scheme is using ring dimension 32768
Input x: (1, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7,  ... ); Estimated precision: 90 bits

Segmentation fault (core dumped)

BFV multiplication gives incorrect result for large polynomials

In the bgv-bfv-benchmarks branch, if we run the bgv-bfv-benchmarks for the Polynomial demo, there are some incorrect results for degree 48 and 64 polynomials for HPS and BEHZ. It looks like the noise level reaches 58, while the modulus is 60. Maybe there is a bug in BFV moduli selection in ParamsGen.

Dockerfile does not work [bug]

Dockerfile has an old git path, branch and tag. It worked for me this way:

  • git path = openfheorg insted of openfhe
  • branch = main insted of master
  • tag = v0.9.1 insted of master

Remove default values for input parameters in virtual functions

example: MakeCKKSPackedPlaintext() in src/pke/include/cryptocontext.h
This may become an issue as the overriders of virtual functions do not acquire the default arguments from the base class declarations, and when the virtual function call is made, the default arguments are decided based on the static type of the object.

EvalMultMany fails in BFV

The EvalMultMany function returns the incorrect answer sometimes. For example, when the multiplicative depth is 4, and we input 2^4 = 16 ciphertexts, this returns an incorrect answer for BFV modes HPS, HPSPOVERQ, and HPSPOVERQLEVELED. However, it returns the correct answer when we manually multiple 16 ciphertexts with EvalMult.

Normalize header files. Phase 1

Some headers include other files unnecessarily. Some of them are:
scheme/bgvrns/bgvrns-scheme.h
key/allkey.h

Some headers include too many header files. Example:
scheme/allscheme.h

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.