Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 11 additions & 12 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,13 +9,13 @@ Here we will not try to quantify what Hamming weight corresponds to a sparse sec
There are already a few different variations of sparse secrets, and many more could be imagined.

We start by describing traditional (non-sparse) secret keys.
There are four main random distributions used for coefficients of secret keys: uniform binary, uniform ternary, discretized Gaussian and uniform modulo an integer q parametrizing the public key space.
It is natural to design a secret key of dimension n containing h entries equal to 1 (resp. 1 or -1), with the remaining values being 0, and calling it a sparse binary secret (resp. sparse ternary secret) if h is sufficiently small, or calling it fixed-Hamming-weight binary secret (resp. fixed-Hamming-weight ternary secret).
One could define a similar secret with the uniform mod-q distribution instead.
A common choice of Hamming weight in the literature is h = 64, however, a variety of Hamming weights are considered in practice from 32 up to 1024. As mentioned above, there are many variations of sparse secrets, for instance:
There are four main random distributions used for coefficients of secret keys: uniform binary, uniform ternary, discretized Gaussian and uniform modulo an integer $q$ parametrizing the public key space.
It is natural to design a secret key of dimension $n$ containing $h$ entries equal to 1 (resp. 1 or -1), with the remaining values being 0, and calling it a sparse binary secret (resp. sparse ternary secret) if $h$ is sufficiently small, or calling it fixed-Hamming-weight binary secret (resp. fixed-Hamming-weight ternary secret).
One could define a similar secret with the uniform $\bmod q$ distribution instead.
A common choice of Hamming weight in the literature is $h = 64$, however, a variety of Hamming weights are considered in practice from 32 up to 1024. As mentioned above, there are many variations of sparse secrets, for instance:
- a sparse ternary secret could also publicly provide the number of 1's and -1's it holds;
- a sparse secret could allow any Hamming weight below the threshold h;
- a secret where each element is sampled from an integer Gaussian with mean 0 and sigma = 0.01 could be defined as a sparse secret, even though the Hamming weight becomes a random variable.
- a sparse secret could allow any Hamming weight below the threshold $h$;
- a secret where each element is sampled from an integer Gaussian with mean 0 and $\sigma = 0.01$ could be defined as a sparse secret, even though the Hamming weight becomes a random variable.

## Goals

Expand All @@ -30,7 +30,7 @@ The costs of known attacks can also be revised (upwards and downwards) thanks to

Attacks we are already aware of and may be competitive either need to be better studied and discarded, or incorporated into existing tools for use in parameter selection.
This means that **existing tools may not give a completely accurate estimate of security**.
Existing tools may also take a **long time to run**.
Existing tools may also take a **long time to run** or simply may not terminate for sufficiently large parameters.
In order to mitigate against confusion caused by long running time, we report running time for the tables we provide.
We hope this gives users an idea of how long they can expect parameter generation to take.

Expand All @@ -41,8 +41,7 @@ We hope this gives users an idea of how long they can expect parameter generatio
Disclaimer: These tools either do not incorporate sparse secrets, or do so to a limited extent (only some attacks).

- [Lattice estimator](https://github.com/malb/lattice-estimator), the most commonly used tool.
- OpenFHE has an [adapted version](https://github.com/openfheorg/openfhe-lattice-estimator) of the lattice estimator for parameter generation of specific
FHE schemes.
- OpenFHE has an [adapted version](https://github.com/openfheorg/openfhe-lattice-estimator) of the lattice estimator for parameter generation of specific FHE schemes.
- [TFHE parameter selection tool](https://eprint.iacr.org/2022/704) which gives optimised parameter sets for TFHE as tables in the paper, and is implemented in the [tfhe-rs library](https://github.com/zama-ai/tfhe-rs).
- Tool from the TII FHE team which gives [specific formulas](https://eprint.iacr.org/2024/1895.pdf) for estimating security.
- Security Guidelines for Implementing Homomorphic Encryption, with [tables](https://eprint.iacr.org/2024/463) and also [code](https://github.com/gong-cr/FHE-Security-Guidelines).
Expand Down Expand Up @@ -104,8 +103,8 @@ Note: In this table, parameter sets are listed in order of increasing Hamming we
#### Notations
- skdim: dimension of the secret key of the LWE/RLWE instance (corresponding to the size of the polynomials in RLWE), earlier called n in this page
- σ: standard deviation of the noise at secret key encryption time
- log2(ctmod): log2 of the (maximal) ciphertext modulus (for instance ctmod often corresponds to Q, or to PQ in the CKKS context)
- HW: Hamming weight of the secret key, earlier called h in this page
- log2(ctmod): $log_{2}$ of the (maximal) ciphertext modulus (for instance ctmod often corresponds to $Q$, or to $PQ$ in the CKKS context)
- HW: Hamming weight of the secret key, earlier called $h$ in this page

#### Instantiation with two parameter sets at once

Expand Down Expand Up @@ -151,7 +150,7 @@ There is a general **rule of thumb** that can be used to have an intuition on th
- decreasing HW decreases security,
- increasing HW increases security.

This rule of thumb was used to estimate the security of the parameter set ID 8 (DESILO FHE). The lattice estimator was not able to provide a proper security estimate for this parameter set, however it was able to estimate the parameter set ID 10. In the case of parameter set ID 10, the lattice estimator gave an estimate for security of 232.52 bits with the attack _bdd_mitm_hybrid_. It is then possible to use the rule of thumb on N to observe that the security of ID 8 is greater or equal to that of ID 10.
This rule of thumb was used to estimate the security of the parameter set ID 8 (DESILO FHE). The lattice estimator was not able to provide a proper security estimate for this parameter set, however it was able to estimate the parameter set ID 10. In the case of parameter set ID 10, the lattice estimator gave an estimate for security of 232.52 bits with the attack `_bdd_mitm_hybrid_`. It is then possible to use the rule of thumb on N to observe that the security of ID 8 is greater or equal to that of ID 10.


### Notes
Expand Down