5 ms·

Nice plan. I've also been brainstorming ideas - I'm now considering setting up something similar (though I have less knowledge in these matters): * encrypt all

by wfn 13y ago

Nice plan. I've also been brainstorming ideas - I'm now considering setting up something similar (though I have less knowledge in these matters): * encrypt all incoming mail to a public key associated with the recipient's email address (new account creation would have to involve uploading a public key; on the other hand, if we are only talking about one user, then it becomes much simpler) * this can be done while there is nothing written to disk (via exim, etc.) * either write the resulting encrypted email to disk, or keep it in memory (depending on paranoia level) * ideally, check incoming email if it already has a PGP header; if it does, do not encrypt on top of that (this would confuse certain mail clients) * user logs in via IMAP, downloads new mail, mail client can be set up to transparently decrypt mail. User is encouraged to then delete mail from the server This wouldn't be user friendly in the traditional sense, but my initial goal presumes that compromises involving friendliness vs end to end encryption suck, so screw it. I'd like to set up something like that for personal + friends' use. Your idea of passphrase ~== private key is very nice. Mine is more ugly in the usability sense (at least for the median user), but at least at no point in the process does the server have to do anything with the private key. Still, of course, it would be possible to wiretap the whole thing at the "process incoming mail and encrypt it" point..

bradleyjg 13y ago
If you have to customize the client anyway, you might as well encrypt the metadata. It looks like you can use an unmodified IMAP server -- your MTA would encrypt each mail part individually and your mail client would decrypt. The sticking point is server side search, which is available in IMAP4. You'd either have to skip that, or implement one of the search over encrypted data algorithms (which are rather slow).
- wfn 13y ago
  > If you have to customize the client anyway, you might as well encrypt the metadata. Yes, but then you'd need a custom extension, whereas the proposed setup would be covered by, e.g., Enigmail for Thunderbird. Depends on the userbase / use case - if one were to set up such a system for themselves, then yes, this would be nice. > It looks like you can use an unmodified IMAP server -- your MTA would encrypt each mail part individually and your mail client would decrypt. Yes, that's the plan :) No need to modify the mail server itself. > The sticking point is server side search, which is available in IMAP4. You'd either have to skip that, or implement one of the search over encrypted data algorithms (which are rather slow). That is true, and this would indeed involve writing custom code/extensions. Normally, email subjects are not encrypted / presumed 'public' (in a sense), so one way to do it would be to simply allow searching for email subject lines, which would not be stored encrypted on the server. Not sure how much customization server-side this would require. edit another way to look at it would be, it shouldn't be possible to do any kind of search on the server. The client (which would presumably actually store all the mail archives (e.g. in an encrypted container which could be hooked up to a simple automatic offsite backup solution)) would do all the search. Again, however, depending on the setup, this might require some customization.
  - bradleyjg 13y ago
    Well I guess it comes down to how important you think the metadata is. In reponse to your edit, if you are storing everything client side than POP works and is considerably simpler. Heck you could even just do local delivery. The idea for IMAP with encrypted mail parts would be to allow multiple clients to access a remote mail store where the remote mail store could not read any of the stored email or its metadata even if it wanted to. You'd also want your MTA to reject mail not sent over TLS. No matter what you do though if the remote server is compromised -- technically or legally -- your future emails are subject to capture.
    - wfn 13y ago
      > You'd also want your MTA to reject mail not sent over TLS. No matter what you do though if the remote server is compromised -- technically or legally -- your future emails are subject to capture. agree & agree. Overall, the email protocol is fucked either way. :) As of now, I'm looking into, e.g. Pond [1]. Of course convincing people to just go ahead and move to something else is kind of quixotic / sisyphean; though it might be possible for a small circle of acquaintances where encryption is actually critical. [1]: https://pond.imperialviolet.org/ https://pond.imperialviolet.org/
wildgift 13y ago
That's funny. I was thinking of exactly the same thing. Another thing to do is limit how much email is kept, so old mail is automatically purged.
- wfn 13y ago
  I suspect lots of people are considering these kinds of designs these days. :) There's been some discussion on various mailing lists, usually assinine, but once in a while clever folk join in. > Another thing to do is limit how much email is kept, so old mail is automatically purged. Makes sense. I'm also not sure how easy it would be to provide an option for the user to choose, for example, whether to accept incoming mail over a plaintext channel. SMTP TLS handshake takes place immediately after the initial "hello". Ideally there could be two servers listening (the user would have to decide which server to use, each of which would imply a different email suffix), one with a forced TLS mode, and each user could choose which mode to use. Maybe I'm overthinking things over a problem that is unsolvable in the framework of the email protocol (which does suck in this regard).
vader1 13y ago
I also considered the approach of transparently encrypting all incoming mail with the user's public key, but it has a couple of downsides, mainly: * This only works if all of a user's clients support GPG. I'm looking for a solution that would work for any average Joe (on his desktop, phone and tablet) rather than a solution geared towards technical people. * This process only encrypts the email's body, and not the metadata (from, to, subject, headers containing IP addresses, etc). As a bunch of people have shown after the PRISM fallout, analysis on metadata alone can reveal an incredible amount of private information. * It would be impossible to support features such as server-side search, effectively making email search on your mobile devices impossible. Of course any solution to this problem will be a compromise between security and usability, so let's hope a number of different solutions will see the light of day, so that everyone can choose the solution that works the best for them.
- wfn 13y ago
  Nice, yes, thanks the reply, agree with everything. > This process only encrypts the email's body, and not the metadata (from, to, subject, headers containing IP addresses, etc). As a bunch of people have shown after the PRISM fallout, analysis on metadata alone can reveal an incredible amount of private information. I also had the idea to have encrypted containers something akin to what you are proposing, with PGP for the body underneath. It gets complicated.. Anyway, > Of course any solution to this problem will be a compromise between security and usability, so let's hope a number of different solutions will see the light of day, so that everyone can choose the solution that works the best for them. I very much agree. Here's to hoping to see multiple solutions soon :)

by wfn 13y ago

bradleyjg 13y ago

If you have to customize the client anyway, you might as well encrypt the metadata. It looks like you can use an unmodified IMAP server -- your MTA would encrypt each mail part individually and your mail client would decrypt. The sticking point is server side search, which is available in IMAP4. You'd either have to skip that, or implement one of the search over encrypted data algorithms (which are rather slow).

wfn 13y ago
> If you have to customize the client anyway, you might as well encrypt the metadata. Yes, but then you'd need a custom extension, whereas the proposed setup would be covered by, e.g., Enigmail for Thunderbird. Depends on the userbase / use case - if one were to set up such a system for themselves, then yes, this would be nice. > It looks like you can use an unmodified IMAP server -- your MTA would encrypt each mail part individually and your mail client would decrypt. Yes, that's the plan :) No need to modify the mail server itself. > The sticking point is server side search, which is available in IMAP4. You'd either have to skip that, or implement one of the search over encrypted data algorithms (which are rather slow). That is true, and this would indeed involve writing custom code/extensions. Normally, email subjects are not encrypted / presumed 'public' (in a sense), so one way to do it would be to simply allow searching for email subject lines, which would not be stored encrypted on the server. Not sure how much customization server-side this would require. edit another way to look at it would be, it shouldn't be possible to do any kind of search on the server. The client (which would presumably actually store all the mail archives (e.g. in an encrypted container which could be hooked up to a simple automatic offsite backup solution)) would do all the search. Again, however, depending on the setup, this might require some customization.
- bradleyjg 13y ago
  Well I guess it comes down to how important you think the metadata is. In reponse to your edit, if you are storing everything client side than POP works and is considerably simpler. Heck you could even just do local delivery. The idea for IMAP with encrypted mail parts would be to allow multiple clients to access a remote mail store where the remote mail store could not read any of the stored email or its metadata even if it wanted to. You'd also want your MTA to reject mail not sent over TLS. No matter what you do though if the remote server is compromised -- technically or legally -- your future emails are subject to capture.
  - wfn 13y ago
    > You'd also want your MTA to reject mail not sent over TLS. No matter what you do though if the remote server is compromised -- technically or legally -- your future emails are subject to capture. agree & agree. Overall, the email protocol is fucked either way. :) As of now, I'm looking into, e.g. Pond [1]. Of course convincing people to just go ahead and move to something else is kind of quixotic / sisyphean; though it might be possible for a small circle of acquaintances where encryption is actually critical. [1]: https://pond.imperialviolet.org/ https://pond.imperialviolet.org/

wildgift 13y ago

That's funny. I was thinking of exactly the same thing. Another thing to do is limit how much email is kept, so old mail is automatically purged.

wfn 13y ago
I suspect lots of people are considering these kinds of designs these days. :) There's been some discussion on various mailing lists, usually assinine, but once in a while clever folk join in. > Another thing to do is limit how much email is kept, so old mail is automatically purged. Makes sense. I'm also not sure how easy it would be to provide an option for the user to choose, for example, whether to accept incoming mail over a plaintext channel. SMTP TLS handshake takes place immediately after the initial "hello". Ideally there could be two servers listening (the user would have to decide which server to use, each of which would imply a different email suffix), one with a forced TLS mode, and each user could choose which mode to use. Maybe I'm overthinking things over a problem that is unsolvable in the framework of the email protocol (which does suck in this regard).

vader1 13y ago

I also considered the approach of transparently encrypting all incoming mail with the user's public key, but it has a couple of downsides, mainly: * This only works if all of a user's clients support GPG. I'm looking for a solution that would work for any average Joe (on his desktop, phone and tablet) rather than a solution geared towards technical people. * This process only encrypts the email's body, and not the metadata (from, to, subject, headers containing IP addresses, etc). As a bunch of people have shown after the PRISM fallout, analysis on metadata alone can reveal an incredible amount of private information. * It would be impossible to support features such as server-side search, effectively making email search on your mobile devices impossible. Of course any solution to this problem will be a compromise between security and usability, so let's hope a number of different solutions will see the light of day, so that everyone can choose the solution that works the best for them.

wfn 13y ago
Nice, yes, thanks the reply, agree with everything. > This process only encrypts the email's body, and not the metadata (from, to, subject, headers containing IP addresses, etc). As a bunch of people have shown after the PRISM fallout, analysis on metadata alone can reveal an incredible amount of private information. I also had the idea to have encrypted containers something akin to what you are proposing, with PGP for the body underneath. It gets complicated.. Anyway, > Of course any solution to this problem will be a compromise between security and usability, so let's hope a number of different solutions will see the light of day, so that everyone can choose the solution that works the best for them. I very much agree. Here's to hoping to see multiple solutions soon :)