yspolyakov

Hi @m271828 The goal of the new functionality is to replace the current (undocumented) cryptocontext-level `GetKeyGenLevel`/`SetKeyGenLevel` functionality (which works only for BV key switching) with the new key-level API. I...

I suggest discussing this further. The idea of adding a vector of LWE ciphertexts is reasonable but it is worth discussing how to do it first.

The difference can be summarized as follows: 1. In the case of `NATIVE_SIZE=64` and `HAVE_INT128=yes`, we use unsigned remainder in the fast basis extension. If we go from $Q$ with...

Also adding @pascoec We should change the implementation for `HAVE_INT128=yes` to use the signed remainder. There are two options: 1. Use the `HAVE_INT128=no` implementation (depending on the benchmarking) 2. Do...

`ApproxScaleAndRound` appears to have the same issue.

Hi @j2kun Based on the error, it looks like you are using a configuration where INT128 is not available. The typical configuration for the 64-bit native backend is to use...

I just looked through the code. It looks like BGV, BFV, and CKKS are hard-coding 60 bits, which is not supported when 128-bit are note available. Assigned this bug to...

I suggest changing the implementation of modular multiplication so that we could support 60-bit moduli for the case when 128-bit integers are not available.

@j2kun If possible, it is better to use the configuration when 128-bit integers are supported. This configuration is faster than the 64-bit only option (even after we fix the 57...

In CMakeLists.txt, the following code checks whether 128-bit and 64-bit integers are supported. This automatically sets `HAVE_INT128` (to TRUE in g++ and clang++ environments). ``` # Size checks include(CheckTypeSize) check_type_size("__int128"...