[rhindi]

There are two main approaches to FHE: homomorphic boolean circuits and homomorphic numerical processing.

In the former (eg Cingulata), you convert a program into a boolean circuit, and evaluate each gate homomorphically. While this is general purpose, it also means you decompose functions that could be done in one instruction into multiple binary operations (so very slow). That’s usually what people refer to when they say FHE is slow.

The other approach consists of operating directly on encrypted integers or reals, and finding ways to do more complex computations (like a square function) in one step. While this is obviously much faster, it is also limited to whatever operations is supported by the scheme. This is what people refer to when they say FHE can only do certain things.

For years, the tradeoff has basically been slow and general purpose, or fast and limited. But there are new scheme being worked on that will be published soon that enable to go way beyond what’s currently done, such as doing efficient deep learning over encrypted data and other complex numerical processing.

Lots is coming out of labs and will be on the market within 2 years!

[entelechy]

ohh interesting! Are there any opensource implementations of homomorphic numerical processing?

Were there any efforts of combining both approaches?

[hedora]

Note that most useful homomorphic numerical encryption schemes are easily breakable. Once you have equality you can usually de-anonymize user data. Many companies have been burnt by this.

With a less than operator and the ability to encrypt chosen plaintext values, you can decrypt arbitrary messages in a linear (in message size) number of steps.

Arithmetic operations can often be used to build gadgets that bootstrap comparison operations. For instance, with addition and equality you can implement a comparison operation for low-medium cardinality fields.

The field is littered with negative results that are being sold as secure, practical systems. Be careful when using them on important data.

[rhindi]

All FHE schemes today add tiny random noise to the ciphertext so that encrypting the same data twice give different results. The noise is then kept to a nominal level as you compute homomorphically using a special operation called bootstrapping. Then when you decrypt, you just ignore the noise and get your result. If you do that well and dont let the noise grow too big, you get very strong security.

Fwiw, bootstrapping is actually what makes FHE slow, not the actual addition/multiplication etc

[bondarchuk]

>and the ability to encrypt chosen plaintext values

Isn't this a big assumption? The way I envision it is

1. client encrypts data with their key

2. server computes on data without decrypting and without needing the key

3. client decrypts computation output with their key.

Or is it always required at step 2 that the server also has the key needed for encryption (but not decryption obviously)?

[littlestymaar]

> Isn't this a big assumption?

The standard resilience criteria for modern multi-purpose encryption suppose that your scheme should be resistant to adaptive chosen-cipher attack. Chosen plaintext is a way weaker attack (the hierarchy being: known plaintext < chosen plaintext < chosen cipher < adaptative chosen cipher).

It may be OK for some situations, but it requires to be much more cautious than with regular crypto (which is already error-prone…).

[rhindi]

The server doesn’t need the decryption key, ever. Thats the whole point in fact. FHE is end to end encryption for compute. However there is sometimes a public key used, called an evaluation key.

[lumost]

Is there a good standards body to refer to for progress on these alternate encryption methods?

[ssmiler]

You can refer to https://homomorphicencryption.org for more details about security, libraries and standardization. Although for the moment it's in early stages of standardization.

[Ar-Curunir]

FHE schemes don’t allow comparing equality of plaintexts without decryption

[ssmiler]

Research paper https://eprint.iacr.org/2018/758 introduces an unified view for HE plaintext spaces. It allows switching between integral, approximate numbers and bit level representations (different HE schemes). But I'm not aware of a HE library implementing this. For the IDASH 2018 competition we have used 2 different libraries (TFHE and CKKS) in the same computation, although the scheme switching procedure was done manually.

[rhindi]

Yes, turns out you can convert ciphertexts from one scheme to another, so you can go back and forth between them depending on what type of computation you are trying to do. However the cost of transciphering is high, so in practice it doesn’t work well. But give it a few years and it’ll work!

[bargle0]

HEAAN and HEmat are two libraries for numerical processing that you can find on github. They’re not perfect, and require work to get in to shape for real distributed computation.

[rhindi]

I suggest looking at TFHE and SEAL for starters