undefined | Better HN

0 pointsjuancn4y ago0 comments

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).

0 comments

chc44y ago

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.

segfaultbuserr4y ago

> 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.

rhindi4y ago

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!

1 more reply

juancnOP4y ago

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

j / k navigate · click thread line to collapse