As mentioned in the comments, there are generic techniques to do this using "gadget RLWE".
They're not particularly performant in this setting though (if you wanted to compute $n$ FMAs they would be fine, but to compute 1 FMA they implicitly compute $n$, so everything is an $O(n)$ factor worse, where $\log_2n\geq 10$, probably is closer to $13$ tbh).
For this reason, I've opted for the following "direct" construction.
It has the "downside" that decryption is not standard RLWE-based decryption, and instead it is standard RLWE-based decryption, followed by client-side post-processing.
This is to say that the final ciphertext does not directly encrypt $a\cdot b+c\bmod p$, and instead encrypts a value that may be post-processed to this quantity.
RLWE-based Homomorphic Encryption
Fix $n = 2^k$ and a prime ciphertext modulus $q$. Let $R_q := \mathbb{Z}_q[x]/(x^n+1)$ be the ring of polynomials with component-wise addition + and polynomial multiplication $\ast$. A standard RLWE-based private-key encryption scheme can be defined as follows.
Encryption and Decryption
Encryption of a plaintext polynomial $m(x) \in R_t$ (where $t < q$ is the plaintext modulus) is performed by the randomized function:
$$\mathsf{Enc}_{s(x)}(m(x)) := [a(x), a(x)\ast s(x) + e(x) + \Delta m(x)] \in R_q^2$$
where:
- $s(x) \in R_q$ is the secret key, with coefficients chosen from a "short" error distribution $\chi$ (e.g., a discrete Gaussian).
- $a(x) \gets R_q$ is a uniformly random polynomial.
- $e(x) \gets \chi$ is a fresh error polynomial.
- $\Delta = \lfloor q/t \rfloor$ is a scaling factor used to separate the message from the noise.
Decryption works by canceling the $a(x)\ast s(x)$ term and rescaling:
$$\mathsf{Dec}_{s(x)}([c_0,c_1]) = \lfloor (c_1-c_0\ast s(x))/\Delta\rceil = m(x) + \lfloor e(x)/ \Delta\rceil$$
Provided the error term is small enough such that $\lfloor e(x)/\Delta\rceil = 0$ ($\lVert e(x)\rVert_\infty < \Delta/2$ suffices for this), decryption is correct.
Homomorphic Properties
This scheme is additively homomorphic and supports multiplication by a plaintext polynomial $c(x)$.
Addition adds the noise of the underlying ciphertext.
Multiplication by $c(x)$ multiplies the noise by $c(x)$.
So, one cannot multiply by "large" $c(x)$ without possibly trigger decryption failures.
The Challenge: Multiplication by Large Integers
The native homomorphic multiplication is insufficient for our goal of computing $a \cdot b + c$ where $a,b,c$ are large 128-bit integers, due to high noise growth.
A generic solution involves "gadget" decompositions, where a large integer is decomposed into a vector of smaller, bounded limbs. This works, and in many cases it is rather lightweight (you increase ciphertext sizes by something like $\times 10$ generally, and do not yet need large amounts of encrypted key material, the normal "hard" part of FHE).
The main issue here is that if we supported $n$ FMAs mod $p$, the ciphertext modulus $q$ would be $\geq 2^{128}$.
So, we would have to set $n$ larger for security, and end up with pretty large ciphertexts, just to not use $n-1$ of our (implicitly computed) FMAs.
A Direct Construction via Kronecker Substitution
A more performant approach is to reduce the integer arithmetic to polynomial arithmetic. This avoids both the large coefficients of the naive approach, and requiring to support 128-bit plaintext arithmetic (which is still an issue for the gadget-based approach).
The Principle
An integer $A = \sum_{i=0}^{d-1} a_i 2^i$ can be mapped to a polynomial $P_A(x) := \sum_{i=0}^{d-1} a_i x^i$. The integer product $A \cdot B$ corresponds to the evaluation of the polynomial product: $(P_A \ast P_B)(2)$. Note that this holds for for unreduced polynomial multiplication. As p is only 128 bit, our polynomial product will be less than 256 bit, so we will not trigger polynomial reduction. But, for other applications of this trick (say for 1024-bit prime $p$), you might have to zero-pad your messages so ensure you don’t wrap around.
Our strategy is to homomorphically compute the polynomial $P_D(x) := P_A(x) \ast P_B(x) + P_C(x)$ using a public-key version of the RLWE scheme. The client can then decrypt this polynomial, evaluate it at $x=2$, and perform the final modular reduction in plaintext.
The Protocol
The following is the standard public-key variant of RLWE, where $\mathsf{pk} := [a_{pk}(x), a_{pk}(x)\ast s(x) + e_{pk}(x)]$.
Parameters: To support the computation, fix parameters that balance efficiency, correctness, and security.
- $n=1024$
- Plaintext modulus $t$: A 12-bit prime (e.g., $t=4091$), which should be sufficient for the coefficients of the product polynomial (which are bounded by 128).
- Ciphertext modulus $q$: A ~29-bit prime, which provides an adequate noise budget for the depth-1 computation while satisfying 128-bit security requirements for $n=1024$.
Client-side: The client encodes its private 128-bit integers $a$ and $c$ into bit-coefficient polynomials $P_a(x)$ and $P_c(x)$. It encrypts each into a single ciphertext and sends them to the server:
$$\mathsf{ct}_A := \mathsf{Enc}_{pk}(P_a(x)), \quad \mathsf{ct}_C := \mathsf{Enc}_{pk}(P_c(x))$$
Server-side: The server encodes the public integer $b$ into its polynomial $P_b(x)$. It then performs one homomorphic multiplication and one addition:
$$\mathsf{ct}_D := (\mathsf{ct}_A \ast P_b(x)) + \mathsf{ct}_C$$
The result $\mathsf{ct}_D$ is returned to the client.
Client-side Reconstruction: The client decrypts to get the polynomial $P_D(x) := \mathsf{Dec}_{sk}(\mathsf{ct}_D)$. It then uses multi-precision arithmetic to compute the integer $D := P_D(2)$ and the final result $\text{Result} := D \pmod p$.
Efficiency and Final Remarks
This scheme is highly performant. The main server-side workload is a single plaintext-ciphertext multiplication, which is efficient ($O(n \log n)$ using NTTs. Likely the client can send everything in the NTT domain already to make it more efficient) as q is a native machine-word integer. The heaviest step is likely the final reconstruction on the client side, which is still very fast.
To speak qualitatively, it would not surprise me if this scheme was faster than lattice-based PKE (which aims for IND-CCA2 security, and has to spend a significant percentage of their time in things like hashing, which the above IND-CPA secure scheme doesn't have to do).
With $n=1024$ and $q \approx 2^{29}$, the total bandwidth is on the order of ~21 KB (14 KB upload, 7 KB download). Bandwidth is typically the "worst" parameter of lattice-based schemes, and while it can be optimized some (even here), it's typically large compared to other options available in cryptography.
Note that this ciphertext does not directly decrypt to the final integer value and thus cannot be used in further homomorphic operations as if it were a standard encryption of $a\cdot b+c$. Whether this is an issue depends on the specific application.
