4 ms·

For a couple of weeks now, I've been brainstorming about how to create a system like this. I'd very much like to use this sort of setup for my own emails, but i

by vader1 13y ago

For a couple of weeks now, I've been brainstorming about how to create a system like this. I'd very much like to use this sort of setup for my own emails, but it simply doesn't seem to exist, especially not as open source (while lavabit claimed to store your emails encrypted, there was no way for anyone to actually vet their approach). The most viable option I came up with so far is modding eCryptfs to allow "write only" mounts by supplying it directly with the derived public key for the passphrase instead of the passphrase itself. This would allow you to use vanilla components such as postfix & dovecot instead of having to write a custom application server. Using the maildir format, incoming mails could be written to the write-only mount without having to read any files from the mount. On IMAP login, the mail daemon would use a passphrase derived from the login password to mount the maildir as read-write, using unshare to ensure that the mount is visible to that process alone, and automatically unmounting it when the IMAP user logs out. Thoughts and ideas are welcome :)

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.
andrewcooke 13y ago
if you're doing this on your own hardware, why not just encrypt your entire disk? (or just a single partition, and give imap access to that alone through unix perms or, if you want to go further, apparmor etc).
- vader1 13y ago
  Firstly because I'm looking to create a solution that can be hosted centrally: the average email user is simply never going to setup and host their own mailserver and setup the encryption. Secondly: simply using a regular encrypted partition for both SMTP and IMAP access means that partition has to be mounted permanently, otherwise new incoming mails couldn't be delivered. This means if a hacker were to gain access to the system, or if a party would force the server operators to give them access to the servers, all emails would be instantly compromised.
e12e 13y ago
I still think one of the sanest ways to do this is to set up a filter that takes an email message on standard input, and outputs the same message to a Maildir/mbox[1], with the body encrypted with the recipients public key (possibly signed by a server key, but that wouldn't add all that much in terms of security, as the server key would have to be always available). 1: Probably one filter that takes an email on standard input, and writes an encrypted "copy" on standard output, and another program that takes a message on standard input and delivers it to a Maildir/mbox: #.forward pseudocode: | gpg-encrypt-to-self | deliver Optionally check if the mail is already encrypted: if is-gpg-message then deliver else encrypt-to-self|deliver fi

by vader1 13y ago

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.

andrewcooke 13y ago

if you're doing this on your own hardware, why not just encrypt your entire disk? (or just a single partition, and give imap access to that alone through unix perms or, if you want to go further, apparmor etc).

vader1 13y ago
Firstly because I'm looking to create a solution that can be hosted centrally: the average email user is simply never going to setup and host their own mailserver and setup the encryption. Secondly: simply using a regular encrypted partition for both SMTP and IMAP access means that partition has to be mounted permanently, otherwise new incoming mails couldn't be delivered. This means if a hacker were to gain access to the system, or if a party would force the server operators to give them access to the servers, all emails would be instantly compromised.

e12e 13y ago

I still think one of the sanest ways to do this is to set up a filter that takes an email message on standard input, and outputs the same message to a Maildir/mbox[1], with the body encrypted with the recipients public key (possibly signed by a server key, but that wouldn't add all that much in terms of security, as the server key would have to be always available). 1: Probably one filter that takes an email on standard input, and writes an encrypted "copy" on standard output, and another program that takes a message on standard input and delivers it to a Maildir/mbox: #.forward pseudocode: | gpg-encrypt-to-self | deliver Optionally check if the mail is already encrypted: if is-gpg-message then deliver else encrypt-to-self|deliver fi