[unknownsavage]

> If you want encryption, don't use email.

That's total nonsense.

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

> If you lose your private key, we can't recover your email

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.

> Spam checking on content isn't possible

This is probably your best point. It's definitely harder to do well

> To access mail on multiple devices, the private key needs to be shared securely between them

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

[eternalvision]

Regarding Apple and security, their policy via AppleCare seems to be to ASK (over the phone, for instance) for your cleartext computer administrator password before you send in your laptop for repair, without any warning whatsoever of the implications.

[TheOsiris]

I spilled soda on my mac once, and took it to the repair shop. the receptionist there asked me for my password. I laughed and I said of course not. she was shocked and asked: well, how are we going to test the new keyboard. I don't know maybe try to type random things in the password field?

[wheelerwj]

I had this EXACT experience just this month. I went to have a screen replaced and I even explained (and apologized for the inconvenience) that I was very security focused. I set it up in advance so that would perform the repair in front of me, that the device wouldn't be plugged into any of their computers, and it wasn't to be taken out of sight.

Then, he straight up asked me for my password, "most customers write their password down so we can test that it works."

I feel a little bad because the look I must have given him was pretty absurd. I told him no, I'll just take the risk and test it myself.

[true_religion]

What if they install the keyboard but the drivers fail? Won't they need the admin password in order to complete the job?

[masukomi]

They have physical access to the device. They can enter recovery mode by holding down command r when restarting. It gives them a different copy of the os with multiple apps that you can type in (like the terminal) and would allow superuser access to whatever they wanted, however your encrypted home directory would remain encrypted and they would not be able to read it. In the olden days you would stick in a recovery cd and reboot onto that... you could also (historically and presently) stick a USB drive into the thing and boot into an os on that.... NEVER give out your password.

[vertex-four]

If a keyboard needs drivers other than USB-HID, someone's doing something wrong.

[sandworm101]

I thought that too, until i bought a cheap netbook that came with windows (7? Student edition? I cannot remember). I plugged in a mouse and windows said it needed to connect to the internet to download the driver for my MS optical mouse. I practically fell out of my chair laughing.

[dagw]

The "driver" is for adding a gui for doing things like customizing buttons and sensitivity and stuff, not to make the basic mouse work.

[mcpherrinm]

Many laptops use an SPI touchpad device, so they don't need to go through the relatively expensive and complex USB stack.

[lozf]

Or just boot into single user mode.

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

[FunnyLookinHat]

> > Spam checking on content isn't possible

> This is probably your best point. It's definitely harder to do well

I think it's possible, just slower and more complex (like search) - and would have to occur upon unlocking your inbox.

[amenghra]

You can mostly get rid of spam by requiring the sender to perform a proof of work if they aren't in your contacts list. I.e. whitelist of senders + proof of work or some kind of configurable per domain quota/proof of work.

[askmike]

I guess that gets rid of all other email as well..

[dexterdog]

How often do you get email from somebody that you've never gotten email from before?

[gtCameron]

Exactly once for each contact that has ever sent me an email

[ardivekar]

Maybe a two-way 'add contact' feature would be useful, like a facebook friend request.

[dexterdog]

I'm talking about now going forward. There are plenty of ways to make a person opt-in the first time they send you something. That process gets rid of more than 99% of spam.

[sandworm101]

From every client that a former client has sent my way. 50% of my clients introduce themselves with some variation of "Something happened, Bill gave me your name. Help!".

[Groxx]

Does anyone actually use e.g. hashcash though? I love the concept, but it's useless if nobody can use it.

[em3rgent0rdr]

I don't think Spam checking should be a concern since most spammers aren't going to encrypt their spam.

[e12e]

Might even flag not just plaintext email, but quarantine all mail from unseen senders / public keys. Should make spam filtering much easier.

[wheelerwj]

How often does spam come encrypted with your public key anyways?

[Neliquat]

Much more often if this is used as a spam measure.

[e12e]

Maybe. Still requires a re-encryption of the symmetric session key for every recipient - effectively proof of work.

"stretching" the equivalent of rsa(session_key, public_key) might be feasible?

[wfunction]

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

Going on a tangent, but do you know of any services that offer such a thing?

[chejazi]

https://cryptag.org

[wfunction]

That doesn't seem to have any email capabilities...

[mtgx]

Also search that only uses email titles is still at least 70% as useful as full title+body search. So I wouldn't count this as such a terrible non-feature of e2e encrypted email.

[EdHominem]

Only if you leave juicy content in the unencrytped subject.

Also, "What? subjects and recipients are unencrypted!?" -- Every User Ever

[sdenton4]

You can encrypt the metadata on the server, and enable local search on the metadata to avoid keeping the full mailbox on a phone, for example

[baudehlo]

Fwiw search that way is (I think) patented by Proofpoint. So it might be hard to implement.

[kmonsen]

It is smart to not speculate on patents. You have now possibly poisoned everyone reading this thread.

[baudehlo]

If patent law worked like coodies that comment would be awesome.

[gregshap]

The interpretation of IP law, at least internally at many big software companies, does in fact work like coodies. Hence things like "clean room implementations" of algorithms, modules, API interfaces etc.

[vidarh]

Clean room matters for copyright. It doesn't help for patents, as patents protects the idea, not the expression of it so expressing the same idea in a different way doesn't help. With a patent you want to know the specifics of the original to ensure you make yours sufficiently different to sidestep the claims.

Where not knowing helps with patents it is in that if you infringe, wilfull infringement increases damages up to threefold.

[vidarh]

Willful infringement allows the court to give judgements for up to triple compensatory damages in the US, so sometimes not knowing can be valuable.

[HappyTypist]

Adding to the iCloud story, I forgot my security questions and I was able to have the AppleCare agent over the phone reset it for me after talking about what apps I've purchased recently.

[granda]

I have experience at Apple with Account Security and that's a clear violation of SOP. That's a coaching opportunity for the advisor.

[hackuser]

> I have experience at Apple with Account Security and that's a clear violation of SOP

It should be technically impossible. If it's a matter of choice for tech support reps, it's not secure for many reasons.

[wheelerwj]

It's icloud, not personal device storage. It has to be possible if you want recoverable content. If you don't like it, you can back up locally to itunes.

[Groxx]

> > To access mail on multiple devices, the private key needs to be shared securely between them

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

How does that change the equation? You're still exposing the thing-that-decrypts to multiple devices, thus (many!) more threat vectors. Lose one, and you lose them all, which is the point of the claim.

[danielpatrick]

...so use unencrypted email?

The point is, some is better than none. More is better than some.

So many people here pointing out holes that make it worse than a theoretically perfect system even though it's leagues ahead of where we are now.

[Groxx]

No, the (implicit) point in the start of the thread is that multiple other encrypted mediums don't leak as much. Use them instead.

If you care enough to use encrypted email, you should probably seriously consider abandoning email. (signing is different - that's proof of identity and non-modification, useful in many non-private scenarios)

[fiatpandas]

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

Were you using 2-factor?

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