[mikepurvis]

Fair. I suppose it really depends what the motivating use cases are for this kind of thing— in my head, the killer app would be a mail server where I decrypt (from GPG) my email in my local client, and then re-encrypt (with HE) and prepare indexing information which is sent to a cloud service for long-term archival. The cloud service allows me to search on and retrieve my email without ever seeing the contents or knowing any of the metadata other than when you uploaded them and the message lengths (and even that could be scrambled up a bunch by adding arbitrary padding and periodically re-uploading old messages). In this scenario there isn't really the "known from elsewhere" info— knowing that certain groups of messages are returned together in response to sets of queries is unlikely to be meaningful if you don't have anything else to map that info to.

And thinking about it further, the client could do other shenanigans to further protect the user, like arranging for every query to return 20% "false" results that are filtered out before display, or storing duplicate instances in the database so that the server thinks query X leads to result A and query Y leads to result B, without knowing the A and B are in fact the same thing.

[bawolff]

> In this scenario there isn't really the "known from elsewhere" info— knowing that certain groups of messages are returned together in response to sets of queries is unlikely to be meaningful if you don't have anything else to map that info to.

If the service knows the upload date of the message (presumably same as send date), and does this for a lot of users to cross correlate, that's actually quite a bit to go on to figure out who you are talking to.