Open bcebere opened 3 years ago
That is the expected behavior. You probably know how to use the function int Decryptor::invariant_noise_budget(...)
to monitor noise growth. This function behaves differently from and takes longer than Decryptor::decrypt(...)
. Automatically monitoring budget in decryption will make decryption much slower. However, I do think that your suggestion is very useful in DEBUG mode, and I might add it to a future version.
Please do not close this issue. Thanks!
Thank you for the explanation!
I have 2 more questions, sorry for the spam:
invariant_noise_budget
there to monitor how much precision I'm losing.123.456
; optimal noise might give you 123.456***
; a tolerable noise gives you 123.4**
; a big noise gives you 12*.***
. The precision you get is the distance between scale
and noise. The rescaling after each multiplying/squaring of ciphertexts stabilizes the distance. However, the usual cause of decryption failure is the growth of value before decimal point, for example, when exponentiating 2.0
, the value before decimal point eventually grows beyond the CoeffModulus
. This will cause a decryption failure and makes the result totally wrong. Therefore, the choice of parameters is less related to noise growth, but the number of rescaling and the precision of your application.sec_level_type::none
to SEALContext
's constructor to temporarily allow insecure parameters.CoeffModulus
should be the depth of your application plus 2 (or more).CoeffModulus
should have the same bit-size of the scale.CoeffModulus
should have the same size and not less than scale.CoeffModulus
if the result is totally wrong. Increase the scale and related primes if precision is low. Decrease the scale and related primes if precision is more than enough.sec_level_type::none
to enforce secure parameters. Increase poly_modulus_degree
if `SEALContext's constructor fails.
Hello. I have the following code snippet, just a simple ciphertext - ciphertext multiplication.
I know that it exceeds the limits of the parameters, but instead of throwing an exception, it decrypts to the wrong value
Is this the expected behavior? should we monitor the noise budget? I was hoping that SEAL would throw an exception in situations like this.
Tested with SEAL 3.6.1