Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug[he/rlwe]: he.LinearTransfromationEvaluator.EvaluateManyNew correctness error #455

Open
Pro7ech opened this issue Apr 29, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@Pro7ech
Copy link
Contributor

Pro7ech commented Apr 29, 2024

Summary

he.EvaluateLinearTransformationsMany computes the CRT decomposition of the input ciphertext once and stores it in the field BuffDecompQP of the rlwe.Evaluator. It then uses it to compute the necessary lazy-pre-rotated ciphertexts for each linear transformation, re-using BuffDecompQP if MultiplyByDiagMatrixBSGS is called, or is directly passed as an argument for the lazy gadget for MultiplyByDiagMatrix .

However BuffDecompQP is used as a temporary buffer when calling GadgetProductLazy. This overwrites the pre-computed CRT decomposition of the input ciphertext, resulting in badly produced lazy-pre-rotated after the first linear transformation.
Since GadgetProductHoisted is called instead when calling MultiplyByDiagMatrix, it does not happen in this case because this method does not access BuffDecompQP.

Note that this bug only happens if new lazy-pre-rotated ciphertexts need to be produced from the pre-computed CRT decomposition after the first linear transformation.

Suggested Fix

  1. Ensure all methods of the rlwe.Evaluator do not modify the buffer BuffDecompQP or document it if they do.
  2. Pre-compute all lazy-pre-rotated ciphertexts once before the loop over the linear transformations instead of updating the map after each linear transformation in EvaluateLinearTransformationsMany. The current implementation can result in unnecessary memory allocation and hoisted rotations since ciphertexts that are not needed for the next linear transformation are removed from the map, but they might be needed for the subsequent ones, and thus have to be re-generated.
@Pro7ech Pro7ech added the bug Something isn't working label Apr 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant