I am not familiar with the rust language, but I’d like to learn and understand how TFHE-rs implements e.g. doing the boolean gate bootstrapping to turn a noisy TLWE ciphertext into a refreshed one (of course with the boolean gate finished), does anyone have some suggestions?
I have read some basic TFHE papers and also the blog posts from Zama, all of this help me understand more in the theoritical way. However, from the implementation perspective, I learned TFHE would use discretized torus and scales to ℤ_𝑞 to implement. And my question is assume it’s under 128 bit security level, why TFHE-rs chooses different parameter set compared to another FHE library that implements the TFHE-like cryptosystem?
Is it because TFHE-rs applies FFT rather than NTT? Are there any other differneces? (It seems like 3 types of TFHE ciphertexts use the same ciphertext modulus 2^32/2^64?)
I guess the best way to understand how things are implemented is to have a look at the code I think the paper CONCRETE: Concrete Operates oN Ciphertexts Rapidly by Extending TfhE might help you.
TFHE-rs is meant to be dedicated to TFHE: as you said, the FFT is used instead of the NTT, and security parameters are chosen to get best performance. For instance, the noise values are determined in function of the space allocated to the level operations. The other parameters are then deduced. More details here. This differs from having a fixed noise input, and so overall performance are improved. Note that using a NTT vs an FFT has also an impact on the parameter choice.
The main advantage of TFHE in comparison with other schemes is to work with word-size ciphertext modulus, which often leads (by construction) to better performance on current CPU architecture.
Probably I am not familiar with phrase “word-size ciphertext” modulus,can you little elaborate
it means that for a 64 bits machine like x86_64 with words of size 64 bits, the computations are naturally done modulo 2^64 (as the overflow bits are lost during operations performed by the CPU), so the modulo are free on those machines.
turns out that x86_64 also has 32 bits operations that wrap around for 2^32 and we also make use of that