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 Afrom a serializedtype Braises 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 Awith one set of crypto parameters from an object oftype Awith 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_conformantmethod to check parameter compatibility. Besides, thesafe_deserialize_conformantfunction includes the parameter compatibility check, and thesafe_deserializefunction 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?