TLDR: I’d like to be able to call the
Ciphertext.op(&Scalar) version of the Integer API comparison operations just like I can call
Ciphertext.op(&Ciphertext). Right now, only
Ciphertext.op(Scalar) (owned not borrowed) works.
I would like to evaluate two different settings for the same code using the Integer API and involving two actors:
- Alice) has sensitive data
- Bob) has proprietary logic that could be protected by the values used in the circuit (no need for circuit privacy)
I have a working prototype where both users encrypt their data / logic (to the same key for simplicity) and we assume execution takes place at a third-party server.
I’d like to evaluate a different setting where one of the two actors acts as the execution server, and doesn’t need to encrypt its input anymore.
The current design of the library won’t allow me to switch seamlessly between the encrypted and cleartext version, without adding tons of boilerplate (and even with that, I haven’t had much luck…). Consider the following example:
let (cks, sks) = crate::utils::serde::gen_keys(false); set_server_key(sks); let ct_1 = FheUint64::try_encrypt(88_u64, &cks).unwrap(); let constant2 = 1000_u64; let ct_3 = FheUint64::try_encrypt(99_u64, &cks).unwrap(); let test_ge_ok = ct_1.ge(constant2); // works let test_ge2_dead = ct_1.ge(&constant2); // doesn't compile let test_ge3_ok = ct_1.ge(ct_3); // works let test_ge4_ok = ct_1.ge(&ct_3); // works
The second line doesn’t compile since the u64 is borrowed and FheOrd is only implemented for
Clear) but not
the trait bound `&u64: tfhe::integer::block_decomposition::DecomposableInto<u64>` is not satisfied the following other types implement trait `tfhe::integer::block_decomposition::DecomposableInto<T>`: <u64 as tfhe::integer::block_decomposition::DecomposableInto<u64>> <u64 as tfhe::integer::block_decomposition::DecomposableInto<u8>> required for `tfhe::high_level_api::integers::types::base::GenericInteger<tfhe::high_level_api::integers::types::static_::FheUint64Parameters>` to implement `tfhe::prelude::FheOrd<&u64>`
On the other hand, calling
ge() on an owned or borrowed FheUint since both implementations are available here.
My question (finally!) is thus:
- would you consider supporting borrowed
Clearas well and adding a new implementation?
- can you suggest a workaround that would allow me to get the same behaviour without adding tons of branching boilerplate to my code?