Honestly, I think the potential advent of efficient fully-homomorphic encryption is potentially one of the largest effects we could ever see on privacy-related computing. The possibilities are absolutely staggering. Imagine, for example, a search engine that returns useful results but does not know what the user is searching for. And so on; the possibilities are well-covered in the literature.
As of right now, the current-day state-of-the-art fully-homomorphic schemes impose roughly a billion-factor overhead on operations, but this is quickly decreasing (in the past 4 years, we've already knocked off three orders of magnitude). But I am personally convinced that an efficient scheme would likely revolutionize privacy in computing. Exciting stuff, especially with recent events.
Unfortunately, I don't expect an efficient scheme to be widely-used for at least 15-25 years. For one, even if a super-efficient FHE scheme was published tomorrow, it'd probably take at least 6-10 years of powerful, sustained cryptanalysis for the community to trust it. Add the time to discover such a scheme (if even possible...) and you have quite a while. But still, the potential is amazing.
> For one, even if a super-efficient FHE scheme was published tomorrow, it'd probably take at least 6-10 years of powerful, sustained cryptanalysis for the community to trust it.
Even so, for the use cases suggested (e.g. search engines), it'd still be a vast improvement on what we currently have – even if it later turns out to be flawed.
Here's a hypothetical use case for homomorphic encryption, although I think it needs to do a lot more than the linked example if it's actually going to work in this case:
There's a bunch of data on a server, including, say, encrypted names. Users accessing the server have a key to decrypt those names, but they also need to be able to search for and sort names. Decrypting all the names and searching/sorting would be one option, but with enough names, it becomes very, very slow. Another option is having a big index that you decrypt for searching/sorting. This is kind of unwieldy as well, even if it's faster than decrypting everything piece by piece.
Perhaps the right homomorphic encryption techniques could also be used, although you'd have to account for substring searching in the case of names: finding "David" searching for "Dav".
This reminds me of the average salary tool. If you are not allowed, or it is bad form, to ask your peers' salaries you can create a list of people add a random number to your own salary give it to the first person on the list that person had their salary and gives it to the next continuing through the list. The last person give you the final number. You subtract your random number and divide by the total number of people and bingo you have the average salary of the group.
I actually did this once at a company I worked for. Both the management and the employees ended up unhappy.
(the typical, and more secure, version of this includes public key encryption between each participant)
Can you expand a little on why the result of this made people unhappy? At a guess, something relating to significant differences in salary for similar jobs?
Is it possible to use homomorphic encryption to create a network of "dump pipes" for exchanging data?
Tor is slow because data has to hop from peer to peer until it hits its destination. What if the "nodes" between you and the recipient ran on a single machine? Clients would simply send a homomorphically encrypted program to a central server which merely executed it. The programs and the data exchanged could be completely transparent, you could even give law enforcement access, and assuming:
1. the homomorphic encryption is secure
2. your data passes through enough trustworthy peers
3. there are enough nodes involved for plausible deniability
...it would not be possible to identify the path data takes as it is routed around.
Could you explain what you mean a bit more clearly?
Traffic can be anonamised hopping it around many peers (assuming that a critical mass of them are not observed, which seems entirely likely these days).
If you sent a request to a single machine, which routed it between processes, eventually decoding the request, you are saying that the machine would not know what user made that request, and it could return the result via the same chain. But because both ends and the processing are observed, traffic analysis would yield which client asked for the file trivially. Rather like if the enemy controlled every node on your darknet, they could trivially know who you were and what you were doing.
The strength of the network is lots of nodes and lots of hops, in the hope that you will pass through enough uncontrolled ones that traffic can't be resolved. While what you suggest might, possibly reduce the risk from a compromised node in a multihop chain, it would not defeat traffic analysis, which is the major problem. Better just to inject fake traffic.
You could still trace packets into and out of the server, showing you exactly where your traffic is being routed.
I don't understand how HE will magically solve this. An HE encrypted application cannot be run on a server, because the instructions would still need to be decrypted for them to execute. HE allows a server to perform an encrypted operation on encrypted data. What you can do is a type of DNS server without anybody knowing what URL's you are looking up.
[+] [-] ReidZB|12 years ago|reply
As of right now, the current-day state-of-the-art fully-homomorphic schemes impose roughly a billion-factor overhead on operations, but this is quickly decreasing (in the past 4 years, we've already knocked off three orders of magnitude). But I am personally convinced that an efficient scheme would likely revolutionize privacy in computing. Exciting stuff, especially with recent events.
Unfortunately, I don't expect an efficient scheme to be widely-used for at least 15-25 years. For one, even if a super-efficient FHE scheme was published tomorrow, it'd probably take at least 6-10 years of powerful, sustained cryptanalysis for the community to trust it. Add the time to discover such a scheme (if even possible...) and you have quite a while. But still, the potential is amazing.
[+] [-] Osmium|12 years ago|reply
Even so, for the use cases suggested (e.g. search engines), it'd still be a vast improvement on what we currently have – even if it later turns out to be flawed.
[+] [-] baddox|12 years ago|reply
[+] [-] cabalamat|12 years ago|reply
[+] [-] davidw|12 years ago|reply
There's a bunch of data on a server, including, say, encrypted names. Users accessing the server have a key to decrypt those names, but they also need to be able to search for and sort names. Decrypting all the names and searching/sorting would be one option, but with enough names, it becomes very, very slow. Another option is having a big index that you decrypt for searching/sorting. This is kind of unwieldy as well, even if it's faster than decrypting everything piece by piece.
Perhaps the right homomorphic encryption techniques could also be used, although you'd have to account for substring searching in the case of names: finding "David" searching for "Dav".
[+] [-] joshuak|12 years ago|reply
I actually did this once at a company I worked for. Both the management and the employees ended up unhappy.
(the typical, and more secure, version of this includes public key encryption between each participant)
[+] [-] aaronmerriam|12 years ago|reply
[+] [-] nkoren|12 years ago|reply
[+] [-] eterm|12 years ago|reply
Are negative numbers not yet supported?
editted to add: Or indeed decimal numbers.
Natural numbers only then?
Still seems cool even if how it works is a mystery to me.
[+] [-] 9ac345a5509a|12 years ago|reply
[+] [-] ewillbefull|12 years ago|reply
Is it possible to use homomorphic encryption to create a network of "dump pipes" for exchanging data?
Tor is slow because data has to hop from peer to peer until it hits its destination. What if the "nodes" between you and the recipient ran on a single machine? Clients would simply send a homomorphically encrypted program to a central server which merely executed it. The programs and the data exchanged could be completely transparent, you could even give law enforcement access, and assuming:
1. the homomorphic encryption is secure
2. your data passes through enough trustworthy peers
3. there are enough nodes involved for plausible deniability
...it would not be possible to identify the path data takes as it is routed around.
Or am I missing something?
[+] [-] shubb|12 years ago|reply
Traffic can be anonamised hopping it around many peers (assuming that a critical mass of them are not observed, which seems entirely likely these days).
If you sent a request to a single machine, which routed it between processes, eventually decoding the request, you are saying that the machine would not know what user made that request, and it could return the result via the same chain. But because both ends and the processing are observed, traffic analysis would yield which client asked for the file trivially. Rather like if the enemy controlled every node on your darknet, they could trivially know who you were and what you were doing.
The strength of the network is lots of nodes and lots of hops, in the hope that you will pass through enough uncontrolled ones that traffic can't be resolved. While what you suggest might, possibly reduce the risk from a compromised node in a multihop chain, it would not defeat traffic analysis, which is the major problem. Better just to inject fake traffic.
[+] [-] kabouseng|12 years ago|reply
[+] [-] geal|12 years ago|reply
For anonymization systems, care must be taken: being able to manipulate encrypted data could very well create information leaks.
There have been some interesting theoretical uses of the Pallier cryptosystem in private information retrieval systems, though.
[+] [-] swordswinger12|12 years ago|reply
[+] [-] general_failure|12 years ago|reply