Closed DAL3X closed 1 year ago
Hello again, I tried tackling my problem by calculating a seventh prime number and using it as the "special prime" as described in example 3.
Is this the intended way to achieve a 6 prime RNS? And is there an implementation reason, why modulus switching once is required when using the BFV scheme?
Because now the relinearisation key is in a 7 prime RNS, while the ciphertexts are in a 6 prime RNS. My hardware accelerator requires both of them to be in the same RNS. Is there any way to disable modulus switching entirely without rewriting significant parts of the code base?
Thank you for any answers.
Working further with the code base has allowed me to understand that SEAL uses BEHZ RNS multiplications and the relinearisation keys are stored in NTT format. The question simply came from a lack of understanding the library.
Hello, I am working on a client-server HE architecture that uses SEAL as the main client component and a hardware accelerator on the server side. I need SEAL to only take care of the key creation, batching, encryption and decryption using the BFV scheme. Computations like multiplications and additions of ciphertexts should be handled by the hardware side. It is therefor necessary for me to obtain the full ciphertexts and relinearization keys in a form that is readable for my accelerator (like a vector of unsigned 64 bit integers). Following issue #537 and example 3 it seems there is no obvious way to obtain this data because of the way SEAL handles modulus switching chains.
With a polynomial modulus degree of 8192 and coefficient modulus consisting of 6x 30-bit Primes I would expect to obtain 2 x 6 x 8192 values as one ciphertext in RNS format. But using
cipher.dyn_array().size()
on a ciphertext reveals 2 x 5 x 8192 values.Is there any way in the current SEAL implementations to obtain all of these values? Any help is greatly appreciated!