Hacker News Reader

Comment by entee | Hacker News Reader

Can someone better versed in this area give a decent sense of how this works and whether this is feasible? Also, as the article mentions, given an unencrypted dataset similar to the original, couldn’t you figure out important elements of the underlying data by brute force reverse engineering of the resulting algorithm?

View on HN

The hitch is the explosive increase in the size of the data. From the article:

> Encryption methods to enable FHE can increase the size of the data by 100-1000x

Note that the DARPA program does nothing about this. DPRIVE is about making the computation go faster. The input+output dataset size explosion is a much harder problem; there's no real silver bullet anywhere on the horizon. This stuff is not viable for "big data" type computation, or anything involving a database.

Personally I'm skeptical that it will ever save customers any money. What it might do is allow a sale to go through in a situation where the vendor won't trust the customer with a copy of the algorithm they're selling, and the customer won't trust the vendor with a copy of the data. So instead of "nobody buys nothing", a sale is made and the telecoms make mad bank from all that bloaty FHE-ified data flying around.

Note that input+output size explosion is one of the major barriers to post-quantum encryption (PQCrypto) being competitive with RSA+ECC. This is understandable: FHE and PQCrypto use lattice-based cryptosystems.

FHE is pretty well established at this point. It can guarantee that someone observing the computation has no ability to tell what data they are acting on or what result they are outputting.

But, this is notably assuming that the program is not itself outputting leaky information. For example, if I use FHE to encrypt a program that takes my name and date of birth as input and then output "Taek is over the age of 21", the program itself has revealed data about me.

You can't reverse engineer the FHE itself. But if the encrypted program is outputting information that could be used in reverse engineering, FHE is not going to protect you. Similar to how Tor isn't going to protect you if you go and log into Facebook using your real account information.

What output are you talking about? In FHE, you need the private key to decrypt any output. The "program" cannot output anything without access to some decryption oracle.

I think the point is that the program is useless unless it outputs _something_. And when it does, it can leak. This isn't a mind blowing concept.

The inputs are encrypted, the processing is encrypted, the outputs are encrypted. Once the execution service has produced an encrypted result it is sent back to the requester, who decrypts the returned result with their decryption key, which has never left their control.

Working and secure crypto is based on the fact that you get different ciphers for the same massages. So if you run „21“ through you encryption you get „xy“ as your first cipher. If another user puts in „21“ and runs it through encryption the output should be now something like „ae“. That’s not the case with FTH you always get the same result. That’s bullshit. Because if data leaks you can reverse engineer the ciphers without having a private key. If your encrypted data can be decrypted without the private key. Your encryption ist just nonsense.

This is not how homomorphic encryptions works. The schemes in use are not deterministic.

The whole point of FHE is that the output (at the cloud server) is encrypted so that you can send it back to a client for decryption. Assuming an attacker isn’t in control of the client, there is nothing that would leak.

So, just as I can store an encrypted file in the Cloud and nobody can tell what it is, we can have a computation happen in the Cloud where nobody can determine what it is?

Yes. But not only the data, also the algorithm isn’t visible to the computer doing the computing...

You may be thinking of Indistinguishability Obfuscation. Current FHE algorithms (e.g. those undergoing standardization: https://homomorphicencryption.org/) don't provide IO. The compute provider knows the exact graph that is being computed, but, in the most secure scenario, they don't get to know the inputs and outputs of each node in the graph. The node operation (which can be only addition or multiplication) must be known to the compute provider so they can perform the correct mathematical transforms on the encrypted data.

Exactly. And the magic is that now you can securely compute aggregations of data you've stored without having to download all of your data.

Say you have some field in all of your encrypted, cloud-stored records and want to find the sum of all of them. With traditional encryption you'd either have to trust the cloud with your decryption key or download all of the records for local processing, which could be very slow. With homomorphic encryption you can instead have a cloud service do that computation without any visibility to the actual values and only have to download a single ciphertext containing the result.

Unfortunately you can't even make the FHE produce unencrypted output at all currently, doing so would give you you secure obfuscation -- but AFAIK all candidates for that seem to be badly broken.

If you need unencrypted output, you don't want FHE, you want functional encryption. But it's much younger and there's still a lot of research to be done in the field before prime time.

Reply on news.ycombinator.com