Hacker News Reader

Comment by guiomie | Hacker News Reader

This is one of the current 'tech' trends that I'm following, the idea of homomorphic encryption is really cool. I feel like there is a lot of real world applications for it, but I have failed to find them yet.

View on HN

Cloud computing is the big one. You might want to rent some remote computer time without sending plaintext data to a third party. Homomorphic encryption lets you upload encrypted data and instructions for a third party to operate on it without having to decrypt it first.

Edit: Try Greg Egan's book Permutation City.

If we had proper homorphic encryption, we could use regular home user machines for a cloud, airbnb style. You can't do that today because the security risks are completely unmanageable. But that all changes with homomorphic encryption.

Today it's not practical, but we see advances like this every year, maybe in a decade it will be practical.

You need more than FHE for that; just because I cannot see what I am computing does not mean I will compute the answer correctly. There are ways this can be resolved but it pushes practicality even further back.

Not sure what you mean? Correct evaluation (modulo some negligible error) is part of the usual FHE definition.

Perhaps it’s referring to human malice rather than mathematical error: that we’d want some sort of certification that the operation performed off-site was actually the one requested?

You can't evaluate the correctness/trust the result without performing the computation yourself or receiving a proof of correctness, e.g. a SNARK.

Is it not practical to just saddle the dataset and compute request with a canary payload that is easily computable by the requestor?

If one can spoof the canary payload effectively, one would have broken the FHE scheme, probabilistically, right?

Unless I'm thinking about this wrong, the FH part of FHE makes this a pretty solvable problem. Is this not already fundamental to any FHE scheme?

Maybe in some cases that is possible, but it is also possible that your function requires as much time to verify as the FHE evaluator would spend on (honestly) computing the result. In other words it would make outsourcing pointless; this is briefly discussed in the related work section of this paper:

https://eprint.iacr.org/2014/202.pdf

You also have to be careful to ensure that the canary cannot be identified in the plaintext; otherwise the evaluator can homomorphically identify the canary (i.e. it can compute the canary values honestly and cheat everywhere else).

Enclaves (e.g. SGX) get you there without the need for fancy math. And you get to maintain normal computation (i.e. x86).

Enclaves have the downside of being a bit of a pain to use. But hell, FHE isn’t any easier.

With SGX you don't have to trust the cloud provider, but you still have to trust Intel. Of course, you're probably trusting Intel anyway, so this is perhaps just a theoretical concern.

With homomorphic encryption, you have to trust Intel to build CPUs that calculate correctly. Except for FDIV style bugs (which are pretty rare, and it's telling that FDIV, from the mid-90s is the go-to example), they mostly managed to maintain that trust.

With SGX you have to trust Intel to build CPUs that isolate securely. Meltdown, Spectre (multiple variants), bugs in Intel TXT and ME, and that's only some of the headline issues from the last 4 years.

...and if there are bugs, with SGX they could expose your secrets. With homomorphic encryption they should just turn your results into detectable garbage on your end, I'd expect.

It is somewhat doubtful, though, that SGX achieves what it was supposed to achieve. While you get full-RAM encryption & integrity, the trouble is that CPUs tend to only work-as-defined for a narrow range of environmental parameters. In all likelihood, a malicious cloud provider can take a CPU out of spec, at which point pretty much all security guarantees go out of the window...

My understanding was that if you take the CPU out of spec (e.g. voltage) while in an enclave, you’ll get MCEs and the CPU either nukes your enclave or forcibly reboots (idr which).

That said you can still shave it down and start FIBing if you have the $$$.

But if you test 5 + 3 = 8 with the current key, wouldn't you then be able to detect a similar pattern in the data you are processing ?

I don't think the data processor would have the key. They'd receive the encrypted inputs and the operation, and return the result.

I have zero knowledge in the field so all my questions are quite naive.

But the encryption process is public right ? So you can encrypt just like any client ?

I really want to sarcastically say "blockchain homomorphic encryption", but, well, it's not necessarily a terrible idea, honestly. One can imagine some combination of the primitives in which you could prove that you added here the same amount you subtracted from there, that neither total is below zero, but for which the number actually transferred is encrypted. The current use case for something like BitCoin is often security focused, but there's also simply a privacy concern that could be addressed there.

I think this is what zcash already does.

zCash uses zk-SNARKs for secret transactions. Which are awesome. But homomorphic encryption allows general-purpose computation.

These fully homomorphic encryption systems can do boolean circuits, which are no more powerful than the arithmetic circuits you get with zk-SNARKs (in fact, are an instance of arithmetic circuits). And with some zk-SNARKs, you get recursive composition, which lets you do arbitrarily many steps of a transition function expressed as a zk-SNARK, which is just as general purpose (albeit more involved) as applying a bunch of boolean circuits to some data.

Hey, we're working on blockchain "somewhat homomorphic encryption" (SHE) via multiparty computation. In particular, a privacy layer for Ethereum.

I implemented this, on top of Fabric however, and with a semi-trusted controller node, for a rather large industry. Was a lot of fun, and is being used in production. You can get quite far with SHE.

There's already practical cryptography to do what you just described called Confidential Transactions. It's not true homomorphic encryption, but it does securely hide the amount transferred on the blockchain while still guaranteeing that a legal transaction occured (no money created or destroyed)

You should look into Enigma (blockchain company). They use this type of technology to enable private decentralized multi-party computation.

> One can imagine some combination of the primitives in which you could prove that you added here the same amount you subtracted from there, that neither total is below zero, but for which the number actually transferred is encrypted

You are exactly describing Mimblewimble.

https://github.com/ignopeverell/grin/blob/master/doc/intro.m...

The "Confidential Transactions" scheme for cryptocurrencies uses homomorphic encryption.

The idea is that you can prove that the encrypted input and output amounts in a transaction balance to zero, without having to actually reveal what any of those amounts are.

See https://people.xiph.org/~greg/confidential_values.txt

CTs don't use homomorphic encryption. They use "additively homomorphic commitments" which are, essentially, cryptographic proofs.

There are certainly real-world applications, just not with the current level of overhead that known algorithms require.

The real-world use case is being able upload data to a cloud provider and do queries and computation on it without the provider ever knowing what's inside. e.g. "How much did I spend last month?"

One of the side projects I have is [FHE-CPU](https://github.com/CapacitorSet/FHE-CPU), an effort to make general-purpose homomorphic computation possible with a Moxie-like CPU, but it's a daunting effort to even get the basics working.

One of the big ones is internet searches. Also processing PII/HIPAA data.

How does this affect internet searches?

Potentially a search engine could provide results without knowing the actual query, although that would make it difficult to identify new trends or determine which results are/aren't being clicked, so it probably wouldn't be competitive as a general purpose search engine.

It would also be completely impractical, since the search engine would necessarily have to perform some sort of scan of its entire database to respond to every query (otherwise it would, in fact, learn something about the query).

Unless the database is also encrypted and provides the same homomorphism against reverse index queries.

If the database was encrypted, you would need a different encrypted database for every user - again impractical.

In which case you are no longer talking about FHE. With FHE the server receives a ciphertext query and produces a ciphertext output, without ever seeing any plaintexts (not even the result of a reverse index query).

One of the things another team at my organisation is working on is using it so that competitors can pool their data to do better analytics over the whole corpus without actually revealing their secrets to the other company - https://www.n1analytics.com/.

The "textbook" application is spam filtering for encrypted mail.

Reply on news.ycombinator.com