Towards Practical GGM-Based PRF from (Module-)Learning-with-Rounding

Abstract

We investigate the efficiency of a $\mathsf {(module}\text {-}\mathsf {)LWR}$-based PRF built using the GGM design. Our construction enjoys the security proof of the GGM construction and the $\mathsf {(module}\text {-}\mathsf {)LWR}$ hardness assumption which is believed to be post-quantum secure. We propose GGM-based PRFs from PRGs with larger ratio of output to input. This reduces the number of PRG invocations which improves the PRF performance and reduces the security loss in the GGM security reduction. Our construction bridges the gap between practical and provably secure PRFs. We demonstrate the efficiency of our construction by providing parameters achieving at least 128-bit post-quantum security and optimized implementations utilizing AVX2 vector instructions. Our PRF requires, on average, only 39.4 cycles per output byte.

This work was supported in part by BPI-France in the context of the national project RISQ (P141580), by the European Union PROMETHEUS project (Horizon 2020 Research and Innovation Program, grant 780701).

A LWR-based PRG

This Appendix explains our PRF construction based on the $\mathsf {LWR}$ hardness assumption. Note that, in general, this construction is very much similar to the one in the main article which is based on the $\mathsf {module}\text {-}\mathsf {LWR}$ hardness assumption. In order not to repeat the same details, we only highlight the differences between the two constructions.

1.1 A.1 Construction

Construction 2 outlines our $\mathsf {LWR}$-variant PRF. Recall that the PRF takes two inputs, namely, a key k and a string x of length $\ell$, and outputs a pseudorandom string z. The matrix $\mathbf A$ is a public parameter. Similar to the $\mathsf {module}\text {-}\mathsf {LWR}$ construction, the $\mathsf {LWR}$ construction is also divided into three parts: pre-computation, main loop, and outputting. Below, we emphasize the differences between the two constructions parts by parts.

Pre-computation. There is no differences in the way we generate randomness, i.e., $\mathsf {Random}(k)$, and reformat, i.e., $\mathsf {Reformat}(\mathbf{t})$. Note however that $\mathbf{s} \in \mathbb {Z}_{\log B}^n$ (instead of $\mathcal {R}_{\log B}^{n'}$).

The reasons for having $\mathsf {Random}(k)$ are also the same, namely, in case the input k is not random or does not have the preferred length. If this is not the case, then $\mathsf {Random}(k)$ can be skipped and directly proceed to $\mathsf {Reformat}(\mathbf{t})$.

Main Loop. Since the underlying PRG is now constructed from $\mathsf {LWR}$, we need to change polynomial multiplications to integer multiplications. Nevertheless, a similar optimization for computing $\mathbf{As}$ is still applied, i.e., each iteration we compute vector-vector multiplications instead of a matrix-vector multiplication. For the $\mathsf {LWR}$ case, we need to multiply only ${m}/{\omega }$ rows of the matrix $\mathbf A$ to the vector $\mathbf s$. This time, $m/\omega$ is certainly more than one. We added an inner loop (line 5–8 in Construction 2) to iterate multiplying those rows. Once we multiply all those $m/\omega$ rows and before moving the next iteration of the outer loop, we call $\mathsf {Reformat}(\mathbf{t})$ to extract bits from $\mathbf t$ and assign to $\mathbf s$. Note that $\mathbf t$ contains $m/\omega$ elements.

Outputting. This part remains the same, namely, we perform the entire matrix-vector multiplication to increase the output length. Then we change the result into the desire format and output it.

1.2 A.2 Implementation

Two major differences between the $\mathsf {module}\text {-}\mathsf {LWR}$ and the $\mathsf {LWR}$ implementations are multiplication algorithm and parameter set. In what follows, we explain how we handle multiplications when we cannot use fast polynomial multiplication algorithms, and then we state possible $\mathsf {LWR}$ parameter sets.

Multiplication. Since we use the plain $\mathsf {LWR}$, i.e., having neither ring nor module additional structure, our multiplications are simply integer vector multiplications which can be implemented efficiently. Another advantage of using integers instead of polynomials is that we do not need to perform polynomial reductions.

Assume that we can perform w pairs of integer vector multiplications. To multiply row i of matrix $\mathbf A$ with vector $\mathbf s$, we load the first w elements of $\mathbf{A}_i$ and the first w elements of $\mathbf s$, then we perform integer vector-vector multiplication. After that, we load the next w element of $\mathbf{A}_i$ and the next w elements of $\mathbf s$, and again we perform another integer vector-vector multiplication. We repeat these steps until we multiply the entire row of $\mathbf A$ with $\mathbf s$. Since we always multiply $A_{i,j}$ with $s_j$, i.e, index j of $\mathbf{A}_i$ with index j of $\mathbf s$, this means that data are aligned in correct slots and no permutation needed. Therefore, this multiplication step works very well with vectorization.

Next step is to sum all the results of the integer vector-vector multiplications into a single integer. Unlike the multiplication step, this addition step requires permutations because we want to add data which contain in the same vector. To do so, we make use of the instruction vphaddd to perform horizontally additions and the instruction vperm2i128 to perform permutations.

Parameters. We recall parameters in our construction. Let q be a modulus and p be a rounding parameter such that $q > p$ and $\log q = \log p + \log B$ where q, p, and B are power of two. Let $\mathbf {A} \in \mathbb {Z}_q^{m \times n}$ be a random public matrix. Let $\mathbf {s} \in \mathbb {Z}_{\log B}^n$ be a small secret vector. Similar to the $\mathsf {module}\text {-}\mathsf {LWR}$ variant, we want to set these parameters such that they satisfy the expansion-rate-$\omega$ output length requirement and achieve at least 128-bit security for the underlying $\mathsf {LWR}$ problem.

Recall the length condition. In our $\mathsf {LWR}$-based PRG, the input is the vector $\mathbf s$ and the output is the rounded vector $\lfloor \mathbf {As} \rfloor _p$. That is, we have the output size $m \cdot \log {p}$ and the input size $n \cdot (\log B)$. Therefore, the equation we consider is:

$$\begin{aligned} m \cdot \log {p}&\ge \omega \cdot (n \cdot (\log B)) \\ m \cdot (\log {q} - (\log B))&\ge \omega \cdot (n \cdot (\log B)). \end{aligned}$$

Similar remarks of requiring $\omega \ge 2$ and larger the $\omega$ shallower the tree also apply to the $\mathsf {LWR}$ variant.

Now, we consider the security of the underlying $\mathsf {LWR}$ problem. We modified Kyber’s script [11] to suit for our security estimation. Two main modifications are: (1) setting the ring dimension to 1 (because we use the plain $\mathsf {LWR}$); and (2) using a uniform distribution instead of a binomial one. The conditions in which we search for good parameter sets are as follows:

• $q = 2^{16}$, fixed

• $\log B \in \{ 1,2,3,4 \}$

• n multiple of 32 in range [640, 800]

• m among 4, 8, 16 and 32 multiples of $\lceil n \cdot \log B / \log p \rceil$

Table 4 shows possible parameter sets for the $\mathsf {LWR}$ construction. To select which parameters to implement, we prioritize the runtime and choose the last row, namely, $m=1840,n=800,\log B = 2$ which gives $m/\omega = 115$, the tree’s depth = 32, and the estimated security of 131.

Table 4. Good parameters achieving at least 128-bit $\mathsf {LWR}$ security and the expansion-rate-$\omega$ condition