[juancn]

The extra cost is worrying. You're talking at 4 to 6 orders of magnitude increase in resource usage for the same computation.

Unless we figure out some awesome hardware acceleration for it, it's not practical but for a few niche applications.

It also has the problem that you can use computation results to derive the data, if you have enough control over the computation (e.g. a reporting application that allows aggregate reports).

[chc4]

Modern homomorphic encryption schemes only have a ~100x performance hit. That sounds bad, until you remember that computers are really fast and spend the majority of time doing nothing, and that the difference between writing a program in Python or C is already something like 10x.

[segfaultbuserr]

> Modern homomorphic encryption schemes only have a ~100x performance hit.

Really?! Now I'm curious. If I have a simple program for an 8-bit CPU @ 1 MHz, when can I run this program on a virtual machine using homomorphic encryption, under a reasonable runtime? Is it possible yet? If the performance hit is only 100x, the runtime should not be much longer than the actual chip. But the last time I checked, the hypothetical runtime seems to be still impractical.

[rhindi]

8 bit is definitely doable today, fast

There are basically 2 strategies:

- do fast operations, with a limit on how many you can do. This is called Leveled Homomorphic Encryption, with CKKS being the most popular scheme. Microsoft open sourced a lib called Seal for it.

- do unlimited operations, but with extra overhead. This is called Fully Homomorphic Encryption, with TFHE being the fastest implementation. My company Zama has open sourced an library in Rust called Concrete.

Reminds me a lot of deep learning in 2010, just before it took off!

[segfaultbuserr]

Thanks.

[juancn]

Still, 100x is a lot. I would still bet that it depends on the complexity of the workload.