Homomorphic comparison can allow an attacker to recover plaintext through iterative encryption of guessed values and comparing them with the original ciphertext (chosen plaintext attack). What mechanisms are implemented in TFHE to prevent this indirect information leakage? Are there any restrictions on homomorphic equality testing to mitigate such attacks? And what about the evaluation key? If user doesn’t have this key he can’t perform operations on ciphertext but such type of key is public, so it can be shared. Do you consider it as a part of problem solving or the first part of the question has different answer?
Hi Savage!
Homomorphic operations in TFHE return an encrypted result. This means that the equality will return an encryption of a boolean value, and it is not possible to recover the clear value without the secret key. So even with an evaluation key, you cannot learn anything new about a ciphertext by performing operations on it.
Another thing to keep in mind is that for a given key, the ciphertext space is much larger than the plaintext space. This means that every time you encrypt, for example, the value “true”, you will get a different ciphertext. Thus, even if you know a given plaintext/ciphertext pair for a boolean value, you cannot use it to deduce the value of other ciphertexts.
That’s related to a security notion called indistinguishibility, Ciphertext indistinguishability - Wikipedia, if you want to read a bit more about it.
Got it, thanks. May I ask few more things? 1) so does it mean that during computations I can’t validate the equality (meaning to get answer without decryption) and can not make a right decision about continuation of computation like “if C1 == C2, C1 * C3” and question N2) TFHE Uncompressed ciphertext size is about 1MByte in case of uint256 computations, does it mean that after 1 multiplication of C1 * C2 = size of 2 MBytes ciphertext? And 3) in case of floating point math, how do you manage mantissa and exponenta (Precision in general) in order to handle correct computational results) especially if plaintext size is 256 or floating point number. Because after every multiplication your plaintext will drastically grow and respectively cophertext shall grow much more than for integers?
Thanks in advance
Hi!
- You are partially right here, you can’t know the result of the equality without doing a decryption. However it is possible to do some conditional operations. For that, you can use the FHE ternary operator (select): Types & Operations | TFHE-rs
let encrypted_res = &encrypted_cond.select(&encrypted_a, &encrypted_b);
-
Arithmetic operations are modular, meaning that the types won’t automatically grow and will instead “wrap around” if you go over the type max value. That’s similar to normal rust here, if you multiply 2 u64 values the result is an u64 (except that rust might panic on overflows based on your compilation flags).
If you want to detect potential overflows, you can use the overflowing operators: Overflow detection | TFHE-rs. -
Floating point arithmetic is not implemented at the moment in TFHE-rs
I see, so you are saying that due to modular reduction I always stay within the same defined prime as uint128 or another.
Regarding floating points, you said it’s not implemented. So it means I can encrypt and operate only on integers plaintexts right? What if I do division operation of operand which resulting floating point value, it means I lost it, right?
Like with rust division over integers, it will return the quotient of the division. You can get the remainder of the division with the % operator: Types & Operations | TFHE-rs.
Yeah, I understand what rust does, just clarifying for myself all nuances, where I’m trying to understand the following:
- may I encrypt 3.14 ? And if yes I assume it will be 314 with later operation after decryption of 314 / 10 power 2
I.e. fixed point operations - if not how do you manage integer part and quotient in the same ciphertext?
Thanks
The encryption takes rust integers as an input, so you cannot directly encrypt a floating point value. If you want to do some fixed point arithmetic, you will have to encode it yourself by doing the conversion before the encryption and after the decryption.
Thanks, now I’ve got it.