Open fjarri opened 4 years ago
What does log_i
parameter do in eval_exp()
?
The bootstrap precision dropped very slightly after commit 5d7f956e6d94c802216663e9f998f4deea985044 , even though it seems to be the correct way to handle mod_up_to()
(and the same way C++ code works).
BootContext
constructor for rpvec
and rpvecInv
is params.log_lo_modulus + 2 * log_plen
(essentially, comes from, C++ HEAAN). Not sure what is the second log_plen
needed for - the tests seem to work fine with just params.log_lo_modulus + log_plen
(no assertions in polynomial.jl
are hit, so we're staying within ranges), but then again, perhaps there are some conditions where this limit is necessary.
The bootstrapping procedure that was ported from C++ HEAAN is described in "Improved Bootstrapping for Approximate Homomorphic Encryption" by Cheon et al (2018), section 2.2.
It works for non-full-slot ciphertexts (that is,
slots < 2^(polynomial_length - 1)
), or at least, it works just as it does in C++ HEAAN. There is still a significant precision loss, although perhaps, that is what's expected.There is a number of problems/unexplained questions.
In commit e0ecd8d5577578d3f4f23633c78420c6d1d0dd91 an optional
log_precision
argument toadd_const()
was removed, which was used inexp2pi()
. The intention seemed to be to override the precision of the constant with that used inBootContext
. But if you add a constant with a precision different fromcipher.log_precision
to a ciphertext, you'll get trash results, which can be checked by testingadd_const()
separately. Nevertheless, somehow it worked, and the precision was even slightly better, 6 to 13 bits retained instead of 6 to 10.In
exp2pi()
, in the linecipher23
andcipher01
have differentlog_precision
/log_cap
, so technically cannot be added. Nevertheless, they are added in HEAAN C++, and the way it works,add()
used the first ciphertext's parameters for the results. Since in this portadd
is stricter, I had to addmod_down_to()
forcipher01
, which didn't seem to change the results.If one changes the bootstrap test to use a full-slot ciphertext (so,
log_slots=7
), there are multiple mismatches of precision and cap inadd
andmul
functions. I tried to alleviate them by making ciphertexts compatible if needed by dropping cap/precision withbut there were still other problems with this code path, so I'm not sure how well it helped. Leaving it for reference here.
It is unclear what is the expected behavior of
bootstrap()
. How high can it be expected to raiselog_cap
? How does chosenlog_precision
forBootContext
affect things (and why is it taken aslog_cap + 4
, specifically, in C++ HEAAN)? Can we predict the precision/cap drop inexp2pi()
andeval_exp()
depending on ciphertexts and boot context parameters, and deduce the optimal way of performing the calculation?Finally, full-slot ciphertext bootstrapping simply does not work, even with the use of
make_compatible()
, because I could not find the set of parameters where thelog_precision
of a ciphertext wouldn't drop below0
at some point (inexp2pi()
). Strangely enough, in C++ HEAAN it does drop below zero (which, in my understanding, would mean that the ciphertext contains complete rubbish), and yet the result is accurate within 2 to 11 bits. Weird.