Serialization/deserialization

This document explains the serialization and deserialization features that are useful to send data to a server to perform the computations.

Safe serialization/deserialization

When dealing with sensitive types, it's important to implement safe serialization and safe deserialization functions to prevent runtime errors and enhance security. TFHE-rs provide easy to use functions for this purpose, such as safe_serialize, safe_deserialize and safe_deserialize_conformant.

Here is a basic example on how to use it:

// main.rs

use tfhe::safe_serialization::{safe_deserialize_conformant, safe_serialize};
use tfhe::shortint::parameters::PARAM_MESSAGE_2_CARRY_2_KS_PBS;
use tfhe::ServerKey;
use tfhe::{generate_keys, ConfigBuilder};

fn main() {
    let params_1 = PARAM_MESSAGE_2_CARRY_2_KS_PBS;

    let config = ConfigBuilder::with_custom_parameters(params_1).build();

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

    let mut buffer = vec![];

    // The last argument is the max allowed size for the serialized buffer
    safe_serialize(&server_key, &mut buffer, 1 << 30).unwrap();

    let _server_key_deser: ServerKey =
        safe_deserialize_conformant(buffer.as_slice(), 1 << 30, &config.into()).unwrap();
}

The safe deserialization must take the output of a safe-serialization as input. During the process, the following validation occurs:

  • Type match: deserializing type A from a serialized type B raises an error indicating "On deserialization, expected type A, got type B".

  • Version compatibility: data serialized in previous versions of TFHE-rs are automatically upgraded to the latest version using the data versioning feature.

  • Parameter compatibility: deserializing an object of type A with one set of crypto parameters from an object of type A with another set of crypto parameters raises an error indicating "Deserialized object of type A not conformant with given parameter set"

    • If both parameter sets have the same LWE dimension for ciphertexts, a ciphertext from param 1 may not fail this deserialization check with param 2.

    • This check can't distinguish ciphertexts/server keys from independent client keys with the same parameters.

    • This check is meant to prevent runtime errors in server homomorphic operations by checking that server keys and ciphertexts are compatible with the same parameter set.

    • You can use the standalone is_conformant method to check parameter compatibility. Besides, the safe_deserialize_conformant function includes the parameter compatibility check, and the safe_deserialize function does not include the compatibility check.

  • Size limit: both serialization and deserialization processes expect a size limit (measured in bytes) for the serialized data:

    • On serialization, an error is raised if the serialized output exceeds the specific limit.

    • On deserialization, an error is raised if the serialized input exceeds the specific limit.

This feature aims to gracefully return an error in case of an attacker trying to cause an out-of-memory error on deserialization.

Here is a more complete example:

The safe serialization and deserialization use bincode internally.

To selectively disable some of the features of the safe serialization, you can use SerializationConfig/DeserializationConfig builders. For example, it is possible to disable the data versioning:

Serialization/deserialization using serde

TFHE-rs uses the Serde framework and implements Serde's Serialize and Deserialize traits.

This allows you to serialize into any data format supported by serde. However, this is a more bare bone approach as none of the checks described in the previous section will be performed for you.

In the following example, we use bincode for its binary format:

Last updated

Was this helpful?