[bigbrooklyn]

These are just minor problems. End to end encryption should not be forced upon users, but should be used selectively. You don't want to lose your entire inbox because you wanted to send a few encrypted emails.

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

How slow would this be with thousands of emails on a mobile device ?

> This is a damn feature. I had my icloud account social engineered (someone walked into an apple store claiming to be me and they couldn't get their iphone syncing to "their account"). I'll never again trust another company with my private stuff.

Most email providers don't have retail stores where this type of attack can happen.

> This is a non-issue. It can easily be derived from a password

What happens if this password got into the wrong hands or even lost? Is it possible to change? Must I re-encrypt every single email ?

[DrJosiah]

> How slow would this be with thousands of emails on a mobile device ?

Not that much slower than email is now. A B+tree index of (for example) 1 gb of total content and index is only about 1-2 gigs in size. You could just store that shit on your phone encrypted. Or 1-5 megs of index on your phone, with 2 round-trips for any email/first page search result per word.

> What happens if this password got into the wrong hands or even lost? Is it possible to change? Must I re-encrypt every single email ?

Overall yes, re-encryption is necessary. But that can be a batch process done while your phone is charging and on wifi over night. Is a drawback, but re-keying always is. But just because you got to change the keys every once in a while, doesn't mean you toss the locks.

[deathanatos]

> Overall yes, re-encryption is necessary. But that can be a batch process done while your phone is charging and on wifi over night. Is a drawback, but re-keying always is. But just because you got to change the keys every once in a while, doesn't mean you toss the locks.

Encrypted hard disks utilize a simple scheme whereby the password/key derived from the password decrypts a small set of keys or single key that's just randomly generated, and decrypts the rest of the drive. So, to change the password, all you need to reencrypt are the real keys.

  Password -- decrypts --> master key -- decrypts --> rest of hard drive
                           ^^^^^^^^^^
                           this is what gets re-encrypted on password change
                           and is small; ~a few KiB

Similar could be had for email.

The approach above also lends itself well to supporting multiple passwords. (If you share an account w/ someone, for example, though email has other tools like mailing lists that might be better suited.)

[sulam]

> Most email providers don't have retail stores

Lots do, though, and the ones that don't often offer customer support over the phone. And anyway, social engineering doesn't only happen in stores or when talking to CS.

[Neliquat]

Really? Name any of the top 10 email providers that have stores, or a responsive 800 number for email support. I'll give you Apple, but they are the clear outlier. MS, Google, have stores, but not with email support, and questionable phone support at best for any non enterprise product.

[sulam]

AT&T? I don't have a list of top 10 email providers, but them and Verizon and Yahoo have all had people report social engineering attacks against them to gain access to accounts.

[viraptor]

> How slow would this be with thousands of emails on a mobile device ?

This in itself is not a problem. Btrees are O(log n) for search, so thousands of emails can be looked up in 3-4 requests with the most naive way to implement remote tree walk.

The fact you're revealing the structure and index contents to the server as you search would be a bigger issue.