5 ms·
> > 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 n
by brianpgordon 10y ago
> > 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?
- dleslie 10y ago> > Encrypted Index This is not the same as the content.
- drdaeman 10y agoWell, 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 10y agoIt's still likely too large to really consider for mobile use, but yes - far better than downloading everything.
- quanticle 10y agoThe 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 10y agoIf 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 10y agoTechnically 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 10y agoI'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 10y agoYou 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 10y agoI'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.
- Pxtl 10y agoSo 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.
- deleted 10y ago[deleted]
- lisper 10y ago> 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.)
- gardnr 10y agohttps://en.wikipedia.org/wiki/Salt_(cryptography) 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.