Library feature request: Setting moduli chain directly

Library Questions
1

Hello.

Somewhat continuing the discussion in this thread, it would be helpful for researchers/benchmarking if the moduli chain for Q and P could be specified directly.

Thus I am posting this feature request.

2

Thanks. I had discussed this issue with some members of the OpenFHE community, e.g., with @zenithal. We could theoretically expose something like this. The main challenge is related to noise estimation (in BGV and BFV) and rescaling in CKKS. In other words, enabling the use of custom primes automatically invalidates various noise estimation procedures and safeguards OpenFHE includes. For an illustration what this might lead to, please look at ePrint 2024/203. In other words, if we provide such an option, the developer would be fully responsible for the choice of primes, correctness of the protocol, and so on.

Happy to have a discussion on this.

3

Thanks for the tag. Same opinion here. I originally thought we may alter the parameter at will, but then I realized customizing parameter will have security implications.

My second thought is to have a compile-time flag so that researchers would be able to take the responsibility, but then for library developers that would mean a whole bunch of code path/API that is hard to ensure correctness and maintain, and making them into official product would be hard.

I understand that this topic would be recurring in this forum and from my limited browsing I’ve seen quite some researchers asking questions about setting parameters in all aspects. Maybe we can maintain a community patch that adds the low-level API with the warning that it is only for research, so that both researchers and library developers will not carry too much burden. After all, researchers will always spend some time to find a way to control the low-level stuff.

4

Also supporting the idea of having some sort of flag that can be used.

openFHE already allows running applications that are not secure by setting HEStd_NotSet as done here. This is done for testing/debugging purposes of course.

Perhaps this idea can be extended and there can be an explicit setModuliExplicit method. This would fail if any of the other parameters it conflicts with are set. I do think if this method is well documented and warned against, similar to using HEStd_NotSet, this method would only be used by the intended audience.