Clients would always have to download+upload the full index (which needs to be re-encrypted with a new IV). This is a huge problem - the index can easily be hundreds of MB for a large mailbox.
Another client on index version X could download the diff, and get index (X+1).
Some desktop client should probably do compaction from time to time.
This is not the same as the content.
I guess, it is a reasonable sacrifice for privacy, unless you want searches to be able to search within attachments including documents in big archives.
You wouldn't use a hashing algorithm to build the index. They are talking about an inverted index in a binary format, something like what lucene outputs. That binary index would be encrypted with a block cipher (AES, Blowfish) using a secret key and would then be stored on the server.
The mobile client comes along and downloads & decrypts the index in memory, searches it for some terms(s), the index returns 10 result, of which, the user selects one and the mobile client downloads and decrypts to show to the user.
Yes.
> I guess it would be impossible to salt those hashes, and it probably risks defeating the whole crypto.
Exactly. (There are other problems too, but that one by itself is a show-stopper.)
> It absolutely is, in both theory and practice. The server stores an encrypted index, and the client walks it (requesting parts as needed). It's going to little slower, and a lot more complex but it's doable.
Are you suggesting that to search your mailbox, the client should download every single encrypted message in the entire mailbox and decrypt them all locally to search them?
If not, how does the server get this "encrypted index" without having your private key?