zama-ai/concrete

Concrete: TFHE Compiler that converts python programs into FHE equivalent

concrete's Issues

Are there any plans to go pure rust with rustfft?

It would appear this would be a great boost for the project. I hope it would work out as it's a simpler install and hopefully better x platform https://crates.io/crates/rustfft/6.0.1

Problem with Compiling

Hello,
I have faced a few issues while compiling the concrete in Ubuntu(20.04.2) Virtual Machine. When I tried to compile code at the getting started page of concrete, it gives an error.

eosen@eosen-VirtualBox:~/Desktop/play_with_fhe$ RUSTFLAGS="-C target-cpu=native" cargo run --release 
   Compiling concrete-core v0.1.7
error: could not compile `concrete-core`

Caused by:
  process didn't exit successfully: `rustc --crate-name concrete_core --edition=2018 /home/eosen/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-core-0.1.7/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type cdylib --crate-type rlib --emit=dep-info,link -C opt-level=3 -C embed-bitcode=no -C metadata=cff372f178cbd779 -C extra-filename=-cff372f178cbd779 --out-dir /home/eosen/Desktop/play_with_fhe/target/release/deps -L dependency=/home/eosen/Desktop/play_with_fhe/target/release/deps --extern bincode=/home/eosen/Desktop/play_with_fhe/target/release/deps/libbincode-756e772149acfbc4.rlib --extern concrete_csprng=/home/eosen/Desktop/play_with_fhe/target/release/deps/libconcrete_csprng-8969f932a00ef47b.rlib --extern fftw=/home/eosen/Desktop/play_with_fhe/target/release/deps/libfftw-0844a0d141cc7fac.rlib --extern serde=/home/eosen/Desktop/play_with_fhe/target/release/deps/libserde-b899b177a1408d04.rlib --cap-lints allow -C target-cpu=native` (signal: 4, SIGILL: illegal instruction)

If I use cargo build and cargo run, the result will be like this:

eosen@eosen-VirtualBox:~/Desktop/play_with_fhe$ cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
eosen@eosen-VirtualBox:~/Desktop/play_with_fhe$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/debug/play_with_fhe`
thread 'main' panicked at 'One of the `aes`, `rdseed`, or `sse2` instructions set was not fount. It is currently mandatory to use `concrete-csprng`.', /home/eosen/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.6/src/aesni.rs:86:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

With "RUST_BACKTRACE=1":

eosen@eosen-VirtualBox:~/Desktop/play_with_fhe$ RUST_BACKTRACE=1 cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
     Running `target/debug/play_with_fhe`
thread 'main' panicked at 'One of the `aes`, `rdseed`, or `sse2` instructions set was not fount. It is currently mandatory to use `concrete-csprng`.', /home/eosen/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.6/src/aesni.rs:86:13
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/panicking.rs:519:12
   1: concrete_csprng::aesni::RandomGenerator::new
             at /home/eosen/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.6/src/aesni.rs:86:13
   2: concrete_core::math::random::uniform_boolean::<impl concrete_core::math::random::RandomGenerable<concrete_core::math::random::uniform_boolean::UniformBoolean> for bool>::sample
             at /home/eosen/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-core-0.1.7/src/math/random/uniform_boolean.rs:12:23
   3: concrete_core::math::random::uniform_boolean::random_uniform_boolean
             at /home/eosen/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-core-0.1.7/src/math/random/uniform_boolean.rs:26:5
   4: concrete_core::math::random::uniform_boolean::random_uniform_boolean_tensor::{{closure}}
             at /home/eosen/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-core-0.1.7/src/math/random/uniform_boolean.rs:62:23
   5: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once
             at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/core/src/ops/function.rs:280:13
   6: core::option::Option<T>::map
             at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/core/src/option.rs:487:29
   7: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::next
             at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/core/src/iter/adapters/map.rs:99:9
   8: <concrete_core::math::tensor::tensor::Tensor<alloc::vec::Vec<Element>> as core::iter::traits::collect::FromIterator<Element>>::from_iter
             at /home/eosen/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-core-0.1.7/src/math/tensor/tensor.rs:1298:18
   9: core::iter::traits::iterator::Iterator::collect
             at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/core/src/iter/traits/iterator.rs:1765:9
  10: concrete_core::math::random::uniform_boolean::random_uniform_boolean_tensor
             at /home/eosen/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-core-0.1.7/src/math/random/uniform_boolean.rs:62:5
  11: concrete_core::crypto::secret::lwe::LweSecretKey<alloc::vec::Vec<bool>>::generate
             at /home/eosen/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-core-0.1.7/src/crypto/secret/lwe.rs:32:21
  12: concrete::lwe_secret_key::LWESecretKey::new
             at /home/eosen/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-0.1.7/src/lwe_secret_key.rs:29:19
  13: play_with_fhe::main
             at ./src/main.rs:6:22
  14: core::ops::function::FnOnce::call_once
             at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

But encoding() work without an issue:

cargo build
   Compiling play_with_fhe v0.1.0 (/home/eosen/Desktop/play_with_fhe)
    Finished dev [unoptimized + debuginfo] target(s) in 1.76s
eosen@eosen-VirtualBox:~/Desktop/play_with_fhe$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/play_with_fhe`
 Plaintext {
         -> nb_plaintexts = 1
         -> 0 : value = 3421366622514856448 | offset = -10 | delta = 20.07843137254902 | precision = 8
      }

 Plaintext {
         -> nb_plaintexts = 5
         -> 0 : value = 3421366622514856448 | offset = -10 | delta = 20.07843137254902 | precision = 8
         -> 1 : value = 13137900832965212160 | offset = -10 | delta = 20.07843137254902 | precision = 8
         -> ...
         -> 3 : value = 8176735483453873152 | offset = -10 | delta = 20.07843137254902 | precision = 8
         -> 4 : value = 16335096280428075008 | offset = -10 | delta = 20.07843137254902 | precision = 8
      }

m1 = -6.276, o1 = -6.276
m2 = [-6.276, 4.3, 0.12, -1.1, 7.78], o2 = [-6.276, 4.300000000000001, 0.11999999999999922, -1.0999999999999996, 7.780000000000001]

same code with RUSTFLAGS="-C target-cpu=native" cargo run --release:

eosen@eosen-VirtualBox:~/Desktop/play_with_fhe$ RUSTFLAGS="-C target-cpu=native" cargo run --release 
   Compiling concrete-core v0.1.7
error: could not compile `concrete-core`

Caused by:
  process didn't exit successfully: `rustc --crate-name concrete_core --edition=2018 /home/eosen/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-core-0.1.7/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type cdylib --crate-type rlib --emit=dep-info,link -C opt-level=3 -C embed-bitcode=no -C metadata=cff372f178cbd779 -C extra-filename=-cff372f178cbd779 --out-dir /home/eosen/Desktop/play_with_fhe/target/release/deps -L dependency=/home/eosen/Desktop/play_with_fhe/target/release/deps --extern bincode=/home/eosen/Desktop/play_with_fhe/target/release/deps/libbincode-756e772149acfbc4.rlib --extern concrete_csprng=/home/eosen/Desktop/play_with_fhe/target/release/deps/libconcrete_csprng-8969f932a00ef47b.rlib --extern fftw=/home/eosen/Desktop/play_with_fhe/target/release/deps/libfftw-0844a0d141cc7fac.rlib --extern serde=/home/eosen/Desktop/play_with_fhe/target/release/deps/libserde-b899b177a1408d04.rlib --cap-lints allow -C target-cpu=native` (signal: 4, SIGILL: illegal instruction)

cargo.toml file:

[package]
name = "play_with_fhe"
version = "0.1.0"
authors = ["eosen"]
edition = "2018"


[dependencies]
concrete = "0.1.0"
itertools = "0.9.0"

In concrete 0.2.0 version , generate_keys() function takes a lot of time.

Describe the bug
In concrete 0.2.0 version , generate_keys() function takes a lot of time. In Debian OS, it look 2 hour 46 minutes.
In macOS, it took more 2 hours. This makes the practical use of the library infeasible for me. Please let me know a way to resolve this problem.

To Reproduce
Steps to reproduce the behaviour

1. Run any sample code for concrete 0.2.0.

Expected behaviour
The code should run fast.

Evidence
If applicable, add material to help explain your problem (e.g. screenshots, logs, artifacts, etc.).

Configuration(please complete the following information):

• OS: [e.g. Ubuntu 20.04]
• Debian

Additional context
Add any other context about the problem here.

Bootstrap key does need to be mutable in bootstrap function

In the bootstrap function, we have a bound that requires the bootstrap key to be mutable. In practice, it does not need to be the case:

concrete/concrete-core/src/crypto/cross/mod.rs

Line 403 in 409efcb

BootstrapKey<BskCont>: AsMutTensor<Element = Complex64>,

Concrete not running in Debian(64-bit) OS

Describe the bug
/usr/bin/ld: i386 architecture of input file `/home/varagarwal/Desktop/Try_bool/proj/target/debug/deps/libconcrete_fftw_sys-109bfa96b6241ce2.rlib(ct.o)' is incompatible with i386:x86-64 output

To Reproduce
Steps to reproduce the behaviour

1. Use Debian (64-bit) Operating system.
2. Make a rust project using "cargo new <project_name>"
3. In Cargo.toml file, add concrete-boolean = "0.1.0" under dependencies.
4. Write some code in main.rs
5. Do "cargo build"
6. The error(under describe the bug) is displayed after some crates are downloaded

Expected behaviour
All the crates should have been successfully downloaded and the function in main.rs should have run. Instead, I got this error.

Configuration(please complete the following information):

• OS: Debian (64-bit)

0.1.11 update breaks M1 compatibility

Describe the bug
Compiling an application that imports Concrete as a dependency fails on Apple M1 with the latest update of Concrete 0.1.11. Rolling back to the previous version works fine.

All steps described in #65 have been followed, including a fresh reinstall of Rust, FFTW and Brew after updating Concrete

To Reproduce
Steps to reproduce the behaviour

1. update cargo.toml to concrete version 0.1.11
2. run cargo run --release --target x86_64-apple-darwin

Expected behaviour
Concrete compiles and runs correctly on Apple M1 machines

Configuration:

• MacOS BigSur 11.6
• Macbook Pro 2020 with Apple Silicon M1 and 16g RAM

Evidence
This is the console output:

error: failed to run custom build command for concrete-fftw-sys v0.1.2

Caused by:
process didn't exit successfully: /Users/randhindi/code/fhealth-ml/target/release/build/concrete-fftw-sys-058acdd3bd100c13/build-script-build (exit status: 101)
--- stdout
Running: "/Users/randhindi/code/fhealth-ml/target/x86_64-apple-darwin/release/build/concrete-fftw-sys-de375ee38e09f5ed/out/src/configure" "--with-pic" "--enable-static" "--enable-avx" "--enable-avx2" "--enable-sse2" "--enable-generic-simd128" "--enable-generic-simd256" "--disable-doc" "--prefix=/Users/randhindi/code/fhealth-ml/target/x86_64-apple-darwin/release/build/concrete-fftw-sys-de375ee38e09f5ed/out"
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... arm-apple-darwin20.6.0
checking host system type... arm-apple-darwin20.6.0
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for C compiler vendor... clang
checking for gcc option to accept ISO C99... none needed
checking for gcc option to accept ISO Standard C... (cached) none needed
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /Library/Developer/CommandLineTools/usr/bin/ld
checking if the linker (/Library/Developer/CommandLineTools/usr/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 786432
checking how to convert arm-apple-darwin20.6.0 file names to arm-apple-darwin20.6.0 format... func_convert_file_noop
checking how to convert arm-apple-darwin20.6.0 file names to toolchain format... func_convert_file_noop
checking for /Library/Developer/CommandLineTools/usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... dlltool
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @file support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... yes
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/Library/Developer/CommandLineTools/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin20.6.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for ranlib... (cached) ranlib
checking for ocamlbuild... no
checking whether C compiler accepts -mtune=native... yes
checking whether C compiler accepts -fstrict-aliasing... yes
checking whether C compiler accepts -O3 -fomit-frame-pointer -mtune=native -fstrict-aliasing... yes
checking whether C compiler accepts -mavx... yes
checking whether C compiler accepts -mavx2... yes
checking whether C compiler accepts -mfma... yes
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking fenv.h usability... yes
checking fenv.h presence... yes
checking for fenv.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking malloc.h usability... no
checking malloc.h presence... no
checking for malloc.h... no
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking altivec.h usability... no
checking altivec.h presence... no
checking for altivec.h... no
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking for uint32_t... yes
checking for uint64_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for long double... yes
checking for hrtime_t... no
checking size of int... 4
checking size of unsigned int... 4
checking size of long... 8
checking size of unsigned long... 8
checking size of long long... 8
checking size of unsigned long long... 8
checking size of size_t... 8
checking size of ptrdiff_t... 8
checking for ptrdiff_t... yes
checking for uintptr_t... yes
checking size of float... 4
checking size of double... 8
checking size of fftw_r2r_kind... 4
checking for working alloca.h... yes
checking for alloca... yes
checking for working strtod... yes
checking for vprintf... yes
checking for _doprnt... no
checking for sin in -lm... yes
checking for BSDgettimeofday... no
checking for gettimeofday... yes
checking for gethrtime... no
checking for read_real_time... no
checking for time_base_to_time... no
checking for drand48... yes
checking for sqrt... yes
checking for memset... yes
checking for posix_memalign... yes
checking for memalign... no
checking for _mm_malloc... no
checking for _mm_free... no
checking for clock_gettime... yes
checking for mach_absolute_time... yes
checking for sysctl... yes
checking for abort... yes
checking for sinl... yes
checking for cosl... yes
checking for snprintf... yes
checking for memmove... yes
checking for strchr... yes
checking for getpagesize... yes
checking whether sinl is declared... yes
checking whether cosl is declared... yes
checking whether sinq is declared... no
checking whether cosq is declared... no
checking whether memalign is declared... no
checking whether drand48 is declared... yes
checking whether srand48 is declared... yes
checking whether posix_memalign is declared... yes
checking for _rtc intrinsic... no
checking for isnan... yes
checking whether C compiler accepts -mpreferred-stack-boundary=4... no
checking for g77... no
checking for xlf... no
checking for f77... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for xlf90... no
checking for f90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... gfortran
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether gfortran accepts -g... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for gfortran option to produce PIC... -fno-common
checking if gfortran PIC flag -fno-common works... yes
checking if gfortran static flag -static works... no
checking if gfortran supports -c -o file.o... yes
checking if gfortran supports -c -o file.o... (cached) yes
checking whether the gfortran linker (/Library/Developer/CommandLineTools/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin20.6.0 dyld
checking how to hardcode library paths into programs... immediate
checking how to get verbose linking output from gfortran... -v
checking for Fortran 77 libraries of gfortran... -L/opt/homebrew/Cellar/gcc/11.2.0/lib/gcc/11/gcc/aarch64-apple-darwin20/11.1.0 -L/opt/homebrew/Cellar/gcc/11.2.0/lib/gcc/11/gcc/aarch64-apple-darwin20/11.1.0/../../.. -lgfortran -lm
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... lower case, underscore, no extra underscore
checking whether a cycle counter is available... no

---

WARNING: No cycle counter found. FFTW will use ESTIMATE mode
for all plans. See the manual for more information.

---

checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating support/Makefile
config.status: creating genfft/Makefile
config.status: creating kernel/Makefile
config.status: creating simd-support/Makefile
config.status: creating dft/Makefile
config.status: creating dft/scalar/Makefile
config.status: creating dft/scalar/codelets/Makefile
config.status: creating dft/simd/Makefile
config.status: creating dft/simd/common/Makefile
config.status: creating dft/simd/sse2/Makefile
config.status: creating dft/simd/avx/Makefile
config.status: creating dft/simd/avx-128-fma/Makefile
config.status: creating dft/simd/avx2/Makefile
config.status: creating dft/simd/avx2-128/Makefile
config.status: creating dft/simd/avx512/Makefile
config.status: creating dft/simd/kcvi/Makefile
config.status: creating dft/simd/altivec/Makefile
config.status: creating dft/simd/vsx/Makefile
config.status: creating dft/simd/neon/Makefile
config.status: creating dft/simd/generic-simd128/Makefile
config.status: creating dft/simd/generic-simd256/Makefile
config.status: creating rdft/Makefile
config.status: creating rdft/scalar/Makefile
config.status: creating rdft/scalar/r2cf/Makefile
config.status: creating rdft/scalar/r2cb/Makefile
config.status: creating rdft/scalar/r2r/Makefile
config.status: creating rdft/simd/Makefile
config.status: creating rdft/simd/common/Makefile
config.status: creating rdft/simd/sse2/Makefile
config.status: creating rdft/simd/avx/Makefile
config.status: creating rdft/simd/avx-128-fma/Makefile
config.status: creating rdft/simd/avx2/Makefile
config.status: creating rdft/simd/avx2-128/Makefile
config.status: creating rdft/simd/avx512/Makefile
config.status: creating rdft/simd/kcvi/Makefile
config.status: creating rdft/simd/altivec/Makefile
config.status: creating rdft/simd/vsx/Makefile
config.status: creating rdft/simd/neon/Makefile
config.status: creating rdft/simd/generic-simd128/Makefile
config.status: creating rdft/simd/generic-simd256/Makefile
config.status: creating reodft/Makefile
config.status: creating threads/Makefile
config.status: creating api/Makefile
config.status: creating mpi/Makefile
config.status: creating libbench2/Makefile
config.status: creating tests/Makefile
config.status: creating doc/Makefile
config.status: creating doc/FAQ/Makefile
config.status: creating tools/Makefile
config.status: creating tools/fftw_wisdom.1
config.status: creating tools/fftw-wisdom-to-conf
config.status: creating m4/Makefile
config.status: creating fftw.pc
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands
Running: "make" "-j8"
/Library/Developer/CommandLineTools/usr/bin/make all-recursive
Making all in support
make[2]: Nothing to be done for all'. Making all in kernel make[2]: Nothing to be done for all'.
Making all in simd-support
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I .. -O3 -fomit-frame-pointer -mtune=native -fstrict-aliasing -MT sse2.lo -MD -MP -MF .deps/sse2.Tpo -c -o sse2.lo sse2.c
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I .. -O3 -fomit-frame-pointer -mtune=native -fstrict-aliasing -MT avx.lo -MD -MP -MF .deps/avx.Tpo -c -o avx.lo avx.c
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I .. -O3 -fomit-frame-pointer -mtune=native -fstrict-aliasing -MT avx2.lo -MD -MP -MF .deps/avx2.Tpo -c -o avx2.lo avx2.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I .. -O3 -fomit-frame-pointer -mtune=native -fstrict-aliasing -MT avx.lo -MD -MP -MF .deps/avx.Tpo -c avx.c -fno-common -DPIC -o avx.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I .. -O3 -fomit-frame-pointer -mtune=native -fstrict-aliasing -MT sse2.lo -MD -MP -MF .deps/sse2.Tpo -c sse2.c -fno-common -DPIC -o sse2.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I .. -O3 -fomit-frame-pointer -mtune=native -fstrict-aliasing -MT avx2.lo -MD -MP -MF .deps/avx2.Tpo -c avx2.c -fno-common -DPIC -o avx2.o

--- stderr
In file included from avx2.c:29:
./x86-cpuid.h:61:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) /* output /
^
./x86-cpuid.h:52:15: note: use constraint modifier "w"
"popl %0\n\t"
^~
%w0
./x86-cpuid.h:61:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:53:15: note: use constraint modifier "w"
"movl %0,%1\n\t"
^~
%w0
./x86-cpuid.h:61:28: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:53:18: note: use constraint modifier "w"
"movl %0,%1\n\t"
^~
%w1
./x86-cpuid.h:61:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:54:24: note: use constraint modifier "w"
"xorl $0x40000,%0\n\t"
^~
%w0
./x86-cpuid.h:61:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:55:16: note: use constraint modifier "w"
"pushl %0\n\t"
^~
%w0
./x86-cpuid.h:61:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:58:15: note: use constraint modifier "w"
"popl %0\n\t"
^~
%w0
./x86-cpuid.h:61:28: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:59:16: note: use constraint modifier "w"
"pushl %1\n\t"
^~
%w1
./x86-cpuid.h:99:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:90:14: note: use constraint modifier "w"
"pop %0\n\t"
^~
%w0
./x86-cpuid.h:99:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:91:15: note: use constraint modifier "w"
"movl %0,%1\n\t"
^~
%w0
./x86-cpuid.h:99:28: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:91:18: note: use constraint modifier "w"
"movl %0,%1\n\t"
^~
%w1
./x86-cpuid.h:99:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:92:25: note: use constraint modifier "w"
"xorl $0x200000,%0\n\t"
^~
%w0
./x86-cpuid.h:99:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:93:16: note: use constraint modifier "w"
"pushl %0\n\t"
^~
%w0
./x86-cpuid.h:99:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:96:15: note: use constraint modifier "w"
"popl %0\n\t"
^~
%w0
./x86-cpuid.h:99:28: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output */
^
./x86-cpuid.h:97:16: note: use constraint modifier "w"
"pushl %1\n\t"
^~
%w1
./x86-cpuid.h:136:16: error: invalid output constraint '+a' in asm
: "+a" (*eax), "+r" (*ebx), "+c" (*ecx), "+d" (edx));
^
./x86-cpuid.h:161:9: error: invalid output constraint '=a' in asm
: "=a" (eax), "=c" (ecx), "=d" (edx)
^
./x86-cpuid.h:183:9: error: invalid output constraint '=a' in asm
: "=a" (eax), "=c" (ecx), "=d" (edx)
^
./x86-cpuid.h:208:42: error: invalid output constraint '=a' in asm
asm (".byte 0x0f, 0x01, 0xd0" : "=a"(eax), "=d"(edx) : "c" (op));
^
In file included from avx.c:29:
./x86-cpuid.h:61:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:52:15: note: use constraint modifier "w"
"popl %0\n\t"
^~
%w0
./x86-cpuid.h:61:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:53:15: note: use constraint modifier "w"
"movl %0,%1\n\t"
^~
%w0
./x86-cpuid.h:61:28: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:53:18: note: use constraint modifier "w"
"movl %0,%1\n\t"
^~
%w1
./x86-cpuid.h:61:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:54:24: note: use constraint modifier "w"
"xorl $0x40000,%0\n\t"
^~
%w0
./x86-cpuid.h:61:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /14 warnings and 4 error
s generated.
^
./x86-cpuid.h:55:16: note: use constraint modifier "w"
"pushl %0\n\t"
^~
%w0
./x86-cpuid.h:61:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:58:15: note: use constraint modifier "w"
"popl %0\n\t"
^~
%w0
./x86-cpuid.h:61:28: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:59:16: note: use constraint modifier "w"
"pushl %1\n\t"
^~
%w1
./x86-cpuid.h:99:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:90:14: note: use constraint modifier "w"
"pop %0\n\t"
^~
%w0
./x86-cpuid.h:99:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:91:15: note: use constraint modifier "w"
"movl %0,%1\n\t"
^~
%w0
./x86-cpuid.h:99:28: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:91:18: note: use constraint modifier "w"
"movl %0,%1\n\t"
^~
%w1
./x86-cpuid.h:99In file included from sse2.c:43:
./x86-cpuid.h:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]:
61 : "=r" (result), "=r" (tst) / output /
^
:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
./x86-cpuid.h:92:25: note: use constraint modifier "w"
"xorl $0x200000,%0\n\t"
^~
%w0
./x86-cpuid.h:99:13: warning: : "=r" (result), "=r" (tst) / output /
^
value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:52:15: note: use constraint modifier "w"
"popl %0\n\t"
^~
%w0
./x86-cpuid.h:./x86-cpuid.h93::6116::13 :note : use constraint modifier "w"
warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
"pushl %0\n\t"
^~
%w0
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:99:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output */
^
./x86-cpuid.h:53:15: note: use constraint modifier "w"
./x86-cpuid.h:96:15: note: "movl %0,%1\n\t"
^~
%w0
use constraint modifier "w"
./x86-cpuid.h:61 "popl %0\n\t":28: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]

            ^~
            %w0

./x86-cpuid.h:99:28: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths] : "=r" (result), "=r" (tst) /* output */

                         ^
  : "=r" (result), "=r" (tst) /* output */
                         ^

./x86-cpuid.h:97:16: note: use constraint modifier "w"
"pushl %1\n\t"
^~
%w1
./x86-cpuid.h:53:18: note: use constraint modifier "w"
"movl %0,%1\n\t"
^~
%w1
./x86-cpuid.h:61:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) /* output */
^
./x86-cpuid.h:136:16: error: invalid output constraint '+a' in asm
./x86-cpuid.h:54:24 : "+a" (*eax), "+r" (*ebx), "+c" (*ecx), "+d" (edx));:
^note
: use constraint modifier "w"
"xorl $0x40000,%0\n\t"
^~
%w0
./x86-cpuid.h:61:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
./x86-cpuid.h:161:9: : "=r" (result), "=r" (tst) / output */
^error: invalid output constraint '=a' in asm

           : "=a" (eax), "=c" (ecx), "=d" (edx)./x86-cpuid.h

: ^55:16:
note: use constraint modifier "w"
"pushl %0\n\t"
^~
%w0
./x86-cpuid.h:61:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) /* output /
^
./x86-cpuid.h:58:15: note: use constraint modifier "w"
"popl %0\n\t"
^~
%w0
./x86-cpuid.h./x86-cpuid.h:61:28::183 :warning9: :value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
error: invalid output constraint '=a' in asm
: "=r" (result), "=r" (tst) / output */ : "=a" (eax), "=c" (ecx), "=d" (edx)

                         ^               ^

./x86-cpuid.h:59:16: note: use constraint modifier "w"
./x86-cpuid.h:208:42: "pushl %1\n\t"
^~
%w1
error: invalid output constraint '=a' in asm
asm (".byte 0x0f, 0x01, 0xd0" : "=a"(eax), "=d"(edx) : "c" (op));
^
./x86-cpuid.h:99:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) /* output /
^
./x86-cpuid.h:90:14: note: use constraint modifier "w"
"pop %0\n\t"
^~
%w0
./x86-cpuid.h:99:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:91:15: note: use constraint modifier "w"
"movl %0,%1\n\t"
^~
%w0
./x86-cpuid.h:99:28: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:91:18: note: use constraint modifier "w"
"movl %0,%1\n\t"
^~
%w1
./x86-cpuid.h:99:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:92:25: note: use constraint modifier "w"
"xorl $0x200000,%0\n\t"
^~
%w0
./x86-cpuid.h:99:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:93:16: note: use constraint modifier "w"
"pushl %0\n\t"
^~
%w0
./x86-cpuid.h:99:13: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output /
^
./x86-cpuid.h:96:15: note: use constraint modifier "w"
"popl %0\n\t"
^~
%w0
./x86-cpuid.h:99:28: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
: "=r" (result), "=r" (tst) / output */
^
./x86-cpuid.h:97:16: note: use constraint modifier "w"
"pushl %1\n\t"
^~
%w1
./x86-cpuid.h:136:16: error: invalid output constraint '+a' in asm
: "+a" (*eax), "+r" (*ebx), "+c" (*ecx), "+d" (*edx));
^
./x86-cpuid.h:161:9: error: invalid output constraint '=a' in asm
14 : "=a" (eax), "=c" (ecx), "=d" (edx) warning
s ^ and
4 errors generated.
./x86-cpuid.h:183:9: error: invalid output constraint '=a' in asm
: "=a" (eax), "=c" (ecx), "=d" (edx)
^
./x86-cpuid.h:208:42: error: invalid output constraint '=a' in asm
asm (".byte 0x0f, 0x01, 0xd0" : "=a"(eax), "=d"(edx) : "c" (op));
^
14 warnings and 4 errors generated.
make[2]: *** [avx2.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [avx.lo] Error 1
make[2]: *** [sse2.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
thread 'main' panicked at '"make" "-j8" failed: exit status: 2', /Users/randhindi/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-fftw-sys-0.1.2/build.rs:11:17
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

BSK save and load function lead to unexpected behavior

When using the save and load functions for storing the bootstraping key (as can be seen in this example https://concrete.zama.ai/advanced-operations/bootstrapping-a-ciphertext#generating-a-bootstrapping-key), the results of the bootstrapping are indeterministic and do not cohere with the expected values.
This is not the case if I directly use a freshly generated bootstrapping key, then the results are deterministic and as expected.
I therefore assume that there might be a bug in either the save or load function.

My Code, which is an adaptation to lower precision and with rounding, of the example in the documentation(https://concrete.zama.ai/advanced-operations/bootstrapping-a-ciphertext#bootstrapping-a-ciphertext):

// encoders
let encoder_input = Encoder::new_rounding_context(0., 10., 2, 1)?;
let encoder_output = Encoder::new_rounding_context(0., 10., 2, 0)?;

// secret keys
let sk_rlwe = RLWESecretKey::new(&RLWE128_1024_1);
let sk_in = LWESecretKey::new(&LWE128_630);
let sk_out = sk_rlwe.to_lwe_secret_key();

// bootstrapping key
//let bsk = LWEBSK::new(&sk_in, &sk_rlwe, 5, 3);
//bsk.save("src/keys/RLWE128_1024_1_LWE128_630_5_3.json");
let bsk = LWEBSK::load("src/keys/RLWE128_1024_1_LWE128_630_5_3.json"); 

// messages
let message: f64 = 5.;

// encode and encrypt
let c1 = LWE::encode_encrypt(&sk_in, message, &encoder_input)?;

// bootstrap
let c2 = c1.bootstrap(&bsk)?;

// decrypt
let output = c2.decrypt_decode(&sk_out)?;

println!("before bootstrap: {}, after bootstrap: {}", message, output);

Ok(())

I am using the rounding context with 2 precision bits, which gives us the encoding points 0, 3.33.., 6.66.. and 10.
Therefore during encryption 5 gets mapped to the encoding point 3.33.. and then bootstrapped with no function which should return 3.33.. as well.
The output of the above code does however produce any random encoding point.

The Output after running 4 times:
before bootstrap: 5, after bootstrap: 6.666666666666667
before bootstrap: 5, after bootstrap: 10
before bootstrap: 5, after bootstrap: 0
before bootstrap: 5, after bootstrap: 3.3333333333333335

The Output when using the key directly after generating it, i.e. uncommenting generation and commenting save and loading:
before bootstrap: 5, after bootstrap: 3.3333333333333335
before bootstrap: 5, after bootstrap: 3.3333333333333335
before bootstrap: 5, after bootstrap: 3.3333333333333335

This is the result I expect when calculating the rounding formulas by hand.

How to run Concrete-core is not clear from the ZAMA documentation.

I built a rust project using cargo new play_with_TFHE.
Then, I added the dependency concrete-core = "0.1.10" in Cargo.toml file.

After that, I want to run the example code given in the concrete-core documentation. But where should I copy paste that code in order to run it? The main.rs file inside the src folder in rust needs a main(){} function without which the rust won't compile. However, the sample code given for concrete-core does not have any main function.

Missing serialization for CRT client key

Unlike CRTVecServerKey, the struct CRTVecClientKey does not derive serialization, cf. line 16 and lines 233-234. I believe that it should be sufficient to #derive serialization to make it work.

Build fail after beta 0.2.0

Describe the bug
Build fail after beta 0.2.0

To Reproduce
Steps to reproduce the behaviour

1. first step
2. second step
3. etc

Expected behaviour
A clear and concise description of what you expected to happen.

Evidence
If applicable, add material to help explain your problem (e.g. screenshots, logs, artifacts, etc.).

Configuration(please complete the following information):

• OS: MacOS BigSur

Additional context

Control flow / branching

I've also opened this here: https://community.zama.ai/t/control-flow-branching/341, hopefully it's okay to open an issue as well. I'd prefer discussion in the issue if I had to choose.

Basically, will control flow / branching ever be possible with TFHE? I thought FHE meant we would be able to perform any arbitrary computation on encrypted data, but I don't understand how that's possible without being able to evaluate conditions and then make decisions based on that encrypted evaluation.

What am I missing? Or will the concrete libraries some day be able to perform control flow?

I've also heard there's a blockchain library being worked on, how would something like an ERC20 be possible without control flow checks to ensure tokens aren't misspent?

guide_part3 extract example failing?

Hello team,
Thank you for the great work for this library.
I was learning this with provided example code under guide directory.

at guide_part3, example of extracting lwe from vec_rlwe

let lwe_ct = rlwe_ct.extract_1_lwe(2, 0);

this is failing with following error.

thread 'main' panicked at 'Uneven chunks size',

Anything I am misusing this?

thanks in advance.

Unexpected result from bootstrap following add_with_new_min

Using the LWE method add_with_new_min with a new minimum value that is different from the minimum of the input LWEs seems to taint the internal state of the resulting ciphertext. It decrypts correctly, but a subsequent bootstrap leads to wrong results.

The following program is a minimal example exhibiting this behaviour:

use concrete::*;

const LWE_DIMENSION: usize = 592;
const LWE_NOISE: i32 = -23;
const RLWE_SIZE: usize = 2048;
const RLWE_NOISE: i32 = -82;
const BASE_LOG: usize = 6;
const LEVEL: usize = 4;

fn main() {
    // key generation
    let rlwe_params = RLWEParams {dimension: 1, polynomial_size: RLWE_SIZE, log2_std_dev: RLWE_NOISE};
    let lwe_params = LWEParams {dimension: LWE_DIMENSION, log2_std_dev: LWE_NOISE};
    
    let sk_rlwe = RLWESecretKey::new(&rlwe_params);
    let sk_in = LWESecretKey::new(&lwe_params);
    let sk_out = sk_rlwe.to_lwe_secret_key();
    let bsk = LWEBSK::new(&sk_in, &sk_rlwe, BASE_LOG, LEVEL);
    
    // encrypt and add
    let encoder_in = Encoder::new(0., 10., 6, 3).unwrap();
    let a = LWE::encode_encrypt(&sk_in, 3.0, &encoder_in).unwrap();
    let b = LWE::encode_encrypt(&sk_in, 2.0, &encoder_in).unwrap();
    
    let padding_in = a.add_with_padding(&b).unwrap();
    let old_min_in = a.add_with_new_min(&b, 0.).unwrap();
    let new_min_in = a.add_with_new_min(&b, 1.).unwrap();
    
    println!("Before bootstrap:");
    println!("  Add with padding = {}, expected {}", 
        padding_in.decrypt_decode(&sk_in).unwrap(), 5.);
    println!("  Add with old min = {}, expected {}", 
        old_min_in.decrypt_decode(&sk_in).unwrap(), 5.);
    println!("  Add with new min = {}, expected {}", 
        new_min_in.decrypt_decode(&sk_in).unwrap(), 5.);
    
    // bootstrap
    let padding_out = padding_in.bootstrap(&bsk).unwrap();
    let old_min_out = old_min_in.bootstrap(&bsk).unwrap();
    let new_min_out = new_min_in.bootstrap(&bsk).unwrap();
    println!("After bootstrap:");
    println!("  Add with padding = {}, expected {}", 
        padding_out.decrypt_decode(&sk_out).unwrap(), 5.);
    println!("  Add with old min = {}, expected {}", 
        old_min_out.decrypt_decode(&sk_out).unwrap(), 5.);
    println!("  Add with new min = {}, expected {}", 
        new_min_out.decrypt_decode(&sk_out).unwrap(), 5.);
}

Compiling and running this in release mode leads to the following output for me:

Configuration:

• OS: Ubuntu 20.04.3 LTS 64-bit running on a Windows Hyper-V VM
• Library version: concrete 0.1.11, itertools 0.10.1

Huge bootstrapping key size

    // secret keys
    let sk_rlwe = RLWESecretKey::new(&RLWE128_1024_1);
    let sk_in = LWESecretKey::new(&LWE128_630);
    let sk_out = sk_rlwe.to_lwe_secret_key();

    // bootstrapping key
    let bsk = LWEBSK::new(&sk_in, &sk_rlwe, 5, 3);

    bsk.save("bootstrapping key");

I try above code to create bootstrapping key. The size is 119 MB (70 MB after compressed).

I understand that we have the cost if we are using FHE. But this huge size is a barrier to use concrete in a production service. It's unrealistic to provide a neural network inference as HTTP service if a single request cost 119 MB network traffic.

Is there any choice to reduce the bootstrapping key?

The Example code in the document does not compile

Describe the bug
I am a beginner of Rut and TFHE. I am learning with the document of concrete.
But I found some codes in the document does not compile in Rust. There seems to be some API changes or Grammar problems.
I tried the code at the bottom of this page: https://docs.zama.ai/concrete/lib/encrypting-and-decrypting/encoding-and-decoding.html

The code

use concrete::*;
fn main() {
    println!("Hello Concrete!");
}

works fine.

To Reproduce
Steps to reproduce the behaviour:

1. edit Cargo.toml to add concrete 0.1.0 into dependency.
2. copy the code at the bottom of https://docs.zama.ai/concrete/lib/encrypting-and-decrypting/encoding-and-decoding.html into main.rs
3. run cargo run

Expected behaviour
It should compile and print the cyphertext and decrypted value.

Evidence
I got the following error message.

error[E0277]: the `?` operator can only be used in a function that returns `Result` or `Option` (or another type that implements `FromResidual`)
  --> src/main.rs:9:61
   |
3  | / fn main() {
4  | |     println!("Hello Concrete!");
5  | |     let min = -10.;
6  | |     let max = 10.;
...  |
9  | |     let encoder = Encoder::new(min, max, precision, padding)?;
   | |                                                             ^ cannot use the `?` operator in a function that returns `()`
...  |
26 | |     Ok(());
27 | | }
   | |_- this function should return `Result` or `Option` to accept `?`
   |
   = help: the trait `FromResidual<Result<Infallible, CryptoAPIError>>` is not implemented for `()`

error[E0277]: the `?` operator can only be used in a function that returns `Result` or `Option` (or another type that implements `FromResidual`)
  --> src/main.rs:13:55
   |
3  | / fn main() {
4  | |     println!("Hello Concrete!");
5  | |     let min = -10.;
6  | |     let max = 10.;
...  |
13 | |     let p1: Plaintext = encoder.encode_single(message)?;
   | |                                                       ^ cannot use the `?` operator in a function that returns `()`
...  |
26 | |     Ok(());
27 | | }
   | |_- this function should return `Result` or `Option` to accept `?`
   |
   = help: the trait `FromResidual<Result<Infallible, CryptoAPIError>>` is not implemented for `()`

error[E0277]: the `?` operator can only be used in a function that returns `Result` or `Option` (or another type that implements `FromResidual`)
  --> src/main.rs:15:50
   |
3  | / fn main() {
4  | |     println!("Hello Concrete!");
5  | |     let min = -10.;
6  | |     let max = 10.;
...  |
15 | |     let p2: Plaintext = encoder.encode(&messages)?;
   | |                                                  ^ cannot use the `?` operator in a function that returns `()`
...  |
26 | |     Ok(());
27 | | }
   | |_- this function should return `Result` or `Option` to accept `?`
   |
   = help: the trait `FromResidual<Result<Infallible, CryptoAPIError>>` is not implemented for `()`

error[E0308]: mismatched types
  --> src/main.rs:18:24
   |
18 |     let o1: Vec<f64> = p1.decode();
   |             --------   ^^^^^^^^^^^ expected struct `Vec`, found enum `Result`
   |             |
   |             expected due to this
   |
   = note: expected struct `Vec<_>`
                found enum `Result<Vec<_>, CryptoAPIError>`

error[E0308]: mismatched types
  --> src/main.rs:19:24
   |
19 |     let o2: Vec<f64> = p2.decode();
   |             --------   ^^^^^^^^^^^ expected struct `Vec`, found enum `Result`
   |             |
   |             expected due to this
   |
   = note: expected struct `Vec<_>`
                found enum `Result<Vec<_>, CryptoAPIError>`

Some errors have detailed explanations: E0277, E0308.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `rust-hello` due to 5 previous errors

Configuration(please complete the following information):

• OS: Ubuntu 20.04

Consider RustFFT?

This post seems potentially relevant to this library: RustFFT 5.0.0-experimental.1: Now faster than FFTW!

Enable coveralls for the github repository

What is the problem you want to solve and can not with the current version?
When running tests on aws a coveralls report is generated and uploaded to coveralls. At the moment the results are not reported back in the PR or in the README.

Describe the solution you'd like
We should allow the coveralls bot to have access to the Concrete github repository. In order to do so, we should subscribe a coveralls account for Zama, and then allow the coveralls bot to have a read access to the repository: https://docs.coveralls.io/coveralls-notifications

Describe alternatives you've considered
With coveralls the other alternative is not to subscribe for the organization, and give write access to the repository.
Otherwise alternatives to Coveralls should be considered, the main one being Codecov.

Support more complex functions

Hello,

in the last example of the documentation you show how to calculate the square function of an input message. I tried to calculate something a bit different like 2*(x^2), but the compiler complains with the message ^ no implementation for {integer} * f64``` . I was wondering also if there is support for 2 variable functions, e.g., having 2 messages as x and y and calculating something like (x+y)/2.

thanks

concrete_lib >=v0.1.2 fails building

Trying to build your example with the latest version of your concrete library causes the following issues:

root@7418bc54364c:/concrete# cargo build
    Updating crates.io index
  Downloaded concrete_lib v0.1.2
   Compiling concrete_lib v0.1.2
error[E0599]: no function or associated item named `to_int_unchecked` found for type `f64` in the current scope
   --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete_lib-0.1.2/src/types/mod.rs:165:26
    |
165 |                     f64::to_int_unchecked::<$T>(
    |                          ^^^^^^^^^^^^^^^^ function or associated item not found in `f64`
...
235 | impl_trait_types!(u32, 32, std::u32::MAX, i32);
    | ----------------------------------------------- in this macro invocation
    |
    = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0599]: no function or associated item named `to_int_unchecked` found for type `f64` in the current scope
   --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete_lib-0.1.2/src/types/mod.rs:165:26
    |
165 |                     f64::to_int_unchecked::<$T>(
    |                          ^^^^^^^^^^^^^^^^ function or associated item not found in `f64`
...
236 | impl_trait_types!(u64, 64, std::u64::MAX, i64);
    | ----------------------------------------------- in this macro invocation
    |
    = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0599`.
error: could not compile `concrete_lib`.

I could make the same observation with concrete_lib = 0.1.3. The older version 0.1.1, however, works fine!

Is there any benchmark test result?

For example, the performance comparison with TenSEAL.

Fix linking issue in concrete-fftw

When compiling concrete-core on a machine with no libfftw package we see the following error:

 error: linking with `cc` failed: exit status: 1
  |
  = note: "cc" "-m64" "-Wl,--eh-frame-hdr" "-Wl,-znoexecstack" "-Wl,--as-needed" "-L" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.0.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.1.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.10.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.11.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.12.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.13.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.14.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.15.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.2.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.3.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.4.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.5.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.6.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.7.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.8.rcgu.o" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.concrete_core.7ulcvqr3-cgu.9.rcgu.o" "-o" "/home/runner/work/concrete/concrete/target/release/deps/libconcrete_core-f55034b3778ea813.so" "-Wl,--version-script=/tmp/rustchs23gw/list" "/home/runner/work/concrete/concrete/target/release/deps/concrete_core-f55034b3778ea813.10yh1prw7ykoh5cs.rcgu.o" "-Wl,--gc-sections" "-shared" "-Wl,-zrelro" "-Wl,-znow" "-Wl,-O1" "-nodefaultlibs" "-L" "/home/runner/work/concrete/concrete/target/release/deps" "-L" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/runner/work/concrete/concrete/target/release/deps/libbincode-d0d36a0a2aea249d.rlib" "/home/runner/work/concrete/concrete/target/release/deps/libconcrete_csprng-832846f2f22c592a.rlib" "/home/runner/work/concrete/concrete/target/release/deps/libaes_soft-961b86ab775405ab.rlib" "/home/runner/work/concrete/concrete/target/release/deps/libopaque_debug-639ada9a752e3c20.rlib" "/home/runner/work/concrete/concrete/target/release/deps/libcipher-f900ef5b785b5253.rlib" "/home/runner/work/concrete/concrete/target/release/deps/libgeneric_array-7169a02f8d45593a.rlib" "/home/runner/work/concrete/concrete/target/release/deps/libtypenum-4ccfbe270cf5e639.rlib" "/home/runner/work/concrete/concrete/target/release/deps/libfftw-9960a641c49ee82c.rlib" "/home/runner/work/concrete/concrete/target/release/deps/libbitflags-595472ca914e4890.rlib" "/home/runner/work/concrete/concrete/target/release/deps/libthiserror-67c480f2043db90e.rlib" "/home/runner/work/concrete/concrete/target/release/deps/liblazy_static-b6b6d150a1eb96bf.rlib" "/home/runner/work/concrete/concrete/target/release/deps/libfftw_sys-884c6da7e1645825.rlib" "/home/runner/work/concrete/concrete/target/release/deps/libnum_complex-46b2bd061f746faa.rlib" "/home/runner/work/concrete/concrete/target/release/deps/libnum_traits-08bf67490b132d79.rlib" "/home/runner/work/concrete/concrete/target/release/deps/liblibc-99d68cb7ac0c4f18.rlib" "/home/runner/work/concrete/concrete/target/release/deps/libconcrete_commons-0b771b3882d30a40.rlib" "/home/runner/work/concrete/concrete/target/release/deps/libserde-9124ea2992ccd86f.rlib" "-Wl,--start-group" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b6b48477bfa8c673.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-f560ec02638f7ffe.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-9c8eadb7013c9e0b.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-8b0ec8dbdb85d0bf.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-ba5d5ee707c805d2.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-55166126dbdd5e46.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-c327b365eae3b2f3.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-416439b546a0d033.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-2581188d29552e15.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-da7b2635bfcce6ef.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-09200ed1945e7b2b.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-223ac369b29f5000.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-39562fe6600dd936.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-9b411bb7a19f81b3.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-64ea0581d80339f7.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-b2dbda88b377d685.rlib" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-2a8415a96ed1d7dc.rlib" "-Wl,--end-group" "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-c4d9a5b072ee3191.rlib" "-Wl,-Bdynamic" "-lfftw3" "-lfftw3f" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc"
  = note: /usr/bin/ld: cannot find -lfftw3
          /usr/bin/ld: cannot find -lfftw3f
          collect2: error: ld returned 1 exit status

Issue with RLWE parameter of dimension 4096

The following code returns an error "The integer representation has not enough precision to represent error samples from the normal law of variance....". What's the right way to use this parameter set?

    let rlwe_params = RLWE128_4096_1;

    let encoder = Encoder::new(-10., 10., 8, 0).unwrap();

    // generate a fresh secret key
    let secret_key = RLWESecretKey::new(&rlwe_params);

    let messages: Vec<f64> = vec![-6.276, 4.3, 0.12, -1.1, 7.78];

    // // encode and encrypt
    let plaintext = Plaintext::new_encode(&messages, &encoder).unwrap();
    let ciphertext = RLWE::new_encrypt_on_cst(&secret_key, &plaintext).unwrap();

Parallelizable bootstrapping

What is the problem you want to solve and can not with the current version?
The current version of Concrete (tested with ae0bef, 19.1.2022) does not compile anymore with parallel iterators, inside which there is bootstrapping. This worked with master commit 7dbb91 (from 9.7.2021). Code sample:

use rayon::prelude::*;

// some init code
let mut c: Vec<LWE> = vec!...;
let mut b: Vec<LWE> = vec!...;
// not working with new Concrete, works with old Concrete:
c.par_iter().zip(b.par_iter_mut()).for_each(| (ci, bi) | {
// only this works with new Concrete:
// c.iter().zip(b.iter_mut()).for_each(| (ci, bi) | {
    *bi = ci.bootstrap_with_function(&bsk, |x| x*x, &encoder_output).expect("LWE::bootstrap_with_function failed.");
});

Find a full example in my repo, where in README one can find the full error log.

Describe the solution you'd like
Compile with parallel iterators that contain bootstrapping.

Describe alternatives you've considered
No alternatives considered.

Additional context
Full example and error log can be found in my repo.

Segfaults in avx2 methods

avx2 methods used in concrete-core/src/math/fft/polynomial.rs trigger segfaults very easily on computers compatible with avx2:

$ export RUSTFLAGS="-C target-cpu=native"
$ cd concrete-core && cargo test crypto::cross::tests::test_cmux0_u32

Interestingly, I can only reproduce it if the "source" feature is used for the fftw crate. With "system", I cannot reproduce it. So you might need to modify Cargo.toml to use the source feature.

The issue stems from those lines:

let resref: *mut __m256d = coeff_tmp_ref.as_mut_ptr() as *mut __m256d;

A __m256d must be aligned on 32-bytes (cf https://doc.rust-lang.org/core/arch/x86_64/fn._mm256_load_pd.html) but there is nothing that is guaranteeing that alignment. Actually, the code uses AlignedVec<Complex64> from fftw, which aligns on 16 bytes, not 32.

AFAICT, fftw does not provide a way to allocate a vector aligned on 32 bytes, so the fix is not trivial here. One solution could be to replace the AlignedVec with a custom one aligning correctly. Another is to stop using those unsafe casts, and use _mm256_storeu_pd which is designed to store into an unaligned pointer.

In addition, wrappers around unsafe calls should not leak unsafeness. Adding asserts such as this one:

// res is cast as a vec of __mm256d which must be aligned on 32 bytes
assert_eq!(res.as_tensor().as_slice().as_ptr() as usize % 32, 0);

would ensure the assumptions under which using those unsafe calls are made are enforced, and a clear panic is raised instead of a segfault in some cases.

Tutorial on implementing neural networks using Concrete

Thank you for this revolutionary HE effort. I was wondering whether there is any end to end tutorial for implementing a neural network using Concrete?

Serde implementation for BootstrapKey should be on AlignedVec

The BootstrapKey has multiple implementations, but when used with Complex64, it is created with an aligned vec:

impl BootstrapKey<AlignedVec<Complex64>> {
   pub fn allocate_complex(...) -> Self {
   }
}

however, the Serialize/Deserialize implementations are done for BootstrapKey<Vec<Complex64>>. This looks wrong, as the intent seems to be to always use an AlignedVec with Complex64 values.

AFAICT, the serialize/deserialize implementations should be done for BootstrapKey<AlignedVec<Complex64>>

Callback in bsk generation

Discussed today with @mayeul-zama,

It would be nice if we could give a feedback on the progress of the bsk generation.

One way to do that is to take a callback in argument, that will be called periodically. This would allow the user to implement the reporting in any way that suits him.

I think it makes sense to have such a report, but I am not sure we want to have this callback in the API...

What are your thought @damienligier @BourgerieQuentin ?

Where to PR a docs improvement?

Hi I wanted to open a PR for docs improvemente.
Here's the commit I would use for PR alessio-proietti@19f2a27.

It seems I can't open a PR to master, on which branch should I ?

Support for WebAssembly

What is the problem you want to solve and can not with the current version?
I tried to build with

wasm-pack build

and I receive the following error:

error[E0658]: use of unstable library feature 'stdsimd'
  --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:21:12
   |
21 |         if is_x86_feature_detected!("aes")
   |            ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #27731 <https://github.com/rust-lang/rust/issues/27731> for more information

error: 
               is_x86_feature_detected can only be used on x86 and x86_64 targets.
               You can prevent it from being used in other architectures by
               guarding it behind a cfg(target_arch) as follows:
       
                   #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] {
                       if is_x86_feature_detected(...) { ... }
                   }
               
  --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:21:12
   |
21 |         if is_x86_feature_detected!("aes")
   |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `is_x86_feature_detected` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: use of unstable library feature 'stdsimd'
  --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:22:16
   |
22 |             && is_x86_feature_detected!("rdseed")
   |                ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #27731 <https://github.com/rust-lang/rust/issues/27731> for more information

error: 
               is_x86_feature_detected can only be used on x86 and x86_64 targets.
               You can prevent it from being used in other architectures by
               guarding it behind a cfg(target_arch) as follows:
       
                   #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] {
                       if is_x86_feature_detected(...) { ... }
                   }
               
  --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:22:16
   |
22 |             && is_x86_feature_detected!("rdseed")
   |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `is_x86_feature_detected` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: use of unstable library feature 'stdsimd'
  --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:23:16
   |
23 |             && is_x86_feature_detected!("sse2")
   |                ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #27731 <https://github.com/rust-lang/rust/issues/27731> for more information

error: 
               is_x86_feature_detected can only be used on x86 and x86_64 targets.
               You can prevent it from being used in other architectures by
               guarding it behind a cfg(target_arch) as follows:
       
                   #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] {
                       if is_x86_feature_detected(...) { ... }
                   }
               
  --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:23:16
   |
23 |             && is_x86_feature_detected!("sse2")
   |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `is_x86_feature_detected` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: use of unstable library feature 'stdsimd'
  --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/lib.rs:54:13
   |
54 |         if !is_x86_feature_detected!("aes")
   |             ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #27731 <https://github.com/rust-lang/rust/issues/27731> for more information

error: 
               is_x86_feature_detected can only be used on x86 and x86_64 targets.
               You can prevent it from being used in other architectures by
               guarding it behind a cfg(target_arch) as follows:
       
                   #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] {
                       if is_x86_feature_detected(...) { ... }
                   }
               
  --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/lib.rs:54:13
   |
54 |         if !is_x86_feature_detected!("aes")
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `is_x86_feature_detected` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: use of unstable library feature 'stdsimd'
  --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/lib.rs:55:17
   |
55 |             || !is_x86_feature_detected!("rdseed")
   |                 ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #27731 <https://github.com/rust-lang/rust/issues/27731> for more information

error: 
               is_x86_feature_detected can only be used on x86 and x86_64 targets.
               You can prevent it from being used in other architectures by
               guarding it behind a cfg(target_arch) as follows:
       
                   #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] {
                       if is_x86_feature_detected(...) { ... }
                   }
               
  --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/lib.rs:55:17
   |
55 |             || !is_x86_feature_detected!("rdseed")
   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `is_x86_feature_detected` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: use of unstable library feature 'stdsimd'
  --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/lib.rs:56:17
   |
56 |             || !is_x86_feature_detected!("sse2")
   |                 ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #27731 <https://github.com/rust-lang/rust/issues/27731> for more information

error: 
               is_x86_feature_detected can only be used on x86 and x86_64 targets.
               You can prevent it from being used in other architectures by
               guarding it behind a cfg(target_arch) as follows:
       
                   #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] {
                       if is_x86_feature_detected(...) { ... }
                   }
               
  --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/lib.rs:56:17
   |
56 |             || !is_x86_feature_detected!("sse2")
   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `is_x86_feature_detected` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0432]: unresolved import `std::arch::x86_64`
 --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:7:16
  |
7 | use std::arch::x86_64::{
  |                ^^^^^^ could not find `x86_64` in `arch`

error[E0433]: failed to resolve: could not find `x86_64` in `arch`
  --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:70:28
   |
70 |             if core::arch::x86_64::_rdseed64_step(&mut rand1) == 1 {
   |                            ^^^^^^ could not find `x86_64` in `arch`

error[E0433]: failed to resolve: could not find `x86_64` in `arch`
  --> /home/mihai/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:75:28
   |
75 |             if core::arch::x86_64::_rdseed64_step(&mut rand2) == 1 {
   |                            ^^^^^^ could not find `x86_64` in `arch`

Describe the solution you'd like
A possible solution ( I'm not sure) is to have a mapping between core::arch::x86_64 to core::arch::wasm32
For example
use std::arch::x86_64:: __m128i;
https://doc.rust-lang.org/core/arch/x86_64/struct.__m128i.html
From documentation they say that :

Internally this type may be viewed as:

i8x16 - sixteen i8 variables packed together
i16x8 - eight i16 variables packed together
i32x4 - four i32 variables packed together
i64x2 - two i64 variables packed together

So for core::arch::x86_64::__m128 can be mapped to core::arch::wasm32::i8x16 / core::arch::wasm32::i16x8 / core::arch::wasm32::i32x4 / core::arch::wasm32::i64x2

Later edit :
Besides those mappings, I see that are specialized CPU intrinsics like _mm_aeskeygenassist_si128 .
So you can't do anything until WASM fully supports SIMD.

So if you know any other Rust library that can be compiled to wasm and offers at least basic arithmetic operation (addition, substitution, division and multiplication) for at least integers please tell me.
Thanks

How to handle addition of ciphertext with different paddings?

I'm trying to do a dot product between a vector and a matrix (which both hold ciphertexts, not f64). My issue is how to perform the sum of a vector of LWE.

During the computation of the inner product between two Vec<LWE>, I need to accumulate the result of vec1[i] * vec2[i]. The accumulator will loose one bit of padding with every addition, and it will raise an error in the second addition because ciphertexts doesn't have the same number of bits for the padding. One alternative is to sum them two by two, the same way a binary tree is organized, till we get to the root (it doesn't work for vec of odd size I guess). However, I'm wondering if there is a better way to do this. Or should I think of the problem differently?

The code snippet below is for explaining the root problem, I'm accumulating two instances of ct2, but it could have been different or more values.

use concrete_lib::*;

fn test_add() -> Result<(), CryptoAPIError> {
    let enc1 = Encoder::new(0., 5., 8, 1)?;
    let enc2 = Encoder::new(5., 10., 8, 1)?;
    let m1 = 2.5;
    let m2 = 7.5;
    let sk = LWESecretKey::new(&LWE80_512);
    // acc will accumulate multiple instances of ct2, but it could have been different ct
    let mut acc = LWE::encode_encrypt(&sk, m1, &enc1)?;
    let ct2 = LWE::encode_encrypt(&sk, m2, &enc2)?;
    // first one works
    acc.add_inplace(&ct2)?;
    // second doesn't work because they don't have the same number of bits in the padding
    acc.add_inplace(&ct2)?;
    Ok(())
}

fn main() {
    test_add().unwrap();
}

concrete_npe::estimate_external_product_noise_with_binary_ggsw

Hi, I've been seeing some weird results from the noise estimation in concrete_npe::estimate_external_product_noise_with_binary_ggsw.

In particular, the third term on line 608 that gives the error of the decomposition seems to be incorrect:

    let res_3 = (square(T::BITS) as f64 - b2l) / (24. * b2l)
        * (1.
            + k * big_n
                * (K::variance_key_coefficient::<T>().get_modular_variance::<T>()
                    + square(K::expectation_key_coefficient())));

I compared the expression with those in https://eprint.iacr.org/2021/729.pdf. Could it be that the square(T::BITS) must be changed to square(f64::powi(2., T::BITS as i32))?

How to solve the problem that concrete is not supported on the Mac M1 chip

 Compiling concrete-csprng v0.1.7
error[E0658]: use of unstable library feature 'stdsimd'
  --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:21:12
   |
21 |         if is_x86_feature_detected!("aes")
   |            ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #27731 <https://github.com/rust-lang/rust/issues/27731> for more information

error: 
        is_x86_feature_detected can only be used on x86 and x86_64 targets.
        You can prevent it from being used in other architectures by
        guarding it behind a cfg(target_arch) as follows:

            #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] {
                if is_x86_feature_detected(...) { ... }
            }
        
  --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:21:12
   |
21 |         if is_x86_feature_detected!("aes")
   |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `is_x86_feature_detected` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: use of unstable library feature 'stdsimd'
  --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:22:16
   |
22 |             && is_x86_feature_detected!("rdseed")
   |                ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #27731 <https://github.com/rust-lang/rust/issues/27731> for more information

error: 
        is_x86_feature_detected can only be used on x86 and x86_64 targets.
        You can prevent it from being used in other architectures by
        guarding it behind a cfg(target_arch) as follows:

            #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] {
                if is_x86_feature_detected(...) { ... }
            }
        
  --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:22:16
   |
22 |             && is_x86_feature_detected!("rdseed")
   |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `is_x86_feature_detected` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: use of unstable library feature 'stdsimd'
  --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:23:16
   |
23 |             && is_x86_feature_detected!("sse2")
   |                ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #27731 <https://github.com/rust-lang/rust/issues/27731> for more information

error: 
        is_x86_feature_detected can only be used on x86 and x86_64 targets.
        You can prevent it from being used in other architectures by
        guarding it behind a cfg(target_arch) as follows:

            #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] {
                if is_x86_feature_detected(...) { ... }
            }
        
  --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:23:16
   |
23 |             && is_x86_feature_detected!("sse2")
   |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `is_x86_feature_detected` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: use of unstable library feature 'stdsimd'
  --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/lib.rs:54:13
   |
54 |         if !is_x86_feature_detected!("aes")
   |             ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #27731 <https://github.com/rust-lang/rust/issues/27731> for more information

error: 
        is_x86_feature_detected can only be used on x86 and x86_64 targets.
        You can prevent it from being used in other architectures by
        guarding it behind a cfg(target_arch) as follows:

            #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] {
                if is_x86_feature_detected(...) { ... }
            }
        
  --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/lib.rs:54:13
   |
54 |         if !is_x86_feature_detected!("aes")
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `is_x86_feature_detected` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: use of unstable library feature 'stdsimd'
  --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/lib.rs:55:17
   |
55 |             || !is_x86_feature_detected!("rdseed")
   |                 ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #27731 <https://github.com/rust-lang/rust/issues/27731> for more information

error: 
        is_x86_feature_detected can only be used on x86 and x86_64 targets.
        You can prevent it from being used in other architectures by
        guarding it behind a cfg(target_arch) as follows:

            #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] {
                if is_x86_feature_detected(...) { ... }
            }
        
  --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/lib.rs:55:17
   |
55 |             || !is_x86_feature_detected!("rdseed")
   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `is_x86_feature_detected` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: use of unstable library feature 'stdsimd'
  --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/lib.rs:56:17
   |
56 |             || !is_x86_feature_detected!("sse2")
   |                 ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #27731 <https://github.com/rust-lang/rust/issues/27731> for more information

error: 
        is_x86_feature_detected can only be used on x86 and x86_64 targets.
        You can prevent it from being used in other architectures by
        guarding it behind a cfg(target_arch) as follows:

            #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] {
                if is_x86_feature_detected(...) { ... }
            }
        
  --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/lib.rs:56:17
   |
56 |             || !is_x86_feature_detected!("sse2")
   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `is_x86_feature_detected` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0432]: unresolved import `std::arch::x86_64`
 --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:7:16
  |
7 | use std::arch::x86_64::{
  |                ^^^^^^ could not find `x86_64` in `arch`

error[E0433]: failed to resolve: could not find `x86_64` in `arch`
  --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:70:28
   |
70 |             if core::arch::x86_64::_rdseed64_step(&mut rand1) == 1 {
   |                            ^^^^^^ could not find `x86_64` in `arch`

error[E0433]: failed to resolve: could not find `x86_64` in `arch`
  --> /Users/cheng/.cargo/registry/src/github.com-1ecc6299db9ec823/concrete-csprng-0.1.7/src/aesni.rs:75:28
   |
75 |             if core::arch::x86_64::_rdseed64_step(&mut rand2) == 1 {
   |                            ^^^^^^ could not find `x86_64` in `arch`

error: aborting due to 15 previous errors

Some errors have detailed explanations: E0432, E0433, E0658.
For more information about an error, try `rustc --explain E0432`.
error: could not compile `concrete-csprng`

LWE's `mul_from_bootstrap` returns `NotEnoughPaddingError` on 1-bit precisions

Describe the bug
LWE's mul_from_bootstrap returns NotEnoughPaddingError when passed a 1-bit precision encoder.

To Reproduce

Upon running the following code:

use concrete::*;
use std::error::Error;

fn main() -> Result<(), Box<dyn Error>> {
    let encoder = Encoder::new_rounding_context(-1.0, 1.0, 1, 3)?;

    let sk_rlwe = RLWESecretKey::new(&RLWE128_1024_1);
    let sk_in = LWESecretKey::new(&LWE128_1024);
    let sk_out = sk_rlwe.to_lwe_secret_key();

    let bsk = LWEBSK::new(&sk_in, &sk_rlwe, 3, 5);

    let c1 = LWE::encode_encrypt(&sk_out, 0.0, &encoder)?;
    let c2 = c1.mul_from_bootstrap(&c1, &bsk)?;

    Ok(())
}

This error is produced:

Expected behaviour
mul_from_bootstrap should not error on 1-bit precisions.

Evidence
Inspecting the source code at https://github.com/zama-ai/concrete/blob/main/concrete/src/lwe/mod.rs#L1955-L1958, the code appears to be checking for the number of bits of precision, rather than padding:

// return an error if nb_bit_precision < 2
if ct1.encoder.nb_bit_precision < 2 {
    return Err(NotEnoughPaddingError!(ct1.encoder.nb_bit_precision, 2));
}

This should be corrected by checking for ct1.nb_bit_padding instead. The same issue can be observed in VectorLWE at https://github.com/zama-ai/concrete/blob/main/concrete/src/vector_lwe/mod.rs#L2236-L2239.

Configuration:

• OS: Ubuntu 20.04 (on WSL2)

Benchmarks no longer compiling

We did not propagate the changes in the bootstrap API to the benchmarks (0b5fb5e). They are hence no longer compiling. That should be fixed quickly.

shortints serialize err

the trait Deserialize<'_> is not implemented for concrete::shortints::types::r#static::ShorIntId<2_u8>

Need to manage padding for deep computation

I am trying to perform a vector matrix multiplication in the encrypted domain using levelled operations and bootstrapping when necessary.

However while performing levelled multiplication and addition I am running out of padding bits.

The documentation states that bootstrapping can free padding bits. However, in my code the padding bits are not freed up after bootstrapping limiting my computation depth.

I am using:
mul_constant_with_padding_inplace for multiplication with real constant.
add_with_padding_inplace for accumulation/reduction (using binary tree style accumulation to avoid unequal padding issues).
bootstrap to bootstrap the ciphertexts when only 1 bit of padding is left during the accumulation/reduction (padding bits not freed up here).
keyswitch to switch keys to the original input key.

Is there way to free up padding after certain number of operations so that ciphertexts be added further up to infinite depth?

Publish latest release to crates.io

The latest version of concrete on crates.io is 0.1.11, but the latest on GitHub is 0.2.1. Can you please publish to crates.io as well so that we can use it via cargo?

Random-seeming Encoder delta after PBS

When using the PBS to change the encoder of the encryption of one ciphertext to match the second one w.r.t. same interval sizes I started wondering as the delta of the ciphertext seems to randomly change after the PBS. I expected the encoder to behave of the ciphertext to change to exactly the interval values of the encoder itself, is this a bug or is it intended this way?

    //ct_out_1, ciphertext_1, ct_out_2, ciphertext_2 are VectorLWE ciphertexts

    println!("Output intervals before bootstrapping: [{:?}, {:?}], [{:?}, {:?}]", ct_out_1.encoders[0].get_min(), ct_out_1.encoders[0].get_max(), ct_out_2.encoders[0].get_min(), ct_out_2.encoders[0].get_max());
    //with key-parameters "rlwe_params = RLWE80_2048_1; rlwe_params.log2_std_dev = -62; let mut lwe_params = LWE80_2048; lwe_params.log2_std_dev = -62; I got following output here
    //Output intervals before bootstrapping: [0.4, 13.23123], [1.001, 13.83223]

    //now we want to bring both ciphertexts to the same padding and apply the new encoders during the bootstrap
    //we bootstrap to refresh padding, if it is too small, and have to bootstrap to update the encoder for the smaller interval range
    if (ct_out_1.encoders[0].nb_bit_padding <= padding) || (ciphertext_1.encoders[0].delta < ciphertext_2.encoders[0].delta) {
        for i in 0..ciphertext_1.nb_ciphertexts {
            let bootstrapped_pos_i = ciphertext_1.bootstrap_nth_with_function(&bsk, |x| x, &ct_out_1.encoders[0], i).unwrap();
            ct_out_1.copy_in_nth_nth_inplace(i, &bootstrapped_pos_i, 0).unwrap();
        }

        println!("Pre keyswitch Output intervals: [{:?}, {:?}], [{:?}, {:?}]", ct_out_1.encoders[0].get_min(), ct_out_1.encoders[0].get_max(), ct_out_2.encoders[0].get_min(), ct_out_2.encoders[0].get_max());
        //suddenly output becomes: Pre keyswitch Output intervals: [0.4, 13.23123], [1.001, 10.624569344014649]

        //key switch back to normal key
        ct_out_1 = ct_out_1.keyswitch(&ksk).unwrap();
    }

What surprised me even more, I was able to pull of a multiplication (between ct_out_1 and ct_out_2 with mul_from_bootstrap_nth) even though the encoder intervals have different sizes and the resulting output encoder looked even weirder with (minval: -140.9702431766974, maxval: 71.22117196334871), imo this should be then (minval=0.4*1.001, maxval=13.23123*10.624569344014649) as this would be the actual boundary or am I wrong here?
(Surprisingly, the result was even pretty close to correct)

Build stalling on concrete-fftw-sys step

Describe the bug
When I try to build the sample rust project in the docs, which includes concrete, it seems to stall during the initial import on the fftw build step.

To Reproduce
Steps to reproduce the behaviour

1. Use the following docker-compose file to start up a development container:
   docker-compose.yml

version: '3.7'
services:
  concrete-dev-node:
    image: rust
    container_name: concrete-dev-node
    command: apt-get update && apt-get install -y libfftw3-dev && tail -f /dev/null
    volumes:
      - .:/workspace

2. Run docker-compose up -d to start the dev container.
3. Setup initial project as described in the documentation ( https://docs.zama.ai/concrete/lib/installation.html#importing-concrete-in-your-project )
4. On the compile and run step, the build stalls. It seems to be doing something, as my CPU fan is spinning hard, but it's stuck on the concrete-fftw-sys(build) step.

Expected behaviour
The Build works as expected.

Evidence

root@5bee72071d4d:/workspace/play_with_fhe# RUSTFLAGS="-C target-cpu=native" cargo run --release 
    Updating crates.io index
   Compiling proc-macro2 v1.0.34
   Compiling unicode-xid v0.2.2
   Compiling syn v1.0.83
   Compiling autocfg v1.0.1
   Compiling serde_derive v1.0.132
   Compiling serde v1.0.132
   Compiling version_check v0.9.3
   Compiling typenum v1.14.0
   Compiling fs_extra v1.2.0
   Compiling libc v0.2.112
   Compiling memchr v2.4.1
   Compiling cc v1.0.72
   Compiling lazy_static v1.4.0
   Compiling opaque-debug v0.3.0
   Compiling bitflags v1.3.2
   Compiling either v1.6.1
   Compiling serde_json v1.0.73
   Compiling adler v1.0.2
   Compiling gimli v0.26.1
   Compiling concrete v0.1.11
   Compiling itoa v1.0.1
   Compiling cfg-if v1.0.0
   Compiling rustc-demangle v0.1.21
   Compiling ryu v1.0.9
   Compiling num-traits v0.2.14
   Compiling miniz_oxide v0.4.4
   Compiling generic-array v0.14.4
   Compiling concrete-fftw-sys v0.1.2
   Compiling itertools v0.9.0
   Compiling backtrace v0.3.63
   Compiling addr2line v0.17.0
   Compiling concrete-npe v0.1.9
   Compiling quote v1.0.10
   Compiling atty v0.2.14
   Compiling object v0.27.1
   Compiling colored v2.0.0
   Compiling cipher v0.2.5
   Compiling aes-soft v0.6.4
   Compiling concrete-csprng v0.1.7
   Compiling num-complex v0.4.0
   Compiling bincode v1.3.3
   Compiling concrete-commons v0.1.1
   Building [=======================>   ] 67/73: concrete-fftw-sys(build) 

Configuration(please complete the following information):

• Ubuntu 20.04 rust base docker image

Additional context
NA

License Question: How Does the Extra Clause Effect Unmodified Commercial Use?

Hey there! I just found the project, but I'm trying to understand the implications of this clause in the license:

*EXEMPTION: ZAMA grants to the user a non-exclusive, free and non-commercial license
on all patents filed in its name relating to the open-source code (the "Patents") for
the sole purpose of development, research, prototyping and experimentation. It is agreed
that ZAMA will support the user and the community to use, develop and improve this
open-source code and Patents included in it. As a counterpart, the user undertakes to
collaborate and share information with ZAMA regarding any use, developments or improvements,
whether protectable or not, of this open-source code and Patents included in it. In
particular, the user commits to declaring to ZAMA their wish to file any patent or
copyright application relating to this open-source code and Patents included in it,
before the application is filed.

Does this mean it's not possible to use this project in a commercial application without infringing on your patents, even if the code is un-modified?

Encryption suddenly becomes VERY slow (Urgent)

I am experiencing something very strange with my encryption when I am trying to encrypt values.
I have three servers, Say Server A, B and C. Server A and B is on the same local network, C is not.
For my development i have been using server C and i can encrypt 1000 values in a matter of seconds.
But on Server A and B, the first few values are encypted with the same speed as you would expect, but after a while every single encryption takes >1 min.

What im trying to do is this;
let enc = Encoder::new(-15, 45, 10, 13).unwrap();
let sk = load_sk();
let mut ct: LWE
for _ in 0..10{
ct = LWE::encode_encrypt(&sk, 0.0, &enc)?;
}

Should only take a few hundred micro seconds for all 10 encryptions when it's working(like it does on Server C, where i do 1000 instead of 10), but only the first few encryptions does.

When either Server A or B is newly upstarted/ not been used for a while I get a good run, like this:

but if i now try again i get this:

and try one more time:

Server A: Ubuntu 18.04.3
Server B: Ubuntu 18.04.2
Server C: Ubuntu 18.04.5

Very urgent to get this working, anyone have any idea?
Sincerely

Edit(s): Time measurements were done inside the loop.
If I only encrypt one value, and run the file multiple times, the same problem occurs and in similar fashion.

add disclaimers for security estimation and side channel attacks

Storing ciphertext

Hi,

This is a question, not really an issue, but here goes.

How would one go about storing the encrypted values into a database? I am talking in practical terms; store, then later read (possibly query) and do some operations on the stored values with Concrete. Would it be enough to store the actual ciphertext, but then how would I reconstruct the ciphertext object that I need for operations? In my research so far, I have only encountered CryptDB, which was impressive at the time, but I couldn't find any other attempts at solving this problem, using the CKKS scheme for example. Do you perhaps know of any other research that could help me? I could utilize concrete-boolean and perhaps postgres to make something of my own, but if you know of something that would save some time, I would be extremely grateful.

Thank you for your help!

Best,
Mirza

Questions regard to the module npe and the macro deltas_eq

It has been a while since I use this library. It is an extraordinary FHE library. I have two questions during my usage.

Q1: The formula for noise estimation of key switching is potentially wrong.

In concrete version 0.1.7, the following code is weird from my point of view:

concrete/concrete-npe/src/lwe.rs

Line 56 in aa73965

let q_square = f64::powi(2., (2 * std::mem::size_of::<$T>()) as i32);

I guess it should be

let q_square = f64::powi(2., (2 * std::mem::size_of::<$T>() * 8) as i32);

Q2: The deltas_eq macro confused me.

concrete/concrete/src/lib.rs

Lines 123 to 130 in aa73965

	macro_rules! deltas_eq {
	($delta1: expr, $delta2: expr) => {{
	let tmp = ($delta1 - $delta2).abs() / $delta1.max($delta2);
	let limit1 = $delta1 / f64::powi(2., -40);
	let limit2 = $delta2 / f64::powi(2., -40);
	tmp < limit1 && tmp < limit2
	}};
	}

As the name suggested, the macro compares the equality of two f64 variables. However, a simple pair of float numbers (10., 20.) proves the macro is not working.

Hope to get a reply.

Consider implementing a fallback for old intel cpus

Regarding 4277054:

As of now old cpus' owner folks is excluded from contributing and explorating the project behind your product.
Being that many academic equipment is quite outdated could turn out useful to implement a fallback on widespread libraries that support old machines, at least in a initial stage.

Compile issue in Ubuntu 20

During compiling procedure (in ubuntu 20.04) of concrete (concrete$ sudo cargo build)
I have got following errors:
1.
error[E0277]: the trait bound Scalar: numeric::CastFrom<<Scalar as numeric::unsigned::UnsignedInteger>::Signed> is not satisfied
--> concrete-core/src/crypto/lwe/keyswitch.rs:669:21
|
669 | Scalar::Signed: SignedInteger,
| ^^^^^^^^^^^^^ the trait numeric::CastFrom<<Scalar as numeric::unsigned::UnsignedInteger>::Signed> is not implemented for Scalar

error[E0277]: the trait bound Self: numeric::CastFrom<<Self as numeric::signed::SignedInteger>::Unsigned> is not satisfied
--> concrete-core/src/numeric/signed.rs:37:20
|
37 | type Unsigned: UnsignedInteger<Signed = Self> + CastFrom;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait numeric::CastFrom<<Self as numeric::signed::SignedInteger>::Unsigned> is not implemented for Self
...

I can compile successfully stale brach: concrete_lib (Updated 5 months ago by damienligier) but the issue is happened with master branch (

Format comments throughout concrete

At the moment the doc test is not formatted correctly: it is possible to format doc tests with the nightly version of rustfmt, by configuring:

format_code_in_doc_comments = true
wrap_comments = true

in rustfmt.toml

Easier process to install: fftw without the system feature

Just FYI, the fftw crate with the default feature already takes care of installing fftw from source. It seems to work out of the box on Mac : o

Maybe it's a good idea to remove the system feature? Unless it was here for a reason.

[dependencies.fftw]
 version = "^0.5.0"
 default-features = false
-features = ["system"]

Error in bootstrap noise formula

@mvanbeirendonck reported an error in the noise formula of the bootstrap:

Think I found another issue with noise estimation that's so small that I won't create a seperate ticket.

In estimate_pbs_noise:

concrete/concrete-npe/src/operators.rs

Line 712 in ae0bef1

let b = base_log.0 as f64;

I believe this should be changed to:

    let b = (1 << base_log.0) as f64;

_Originally posted by @mvanbeirendonck in zama-ai/tfhe-rs#423

Bug in concrete: two tests fail

Two tests are failing in concrete, following the update with concrete-core:
https://github.com/zama-ai/concrete/runs/2914419527?check_suite_focus=true

failures:

---- vector_lwe::tests::test_encode_encrypt_x_mul_constant_with_padding_inplace_x_decrypt stdout ----
---- vector_lwe::tests::test_encode_encrypt_x_mul_constant_with_padding_inplace_x_decrypt stderr ----
thread 'main' panicked at '-284.56595702353104 != 24837.640563888002 +- 14708.530285714287 (|delta|=25122.20652091153)-> encoder:  Encoder {
            -> [10129.110278173715,39546.17084960229[
            -> center = 24837.640563888002
            -> radius = 14708.530285714287
            -> nb bit precision = 1
            -> granularity = 14708.530285714287
            -> nb bit padding = 0
            -> round = false
        }
            ', concrete/src/vector_lwe/tests.rs:502:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- lwe::tests::test_encode_encrypt_x_bootstrap_x_decrypt stderr ----
thread 'main' panicked at '1572.525020060912 != 894.661 +- 209.916 (|delta|=677.8640200609121)-> encoder:  Encoder {
            -> [894.661,1734.3249999999998[
            -> center = 1314.493
            -> radius = 419.832
            -> nb bit precision = 2
            -> granularity = 209.916
            -> nb bit padding = 3
            -> round = false
        }
            ', concrete/src/lwe/tests.rs:554:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace