[brianpgordon]

> > Search isn't possible

> 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?

[quanticle]

The search doesn't happen on the server. The client (e.g. desktop client) indexes the messages and encrypts the index. Then, when another client (e.g. mobile client) wants to search for a message, it downloads the index, searches it, and then pulls down the appropriate message(s).

[ynik]

If an attacker can tell which part of the index was modified, that gives them enough information to decrypt the index and e-mails.

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.

[e12e]

Technically if a client has a full index version X (in plaintext), it could modify X to get X+1, compute a binary diff between X and (X+1) - encrypt and upload the diff.

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.

[GordonS]

I'd you are using a new IV when encrypting the new index then this won't work, since the old and new indexes will be completely different.

[e12e]

You would have to re-download the index after compaction. But the index and patches would be independent - you apply the decrypted patches to the decrypted index.

[grapehut]

I'm not quite sure what you're getting at. It sounds like you're describing a known-plaintext attack, which modern ciphers are not vulnerable to. And what you are describing makes it seem like full disk encryption would be totally useless, but we know that's not the case.

[dleslie]

> > Encrypted Index

This is not the same as the content.

[drdaeman]

Well, the client has to fetch message once, decrypt it, and upload updates to the index (kept on server).

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.

[Groxx]

It's still likely too large to really consider for mobile use, but yes - far better than downloading everything.

[Pxtl]

So what, you hash each word in the e-mail and search for the hash, and this returns which emails include those hashed words? Would that be horribly insecure? I guess it would be impossible to salt those hashes, and it probably risks defeating the whole crypto.

[gardnr]

https://en.wikipedia.org/wiki/Salt_(cryptography)

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.

[lisper]

> Would that be horribly insecure?

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.)