Stricter Evaluation API
Closed this issue · 1 comments
SEAL's evaluation API is a bit too lenient, which makes HIT's APIs equally lenient.
For example, SEAL multiplication allows inputs where one or more ciphertexts is not linear, but it's impossible to relinearize such a ciphertext (at least without using an unknown-to-me SEAL API for generating more relinearization keys).
Similarly, rescale_to_next permits ciphertexts with nominal scale, which results in a ciphtext with scale ~0, which is bad.
Our documentation explains what properties the input ciphertexts should have, but we don't actually check for it. In most cases, a bad input results in a SEAL error (which is fine), but when it doesn't, the user can get stuck in a situation they don't know how to get out of. It would be nice if HIT enforced a stricter API that prevented users from calling functions on inputs which don't throw a SEAL error but which are probably not intended.