# Security

## Parameter Curves

To select secure cryptographic parameters for usage in Concrete, we utilize the Lattice-Estimator. In particular, we use the following workflow:

Data Acquisition

For a given value of $(n, q = 2^{64}, \sigma)$ we obtain raw data from the Lattice Estimator, which ultimately leads to a security level $\lambda$. All relevant attacks in the Lattice Estimator are considered.

Increase the value of $\sigma$, until the tuple $(n, q = 2^{64}, \sigma)$ satisfies the target level of security $\lambda_{target}$.

Repeat for several values of $n$.

Model Generation for $\lambda = \lambda_{target}$.

At this point, we have several sets of points $\{(n, q = 2^{64}, \sigma)\}$ satisfying the target level of security $\lambda_{target}$. From here, we fit a model to this raw data ($\sigma$ as a function of $n$).

Model Verification.

For each model, we perform a verification check to ensure that the values output from the function $\sigma(n)$ provide the claimed level of security, $\lambda_{target}$.

These models are then used as input for Concrete, to ensure that the parameter space explored by the compiler attains the required security level. Note that we consider the `RC.BDGL16`

lattice reduction cost model within the Lattice Estimator. Therefore, when computing our security estimates, we use the call `LWE.estimate(params, red_cost_model = RC.BDGL16)`

on the input parameter set `params`

.

The cryptographic parameters are chosen considering the IND-CPA security model, and are selected with a bootstrapping failure probability fixed by the user. In particular, it is assumed that the results of decrypted computations are not shared by the secret key owner with any third parties, as such an action can lead to leakage of the secret encryption key. If you are designing an application where decryptions must be shared, you will need to craft custom encryption parameters which are chosen in consideration of the IND-CPA^D security model [1].

[1] Li, Baiyu, et al. “Securing approximate homomorphic encryption using differential privacy.” Annual International Cryptology Conference. Cham: Springer Nature Switzerland, 2022. https://eprint.iacr.org/2022/816.pdf

## Usage

To generate the raw data from the lattice estimator, use::

by default, this script will generate parameter curves for {80, 112, 128, 192} bits of security, using $log_2(q) = 64$.

To compare the current curves with the output of the lattice estimator, use:

this will compare the four curves generated above against the output of the version of the lattice estimator found in the third_party folder.

To generate the associated cpp and rust code, use::

further advanced options can be found inside the Makefile.

## Example

To look at the raw data gathered in step 1., we can look in the sage-object folder. These objects can be loaded in the following way using SageMath:

entries are tuples of the form: $(n, log_2(q), log_2(\sigma), \lambda)$. We can view individual entries via::

To view the interpolated curves we load the `verified_curves.sobj`

object inside the sage-object folder.

This object is a tuple containing the information required for the four security curves ({80, 112, 128, 192} bits of security). Looking at one of the entries:

Here we can see the linear model parameters $(a = -0.026599462343105267, b = 2.981543184145991)$ along with the security level 128. This linear model can be used to generate secure parameters in the following way: for $q = 2^{64}$, if we have an LWE dimension of $n = 1536$, then the required noise size is:

$\sigma = a * n + b = -37.85$

This value corresponds to the logarithm of the relative error size. Using the parameter set $(n, log(q), \sigma = 2^{64 - 37.85})$ in the Lattice Estimator confirms a 128-bit security level.

Last updated