# LWE: error and float operations

## Background

I'm trying to make sense of the error in implementations of LWE and R-LWE. In LWE and R-LWE error is added to vectors in lattices to make it computationally infeasible to recover any meaningful data.

It was said here that using float operations in PRNG's aren't reliable enough across different environments.

According to the accepted answer on this question though, it's possible to "trivially" generate cryptographically secure, nearly uniform distributions of floating point decimals.

## Questions

1. Does the error used in LWE or R-LWE rely primarily on float operations?
2. Do float operations need to be in a finite field to be secure?
3. Before rounding occurs, are all numbers floating decimals?

## Conjectures

My assumption is that Case 1 may be likely, but Case 2 is true. This leads me to believe that only error terms are treated as floating point decimals as a way to maintain efficiency and security, but taking everything either modulo a number or modulo an ideal generates an integer. So in effect, the error taken modulo a number produces a lattice point (integer), or error taken modulo an ideal produces a lattice (finite field).

Is this an accurate assessment?

• Sampling a uniformly distributed number in the range $[0,1)$ is different from building a CSPRNG that is built on floating point operations. Being able to do the former does not imply the latter. May 3 '17 at 0:13
• This is one part of my question, yes. The rest of the question focuses on the specific operations an implementation of LWE or R-LWE requires in order to introduce error securely. May 3 '17 at 0:26
• As far as I know there isn't any floating points involved in either LWE or Ring-LWE errors. The error vector is an element in Z_q^n or Z_q[x]/(x^n+1), which has small coefficients (compared to q) when lifted to the integers. Jun 2 '17 at 18:07
• @zhenfeizhang: Well, the construct (r)LWE, as used within cryptography, doesn't involve any floating point values being exchanged. However, we still have the possibility of whether constructing the 'discrete gaussian' error vectors could be done faster by using floating point internally. I personally suspect not, but the answer isn't obvious... Jun 2 '17 at 18:33
• No, it's not obvious; in addition, performance questions like this would generally depend on the CPU architecture. Jun 3 '17 at 19:12