6 ms·

Just after the PRISM scandal exploded, I came up with the idea of encrypted-storage based email [1]. Unfortunately, within a little while of thinking of this, I

Just after the PRISM scandal exploded, I came up with the idea of encrypted-storage based email [1]. Unfortunately, within a little while of thinking of this, I read about lavabit and realized that they had the exact same security model that I was thinking of. Now that lavabit's gone, I think there is a good opportunity for someone in a sane country with good data-protection laws. [1]: http://firespotting.com/item?id=1632 http://firespotting.com/item?id=1632

option_greek 13y ago
It's very interesting. Something like this is really required. How ever, if this is a private project then people may not have absolute trust on it. If it is open source, independent verification is possible which will improve user trust. Also when malicious unnamed agents come after you through legal channels, you can drop the service like lavabit but some one else can setup an independent server and do a direct import of user data from your servers with user permission.
- captn3m0 13y ago
  My plan was to keep it open source, and have free accounts, as far as possible. The monetization could have come from extra storage, like GMail, or custom domains.
  - Xurinos 13y ago
    Every time I see the phrase "open source", I mentally add "but not open binary"; how do I know that the service that is run uses binaries that are compiled from that open source alone? with trusted libraries? After all, anyone can employ a site-specific patch in their build process that adds additional "features" to their normally open source project. Is there a reasonable way to have trusted individuals intermittently audit the service?
    - muyuu 13y ago
      A no-trust-required system would consist of taking these sources and hosting your mail yourself. Which pretty much defeats the purpose, since what you want to avoid is hosting your own email (another alternative). Honestly I lend more towards phasing out email completely. Maybe providing gateways to other protocols.
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..
zokier 13y ago
If you don't care about metadata then imho the approach presented in a blog post[1] linked in your firespotting thread is most reasonable. Most importantly the private key never touches the mail-server. If you do care about metadata then you could do some lavabitesque tricks in addition to encrypting the message bodies. [1] https://grepular.com/Automatically_Encrypting_all_Incoming_Email_Part_2 https://grepular.com/Automatically_Encrypting_all_Incoming_E...
pilif 13y ago
Considering that STARTTLS is still optional and most MTAs don't implement it, what value is there behind storing the mail encrypted? Because governments are storing every email anyways, when they want to get to my data, why would they bother asking you to decrypt it for them (which you can't) instead of just looking at the SMTP communication between $OTHERSERVER and you. With a very high likelyhood, that SMTP communication is unencrypted. Of course $EVILGUY might have encrypted their message before sending it, but then you can't help the government anyways. IMHO, as it stands currently, encrypted mail storage provides a false sense of security.
- cypherpunks01 13y ago
  Is it really true that most MTAs don't implement it? Looking through a bunch of random emails of mine (on gmail), I see version=TLSv1 somewhere in the headers, which I thought indicated that STARTTLS was being used. Am I wrong about this? Or is there some intermediate MTA that might not be using TLS in this case?
  - pilif 13y ago
    Could very well be. You can try and check all Received:-Headers, but there's no obligation that the MTA actually has to write whether TLS was used, nor can you be sure that the MTAs aren't simply adding some TLS string without actually having used TLS. Of the big email providers, only Gmail supports TLS.
- old-gregg 13y ago
  The tech required for a truly safe email lives on a client, not a server: http://en.wikipedia.org/wiki/S/MIME http://en.wikipedia.org/wiki/S/MIME
  - sorbits 13y ago
    The problem is that only the body is encrypted. Who you are communicating with (and in term, who they are communicating with) is at least as sensitive as what you are writing.
umsm 13y ago
You could always make it open-source and allow users to "download" and "upload" their mailbox. This way, when one service provider is shutdown, you can find a host and install the email system and upload your mailbox. I had a similar idea, but I have no time to execute it.

option_greek 13y ago

It's very interesting. Something like this is really required. How ever, if this is a private project then people may not have absolute trust on it. If it is open source, independent verification is possible which will improve user trust. Also when malicious unnamed agents come after you through legal channels, you can drop the service like lavabit but some one else can setup an independent server and do a direct import of user data from your servers with user permission.

captn3m0 13y ago
My plan was to keep it open source, and have free accounts, as far as possible. The monetization could have come from extra storage, like GMail, or custom domains.
- Xurinos 13y ago
  Every time I see the phrase "open source", I mentally add "but not open binary"; how do I know that the service that is run uses binaries that are compiled from that open source alone? with trusted libraries? After all, anyone can employ a site-specific patch in their build process that adds additional "features" to their normally open source project. Is there a reasonable way to have trusted individuals intermittently audit the service?
  - muyuu 13y ago
    A no-trust-required system would consist of taking these sources and hosting your mail yourself. Which pretty much defeats the purpose, since what you want to avoid is hosting your own email (another alternative). Honestly I lend more towards phasing out email completely. Maybe providing gateways to other protocols.

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

zokier 13y ago

If you don't care about metadata then imho the approach presented in a blog post[1] linked in your firespotting thread is most reasonable. Most importantly the private key never touches the mail-server. If you do care about metadata then you could do some lavabitesque tricks in addition to encrypting the message bodies. [1] https://grepular.com/Automatically_Encrypting_all_Incoming_Email_Part_2 https://grepular.com/Automatically_Encrypting_all_Incoming_E...

pilif 13y ago

Considering that STARTTLS is still optional and most MTAs don't implement it, what value is there behind storing the mail encrypted? Because governments are storing every email anyways, when they want to get to my data, why would they bother asking you to decrypt it for them (which you can't) instead of just looking at the SMTP communication between $OTHERSERVER and you. With a very high likelyhood, that SMTP communication is unencrypted. Of course $EVILGUY might have encrypted their message before sending it, but then you can't help the government anyways. IMHO, as it stands currently, encrypted mail storage provides a false sense of security.

cypherpunks01 13y ago
Is it really true that most MTAs don't implement it? Looking through a bunch of random emails of mine (on gmail), I see version=TLSv1 somewhere in the headers, which I thought indicated that STARTTLS was being used. Am I wrong about this? Or is there some intermediate MTA that might not be using TLS in this case?
- pilif 13y ago
  Could very well be. You can try and check all Received:-Headers, but there's no obligation that the MTA actually has to write whether TLS was used, nor can you be sure that the MTAs aren't simply adding some TLS string without actually having used TLS. Of the big email providers, only Gmail supports TLS.
old-gregg 13y ago
The tech required for a truly safe email lives on a client, not a server: http://en.wikipedia.org/wiki/S/MIME http://en.wikipedia.org/wiki/S/MIME
- sorbits 13y ago
  The problem is that only the body is encrypted. Who you are communicating with (and in term, who they are communicating with) is at least as sensitive as what you are writing.

umsm 13y ago

You could always make it open-source and allow users to "download" and "upload" their mailbox. This way, when one service provider is shutdown, you can find a host and install the email system and upload your mailbox. I had a similar idea, but I have no time to execute it.