I've been really excited about the potential use of HE for private messaging. Today the most anyone does is end-to-end encryption, which does a great job protecting what you're saying, but it fails to protect who you are talking with. HE has the potential to change that.
The Wikipedia demo[1] starts with a big download because you're fetching an index of articles. Subsequent requests have you send an encrypted one-hot[2] vector making the article you want to read. The server does an encrypted dot-product of the vector with the vector of articles, returning just the encrypted article you're looking for.
A messaging system could do the same thing, where your vector selects member identifiers or public keys.
End to end encryption can hide the recipient, at the cost that each recipient has to attempt to unencrypt all encrypted messages with their key to see if they were the intended. This is fairly fast on modern computers, and is how secure scuttlebutt works. Note this is only feasible on gossip protocols, pub-sub, or content addressable hash stores where you are only looking at a subset of the users that you follow, instead of inspecting all traffic without another side channel for indicating what messages should be inspected.
I think I understand what you're suggesting, but keep in mind that in the Wikipedia example the database is largely static (the server decides when to update), while a messaging app needs to support users updating the DB. There are a lot of leakage scenarios that need to be taken into account (like no push notifications).
Spiral has a video[1] where they dive into some of the details.
Comments
I've been really excited about the potential use of HE for private messaging. Today the most anyone does is end-to-end encryption, which does a great job protecting what you're saying, but it fails to protect who you are talking with. HE has the potential to change that.
The Wikipedia demo[1] starts with a big download because you're fetching an index of articles. Subsequent requests have you send an encrypted one-hot[2] vector making the article you want to read. The server does an encrypted dot-product of the vector with the vector of articles, returning just the encrypted article you're looking for.
A messaging system could do the same thing, where your vector selects member identifiers or public keys.
[1]: https://spiralwiki.com/
[2]: https://en.wikipedia.org/wiki/One-hot
Hiding the metadata is indeed very important for the privacy conscious.
To quote an ex-NSA chief "We kill people based on metadata". https://abcnews.go.com/blogs/headlines/2014/05/ex-nsa-chief-...
Metadata is data.
End to end encryption can hide the recipient, at the cost that each recipient has to attempt to unencrypt all encrypted messages with their key to see if they were the intended. This is fairly fast on modern computers, and is how secure scuttlebutt works. Note this is only feasible on gossip protocols, pub-sub, or content addressable hash stores where you are only looking at a subset of the users that you follow, instead of inspecting all traffic without another side channel for indicating what messages should be inspected.
I think I understand what you're suggesting, but keep in mind that in the Wikipedia example the database is largely static (the server decides when to update), while a messaging app needs to support users updating the DB. There are a lot of leakage scenarios that need to be taken into account (like no push notifications).
Spiral has a video[1] where they dive into some of the details.
[1] https://youtu.be/T7RDEEJ5vQg
This is basically what we did in our project: https://www.cis.upenn.edu/~sga001/papers/pung-osdi16.pdf.
We never built it into a product because we couldn't figure out a way to monetize it to pay for the servers.