> For the complete documentation index, see [llms.txt](https://docs.zama.org/tfhe-rs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zama.org/tfhe-rs/fhe-computation/compute/parameters.md).

# Parameters

This document explains how the choice of cryptographic parameters impacts both the security and efficiency of FHE algorithms. The chosen parameters determine the error probability (sometimes referred to failure probability) and overall performance of computations using fully homomorphic encryption. This error probability is due to the noisy nature of FHE computations (see [here](/tfhe-rs/get-started/security-and-cryptography.md) for more details about the encryption process).

All parameter sets provide at least 128-bits of security according to the [Lattice-Estimator](https://github.com/malb/lattice-estimator).

## Default parameters

Currently, the default parameters use blocks that contain 2 bits of message and 2 bits of carry - a tweaked uniform (TUniform, defined [here](/tfhe-rs/get-started/security-and-cryptography.md#noise)) noise distribution, and have a bootstrapping failure probability $$p\_{error} \le 2^{-128}$$. These are particularly suitable for applications that need to be secure in the IND-CPA^D model (see [here](/tfhe-rs/get-started/security-and-cryptography.md#security) for more details).

When using the high-level API of **TFHE-rs**, you can create a key pair using the default recommended set of parameters. For example:

```rust
use tfhe::{ConfigBuilder, generate_keys};

fn main() {
    let config = ConfigBuilder::default().build();

    // Client-side
    let (client_key, server_key) = generate_keys(config);

    // encryption and FHE operations
}
```

{% hint style="info" %}
These default parameters may be updated in future releases of **TFHE-rs**, potentially causing incompatibilities between versions. For production systems, it is therefore recommended to specify a fixed parameter set.
{% endhint %}

## Parameters versioning and naming scheme

Parameter sets are versioned for backward compatibility. This means that each set of parameters can be tied to a specific version of **TFHE-rs**, so that they remain unchanged and compatible after an upgrade.

All parameter sets are stored as variables inside the `tfhe::shortint::parameters` module, with submodules named after the versions of **TFHE-rs** in which these parameters were added. For example, parameters added in **TFHE-rs** v1.0 can be found inside `tfhe::shortint::parameters::v1_0`.

The naming convention of these parameters indicates their capabilities. Taking `tfhe::parameters::v1_0::V1_0_PARAM_MESSAGE_2_CARRY_2_KS_PBS_TUNIFORM_2M128` as an example:

* `V1_0`: these parameters were introduced in **TFHE-rs** v1.0
* `MESSAGE_2`: LWE blocks include 2 bits of message
* `CARRY_2`: LWE blocks include 2 bits of carry
* `KS_PBS`: the keyswitch is computed before the bootstrap
* `TUNIFORM`: the tweaked uniform noise distribution is used
* `2M128`: the probability of failure for the bootstrap is $$2^{-128}$$

For convenience, aliases are provided for the most used sets of parameters and stored in the module `tfhe::shortint::parameters::aliases`. Note, however, that these parameters are not stable over time and are always updated to the latest **TFHE-rs** version. For this reason, they should only be used for prototyping and are not suitable for production use cases.

## How to choose the parameter sets

Since tfhe-rs 1.5, there is a `MetaParameterFinder` which enables to search for suitable parameters given some choice of constraints.

### Note

It is recommended to serialize the parameters found if you plan on re-using them, as the heuristics used by the `MetaParametersFinder` are susceptible to change across TFHE-rs versions

```rust
use tfhe::shortint::parameters::{MetaParametersFinder, Log2PFail, Constraint, Version, Backend, NoiseDistributionChoice, NoiseDistributionKind};
use tfhe::{FheUint32, CompressedCiphertextListBuilder, generate_keys, set_server_key};
use tfhe::prelude::*;

fn main() {
    // Create a finder with minimal constraints
    let finder = MetaParametersFinder::new(
        // We want parameters that have a failure probability `pfail` that is: pfail <= 2^-64
        Constraint::LessThanOrEqual(Log2PFail(-64.0)),
        // We want parameters meant for CPU execution
        Backend::Cpu
    );

    let parameters = finder
        .find()
        .expect("Could not find suitable parameters");

    // It is recommended to serialize the parameters found if you plan on re-using them
    let mut serialized_params = vec![];
    tfhe::safe_serialization::safe_serialize(&parameters, &mut serialized_params, 1 << 10).unwrap();
    

    let (client_key, server_key) = generate_keys(parameters);

    // We can add other constraints:
    let finder = finder
        // Find parameters from the 1.4 version
        // By default, the finder looks in the current tfhe-rs version
        .with_version(Version(1, 4))
        // We want to use compression (CompressedCiphertextList)
        // So we require parameters that support it
        .with_compression(true) 
        .with_noise_distribution(
            // Allow any noise distribution that is not TUniform
            NoiseDistributionChoice::allow_all()
            .deny(NoiseDistributionKind::TUniform)
        );


    let parameters = finder
        .find()
        .expect("Could not find suitable parameters");

    let (client_key, server_key) = generate_keys(parameters);

    let a = FheUint32::encrypt(1337u32, &client_key);
    set_server_key(server_key);
    let compressed_list = CompressedCiphertextListBuilder::new()
        .push(a)
        .build()
        .unwrap();
}
```

You can override the default parameters with the `with_custom_parameters(block_parameters)` method of the `Config` object. For example, to use a Gaussian distribution instead of the TUniform one, you can modify your configuration as follows:

```rust
use tfhe::{ConfigBuilder, generate_keys};
use tfhe::shortint::parameters::current_params::V1_8_PARAM_MESSAGE_2_CARRY_2_KS_PBS_GAUSSIAN_2M128;

fn main() {
    let config =
        ConfigBuilder::with_custom_parameters(V1_8_PARAM_MESSAGE_2_CARRY_2_KS_PBS_GAUSSIAN_2M128)
            .build();

    // Client-side
    let (client_key, server_key) = generate_keys(config);

    // encryption and FHE operations
}

```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.zama.org/tfhe-rs/fhe-computation/compute/parameters.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.