General purpose FHE is indeed quite slow. But by focusing on specific subproblems, like private information retrieval (get rows from a database without revealing anything about your queries), it is possible to achieve acceptable performance. There's been lots of recent improvement here: see papers [0] and [1] from this year, which both achieve GB/s throughput for private database lookups.

And for a more tangible demo of FHE, we built open-source webapps that let you privately browse Wikipedia [2] or look up live Bitcoin address balances [3]. This is FHE running in the browser today, returning results in seconds.

[0] https://eprint.iacr.org/2022/368 (disclaimer: this is our paper)

[1] https://eprint.iacr.org/2022/949

[2] https://spiralwiki.com

[3] https://btc.usespiral.com

To make it fast I think we'll need custom silicon. I wonder how many stealth startups exist working on FHE chips?

This isn't a problem that silicon can fix. FHE requires orders of magnitude more operations to be done, and/or more complex operations, to achieve the same results. GP silicon already runs these operations as fast as possible, it's just that there are too many of them, and they are not even parallelizable.

I was gonna say, but yeah if you can't make it more parallel, then yeah custom silicon definitely would bottleneck on that. TBF I know nothing about this, but I have done a lot of parallelization and speeds up of algos on FPGA that are relatively easy to parallelize and seen tremendous speed ups over general purpose CPUs.

I wouldn't hold my breath on this. Reducing it by x40 AND making sure that hardware is not leaky.

Wait, how would hardware be possibly leaky? The encryption/decryption can leak data, sure, but that's unrelated to FHE. If your hardware can leak info about the plaintext on the side processing the encrypted data, then you could do the same in software anyway, and the FHE scheme itself is clearly broken...

Basically. FHE would not "leak" anything that anyone could decipher except the owner of the key for the submitted calculation.

It's clear v4dok doesn't understand how FHE works, maybe due to confusion with enclaves like SGX. The hardware isn't able to leak the plaintext because it doesn't have the key; it executes on the ciphertext.

The hardware is not relevant if it's simply being used as an accelerator. FHE reveals no information about the underlying data, so the privacy leakage is the same, no matter if you're running the FHE code on ENIAC or on a modern supercomputer.

At least the one that employs the author of this article.

Are the used operations that exotic that special hardware can achieve massive speedups?

Not at all, but imagine having to perform 10.000 multiplications on numbers of 10.000 digits just to encrypt "This is my password".

And that, differently, for each access (write and read) to each cell in the table.

Not what you would say feasible right now.