[osaariki]

I do research on FHE. On a high level querying works by evaluating an equivalence function between the encrypted query key and keys in the database such that the result is 1 if the key matches and 0 otherwise. You can then multiply this with the values and sum all of them together to get just the row that matches.

For write operations you could do a similar trick to select a new version of each value based on the query key matching. You are in effect writing all rows, but using the old value when you don't want to change it.

Now, due to some quirks of FHE you can only do this write operation a limited number of times before you have to perform a more expensive operation called bootstrapping to "refresh" ciphertexts. I find bootstrapping to be the coolest part of homomorphic encryption: you encrypt the secret key itself with homomorphic encryption and then use it to decrypt inside FHE. The result is still encrypted but closer to a freshly encrypted ciphertext.

[h0l0cube]

So in essence you're performing encrypted operations on a remote and potentially untrusted encrypted database, but these operations are very expensive? So when would this be valuable?

[sodality2]

When it matures to be less expensive, or the hardware handles it fast enough to not be a problem.

[h0l0cube]

But always orders of magnitude slower than what a vanilla CPU can do locally. The value would entail that operations on a remote server are necessary to the function. Maybe a remote database that can be accessed from multiple devices with the same key but still permitting simultaneous read/write operations? The database could be compromised without any data stolen.

[sodality2]

Sometimes the benefit from FHE can be larger than the speed gains. Doubt facebook would use this (for scaling and privacy reasons) but if the CIA needed to not have to trust a cloud provider for something of a smaller scale? 100% worth it.

> The value would entail that operations on a remote server are necessary to the function

Yes, not every organization has the compute power necessary, or even prefer to not handle it at all in house. If you only manage keys locally, that's a significantly smaller attack surface.

[h0l0cube]

> 100% worth it

I'm not sure the value proposition is clear cut. In terms of security, while the server data itself is secure, and the nature of the transactions are inscrutable, there's now reason to share a single key between multiple users, and only one of those users needs to be compromised. The key could be generated and stored in some super secure silicon with a small attack surface, but if the data needs to be available to multiple users, you're back to duplicating and distributing the key, and social engineering remains the best attack vector. A benefit could be gained with multiple users with multiple keys and limited sharing to reduce vulnerability, like sharing sensitive documents between between select individuals. But that's a pretty niche use case.

[jdc]

Are there any good papers (with code even) you know of demonstrating these kind of practical applications?