CKKS: Generate Scheme Param

[ZenithalHourlyRate]

In a similar style with #1379.

CKKS noise analysis is not as suggestive as BGV, which only gives the precision info, while the later can be used for determining overflow or not (correctness). So we may only support user providing the the default scale and the first mod size and we generate the parameter for them.

There are many scale-related techniques like #1169 (comment) and #1169 (comment). This PR only serves as a baseline for making the pipeline work, as it just generates the primes in an increasing order without caring the scaling factor. These management passes should be implemented later.

I put the parameter generation process in secret-to-ckks. As we are not using noise model (so not validate-noise), we do not have other pass to put it.

The CKKS SchemeParamAttr is for later integration like the Lattigo CKKS backend #1382.

[j2kun]

A lot of stuff in this file looks copied from BGV/Params.cpp. Maybe extract the prime generation to a new library in lib/Utils/NumberTheory.{h,cpp}? Or maybe a new Utils lib in lib/Parameters that includes the prime generation and the other common functions like computeDnum and computeRingDim and the HEStd_128_classic

Then it seems a large part of getConcreteSchemeParams is also copied. Because that function is so large, it's hard for me to see what differs between the BGV/CKKS versions of it. It seems like the only difference is logDefaultScale replaced plaintextModulus, and logDefaultScale is passed through while plaintextModulus is used as the first prime. It might be worth abstracting the common parts so they can be reused to make it easier to keep the two implementations in sync and also to show the differences between them more clearly. It's not clear to me what's the right way to do this, though. Is it possible to have a baseline RLWE parameter generation that is agnostic of BGV/CKKS or provides configurable options, and then modify/pass particular options to do the CKKS/BGV specific parts? Or maybe the subroutines used in both can be extracted without too much loss of clarity.

[ZenithalHourlyRate]

Now I separate them into

• RLWESecurityParams, including the HEStd_128_classic (updated to the recent "Security guidelines for implementing homomorphic encryption") and computeRingDim
• RLWEParams, for common fields and the prime generation
• {BGV/CKKS}/Params, for special field for BGV/CKKS

For now I think it is OK as we are only making the pipeline work. In the future for CKKS there might be a different prime generation process living in CKKS/Params.cpp because Openfhe has a level specific scaling factor and to maintain that Openfhe uses a carefully designed algorithm in "Approximate Homomorphic Encryption with Reduced Approximation Error"

[j2kun]

Looks great, thanks!