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.
> 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?
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.)
> 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.
base64encode(hmac("[email protected]+valid-to+01012018", key))[email protected]
Truncated to something like [email protected] that would only be valid when sent with the from-adress [email protected] (along with some clever magic to avoid email loops! :-)
I think maybe it was authored by ESR (Eric Raymond) in python - but Google only turns up various dkim schemes...
New senders would have their mail held back, and get a "please reply if you are human"-message - a reply (to the "magic" reply-to alias) would release the held mail and whitelist the sender.
A greylist variant of sorts.
It wouldn't be so good if email turned into Facebook, where you can only contact somebody if the circuit has been established beforehand (i.e., both parties friend each other). What happens if this is the point of initial contact, and there's no other way to get in touch? I have to conspicuously friend this person from my otherwise dormant account and then not think about whether they're going to feel weird when I unfriend them later on?
I sent an unsolicited email a couple weeks ago. Academic-type, self published, personal webpages where I saw something that needed fixing, and so I did. There was no CMS, just a static site—and not the sort where you're running markdown sources through a generator and have a whole Git hosting service apparatus intertwined with hooks sunk into it. Plain, legacy HTML. I saved a local copy to my machine, made my changes, and mailed them in. They happened to be machine-readable patches, given the recipient, but it could have just as well been a message written in natural language. The changes were made, I was thanked, and done.
I'm still upset that in the 90s I could get in contact with almost anybody by looking in the phonebook, but when I tried doing that a few years ago for an old coworker, it was hopeless. Getting the listings for a city you've moved away from can prove to be harder than it seems, even when you know they have a landline.
These are the kinds of things you lose when you assume the world is already fixed in the form that it should maintain going forward.
"stretching" the equivalent of rsa(session_key, public_key) might be feasible?
Going on a tangent, but do you know of any services that offer such a thing?
Also, "What? subjects and recipients are unencrypted!?" -- Every User Ever
Where not knowing helps with patents it is in that if you infringe, wilfull infringement increases damages up to threefold.
It should be technically impossible. If it's a matter of choice for tech support reps, it's not secure for many reasons.
> 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.
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.
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)
Were you using 2-factor?
> 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 ?
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.
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
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.)
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.
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.
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