Request for Bug Confirmation in Issues

Hello,

I hope this message finds you well. During the past two weeks, I have raised several issues on GitHub as follows, but I have not received any response.

I understand that you may be busy, but I wanted to kindly inquire if there has been any progress or if there is any additional information needed from my end to confirm the bugs. It is relatively easy to reproduce these bugs using the examples provided by OpenFHE.

Due to the imminent submission of the preliminary draft of my graduation thesis, I need bug confirmations to validate effectiveness of my work in software testing.

Thanks for your attention to this matter and the contributions you have made to OpenFHE. :grinning:

Hi @ailanxier Thank you for submitting the issues. We are more active in the OpenFHE discourse forum and typically create issues ourselves when the bugs are confirmed. Moreover, the past week has been crazier than usual. I saw your issues yesterday and am planning to look at them (and assign them to the next bugfix version v1.0.4 if needed) in the next few days.

1 Like

I see. Thank you for your response and your diligent contribution! :+1:

Hi @ailanxier I’ve examined all issues and assigned 5 of them to the next bugfix release (v1.0.4). I closed one of them as it is already covered by another issue for v1.0.4.

Hi @ypolyakov Thanks for your quick confirmation. I still have some points of confusion in issue#364. Could I understand that, in the CKKS scheme, even if the decryption process can be completed without any error messages, there is no universal method to verify whether the results are correct within a certain margin of error? I have met the same issue in the BGV scheme as well, where evident errors occur in the results under certain unreasonable parameter settings, yet the decryption process is still successful.

Initially, I had expected an exception to be thrown indicating decryption failure. But due to the limitation of “the underlying messages are encrypted”, is it currently not possible to capture such exceptions?

Any checks like this would have to be written by the application developer, e.g., using a reference implementation in the clear. These logical checks require understanding the context of the application, acceptable margin of error, etc. For instance, the user can select a plaintext modulus in BGV that is not large enough. When integers are added, an overflow can occur, resulting in incorrect results. The library does not know that this result is incorrect.