Add RLWEParameters and reduction to LWE

[j2kun]

Fixes #48

Hi Martin,

I added the simple reduction from RLWE to LWE in an RLWEParameters class. I wanted to get early feedback from you on aligning with your contributing guidelines before, e.g., adding constants for specific RLWE parameter instances in the literature (or adding tests, looks like it's all doctests?).

In particular, I ran into a roadblock when generating the docs (to see how my formatted matrices look and tweak them), and I ran into this error:

WARNING: [autosummary] failed to import estimator.rlwe_parameters.
Possible hints:
* ImportError: no module named estimator
* TypeError: '<' not supported between instances of 'int' and 'MagicMock'
* KeyError: 'estimator'

I think this is happening because of the MagicMock in docs/conf.py, which is being compared to an int in __post_init__; however, I don't see how this is not causing the same problem in lwe_parameters.py. I'm not particularly familiar with sphinx (why would it be running this code to run into the type error instead of statically analyzing it?), but I also noticed that sphinx-book-theme is preventing sphinx version >= 5, which I imagine might have bug fixes that would avoid this: executablebooks/sphinx-book-theme#592.

Open to any suggestions you have to fix this!

[j2kun]

Some other questions I was unsure about:

• Wouldn't a reduction from RLWE to LWE require that the resulting LWE samples are independent? In this case, the samples that arise from the RLWE instance are correlated, no?
• Do you have any clue how this reduction applies for the version of RLWE in which more than one polynomial sample is drawn? I.e., the sample is (p_1, p_2, ..., p_n) and the secret is similar, and the encryption operation is a dot product of the two vectors of polynomials? I know of at least one case (Zama's boolean TFHE implementation) that suggests to use length-2 polynomial vectors, and I have empirically observed a significant performance improvement from doing so, because it should allow me to halve the degree of the RLWE polynomial.

[j2kun]

On further thought, for RLWE with vectors of polynomials, wouldn't you just stack the dimension-1 reduction horizontally, and then repeat the secret key vector dim many times? Somehow that seems like is will violate something about the distributions, because the secret key is no longer uniform...

[j2kun]

Also, on the doc generation questions, it looks like the autodoc generation is failing in the github action as well, though it has an import error for all the modules, not just my new one...

[malb]

Hi Jeremy, let's talk about the mathematics/cryptography separately from Python issues. I don't think the PR works as is. Ring-LWE is not only defined for power-of-two ring dimensions. It is defined for, at least, any cyclotomic ring, e.g. sage: CyclotomicField(127).polynomial(). On some level, there is then no translation: parameters just translate one to one and I don't think a new class is needed. If we wanted to be precise, there would be differences (the spaces where elements live, cf. canonical embeddings) but those don't (seem to!) matter for security estimates. So I'm afraid adding something like this would only add confusion.

[malb]

If we're given samples (a_i, a_i * s + e_i) we can consider (A_i, A_i*s + e_i) where A_i = rot(a_i) the rotational matrix of the ring element a_i. So each RLWE sample simply gives you n LWE samples. Yes, these are correlated, but as far as we know this doesn't seem to matter to algorithms.

[malb]

I'm at a loss on the Sphinx question, though.

[j2kun]

My intention with this PR was mainly to document the provenance of the LWE parameter sets coming from RLWE instantiations, since those are not clearly explained in the cited papers. For example, the TFHE1024 set marks n=1024 in LWE parameters, but the paper it comes from uses RLWE and is at best vague about the relationship. This is all they have to say:

And then in the table cited by lattice-estimator, the authors silently switch from N=1024, k=1 (RLWE with only one sample polynomial) to n=1024 and claim security. I recall other parameter sets that used N=512, k=2 (512-degree with two sampled polynomials), where it seems the product of those two parameters gives you the corresponding LWE parameter set. For me, it would be clearer to see, e.g., RLWEParameters(N=512, k=2).as_lwe_params() and know that there is a conversion happening, albeit a very simple one, than to see LweParameters(n=1024) with no further explanation. In addition, if "RLWE" includes the "generalized" RLWE in the CGGI line of work, then the N=512, k=2 example shows it's not 1-1.

I have also heard that, if N is not a power of 2 (and/or the secret is not binary) then the RLWE distributions don't reduce to
LWE neatly (or at all?), so in that case it seems lattice-estimator can't be applied. The "guards" via raised ValueErrors would serve as documentation of that folk lore. In addition to what you mentioned, that these reductions are applicable mainly because we don't have any stronger attacks that rely on the ring structure (and the correlation of samples).

Happy to accept the final call and close the PR if you're still unconvinced.

[malb]

I suspect by N=512, k=2 people mean M-LWE with rank k=2 and ring dimension N=512, i.e. overall secret dimension 1024? It is true that when N is not a power of two you may have to worry about the distortion of the noise when considering it in the "coefficient embedding". However, in the "canonical embedding" this issue doesn't exist.

I'm afraid I still think this PR would rather add confusion than make things more accessible.