7 ms·

I don't think Mailpile is potentially valuable because it immediately solves the encryption problem, but because it solves the MUA problem. All innovation in t

by moxie 13y ago

I don't think Mailpile is potentially valuable because it immediately solves the encryption problem, but because it solves the MUA problem. All innovation in the secure email space has been blocked for the past 13 years by one primary problem: webmail. It is simply not possible to develop a secure email solution if webmail is the only viable option for accessing mail, so most people who would be interested in innovating here don't even bother. If we can successfully make the transition back to local MUAs, however, we might have a chance to try something new. Even if we can't leverage it to get a full end-to-end mail encryption, here's why I want something like Mailpile: Right now, every single email I receive is encrypted. I have my public GPG key on my mail server, and every incoming email that's not already encrypted is encrypted using that public key. That way if the anyone compels my VPS provider for access, they just get a bunch of encrypted email. So my problem isn't receiving or encrypting email, it's reading it. The only real option I have right now is Thunderbird, which isn't great, and is no longer under development. As a browser-based but locally-hosted MUA, Mailpile might be the remedy to Thunderbird that we need.

enterthemist 13y ago
Firstly, I want to applaud mailpile for their efforts. Next, I'd like to respond to you with what our product is aiming to solve (because that is what I know best). > All innovation in the secure email space has been blocked for the past 13 years by one primary problem: webmail. We are working on solving this very problem. We do this via js crypto. The main problem with js crypto is modification of the crypto with the transfer. We aim to solve this via having a browser extension be the default js store (so that all the crypto is verifiable by outside sources). > That way if the anyone compels my VPS provider for access, they just get a bunch of encrypted email. This is also true of any service which provides end-to-end encryption (With the exception of the plaintext headers). > So my problem isn't receiving or encrypting email, it's reading it. We use SMIME for encryption which is supported by a variety of clients: Outlook, iMail, and our own client. For internet mail, as I said, we are working on browser extensions for gMail. The main problem that this does not solve is the routing and timestamp metadata problem as that is still necessary for the transfer of the email.
- tlrobinson 13y ago
  Is your browser extension a generic solution to the "browser JS crypto" problem, or specific to your application? Solving that problem would go a long way in making secure communication more accessible, but it's a hard problem.
  - enterthemist 13y ago
    Rome wasnt built in a day, as the saying goes. Our solution here tries to solve a few of the problems to start with. The goal, however, is to maintain a list of urls, sha1 hashes, update times, and a list of verifiers. The sha1 hashes make sure that the js that you have is the one being distributed (although the hash may soon be upgraded to a different one). The update times and list of verifiers are used to be able to update the code as safely as possible. The verifiers are a list of people who sign the code (with a timestamp). This is used to make sure that any individual isnt sending you a modified version of the js. Those are the goals for that compartment of the code, but as is right now, we are the only signers and so the basic point of the extension is so that we ourselves cant update your code by ourselves (you'd have to update the extension). This means that if we are forced somehow to change the js to get your key, that code will be available to anyone who wants to look at the diff where it should be staring you in the face.
    - bradleyjg 13y ago
      Is the delivered js minimized / compiled or delivered in human readable form?
      - enterthemist 13y ago
        The container is abstracted, so it can receive whatever type of js the server wants to send. Specifically, the js that we will use will not be compiled so that it can be verified (and it will also be open source). The main problem with this is that it wastes bandwidth which shouldnt be a problem for two reasons: the architecture can cache the js intelligently and the extension will have a lot of the crypto stuff embedded meaning that it wont need to be redistributed per access.
Aloisius 13y ago
> All innovation in the secure email space has been blocked for the past 13 years by one primary problem: webmail. It is simply not possible to develop a secure email solution if webmail is the only viable option for accessing mail, so most people who would be interested in innovating here don't even bother. If we can successfully make the transition back to local MUAs, however, we might have a chance to try something new The only way I can think that webmail could be secured is through changing HTTP and HTML standards to allow the web browser to arbitrarily encrypt forms and decrypt elements with keys unknown to the web server plus disable JS inspection of form elements and elements set as encrypted. I can't imagine the difficulty in getting it through the standards process let alone implementing it securely though.
spindritf 13y ago
Wouldn't Mailpile make things better even if you kept your GPG keys on the server? Sure, if the authorities targeted you specifically, they could probably pry the unencrypted keys from the server's memory (although with considerable effort it it was a dedicated or collocated machine) but widespread adoption of that model would completely stop dragnets. Only narrowly tailored investigations would be feasible, no mass surveillance.
- malandrew 13y ago
  Can't we also make a server that is physically hardened against tampering? If servers get small enough and cheap enough and only need to support one individual, then you can always try encasing that server in some material that is physically difficult to penetrate without risking destruction of the server itself. i.e. encase the server in concrete or opaque resin with a thin lead shielding to prevent x-raying of the device for precise drilling and exposing only the power leads and the network interface. As long as the network software interface is totally secure, you leave no way for any other attacks that I can think of. You could go further and booby trap the enclosure so that it destroys it's contents. At the end of the day, many of these ideas have already been explored in the safe manufacturing industry, such as glass panels that shatter upon drilling, permanently locking the safe. A glass enclosure with a strong liquid corrosive could be used around a small server. Tampering with the outer enclosure could result in likely breakage of that glass vessel, thereby destroying the server beyond recovery.
  - cdjk 13y ago
    It's called a hardware security module (HSM) [1]. The basic idea is to store the private key in the tamper-resistant hardware, along with a microprocessor to perform the basic encryption options you need. They can be relatively cheap, like a smart card + usb smart card reader, to very expensive, like an IBM 4764. Yubikey sells a usb HSM if you want to run your own authentication server for around $500. There's a whole chapter dedicated to HSMs in Security Engineering [2], which is available online. There are clever ways to attack them, and yes, the booby trap idea has been done, typically by using something light-sensitive. I'm not aware of any concrete-encased HSMs, however... It's an interesting topic. That are lots of challenges around them too. It will probably have a battery backup, so how do you allow someone to replace the battery without wiping the keys? Or can only people with access to the keys replace the batteries? That won't work if you're doing mathematical secret sharing, however, since there's no physical way to do that. [1] http://en.wikipedia.org/wiki/Hardware_security_module [2] http://www.cl.cam.ac.uk/~rja14/book.html
px43 13y ago
Have you looked into systems like Mailvelope? (similar to what FireGPG once was) Private keys are kept in the domain of a browser extension, so even if your webmail provider served up malicious javascript (via xss or court order), they would not be able to directly read the contents of your emails since they are being encrypted/decrypted in a separate domain. Ideally the crypto APIs in browsers would work nicer with hardware tokens etc, but until then, at least people can start moving towards GPG without having to trust large, scary, poorly maintained email clients like thunderbird and evolution, which tend to segfault with a terrifying frequency.
girvo 13y ago
I'm currently using Geary as my local MUA (Linux only, FWIW) -- I'm unsure if it has encryption built in yet, but I know it's on the radar, and is under heavy development. Check it out, if you're a Linux user. I replaced Thunderbird with it quite successfully :)

by moxie 13y ago

enterthemist 13y ago

Firstly, I want to applaud mailpile for their efforts. Next, I'd like to respond to you with what our product is aiming to solve (because that is what I know best). > All innovation in the secure email space has been blocked for the past 13 years by one primary problem: webmail. We are working on solving this very problem. We do this via js crypto. The main problem with js crypto is modification of the crypto with the transfer. We aim to solve this via having a browser extension be the default js store (so that all the crypto is verifiable by outside sources). > That way if the anyone compels my VPS provider for access, they just get a bunch of encrypted email. This is also true of any service which provides end-to-end encryption (With the exception of the plaintext headers). > So my problem isn't receiving or encrypting email, it's reading it. We use SMIME for encryption which is supported by a variety of clients: Outlook, iMail, and our own client. For internet mail, as I said, we are working on browser extensions for gMail. The main problem that this does not solve is the routing and timestamp metadata problem as that is still necessary for the transfer of the email.

tlrobinson 13y ago
Is your browser extension a generic solution to the "browser JS crypto" problem, or specific to your application? Solving that problem would go a long way in making secure communication more accessible, but it's a hard problem.
- enterthemist 13y ago
  Rome wasnt built in a day, as the saying goes. Our solution here tries to solve a few of the problems to start with. The goal, however, is to maintain a list of urls, sha1 hashes, update times, and a list of verifiers. The sha1 hashes make sure that the js that you have is the one being distributed (although the hash may soon be upgraded to a different one). The update times and list of verifiers are used to be able to update the code as safely as possible. The verifiers are a list of people who sign the code (with a timestamp). This is used to make sure that any individual isnt sending you a modified version of the js. Those are the goals for that compartment of the code, but as is right now, we are the only signers and so the basic point of the extension is so that we ourselves cant update your code by ourselves (you'd have to update the extension). This means that if we are forced somehow to change the js to get your key, that code will be available to anyone who wants to look at the diff where it should be staring you in the face.
  - bradleyjg 13y ago
    Is the delivered js minimized / compiled or delivered in human readable form?
    - enterthemist 13y ago
      The container is abstracted, so it can receive whatever type of js the server wants to send. Specifically, the js that we will use will not be compiled so that it can be verified (and it will also be open source). The main problem with this is that it wastes bandwidth which shouldnt be a problem for two reasons: the architecture can cache the js intelligently and the extension will have a lot of the crypto stuff embedded meaning that it wont need to be redistributed per access.

Aloisius 13y ago

> All innovation in the secure email space has been blocked for the past 13 years by one primary problem: webmail. It is simply not possible to develop a secure email solution if webmail is the only viable option for accessing mail, so most people who would be interested in innovating here don't even bother. If we can successfully make the transition back to local MUAs, however, we might have a chance to try something new The only way I can think that webmail could be secured is through changing HTTP and HTML standards to allow the web browser to arbitrarily encrypt forms and decrypt elements with keys unknown to the web server plus disable JS inspection of form elements and elements set as encrypted. I can't imagine the difficulty in getting it through the standards process let alone implementing it securely though.

spindritf 13y ago

Wouldn't Mailpile make things better even if you kept your GPG keys on the server? Sure, if the authorities targeted you specifically, they could probably pry the unencrypted keys from the server's memory (although with considerable effort it it was a dedicated or collocated machine) but widespread adoption of that model would completely stop dragnets. Only narrowly tailored investigations would be feasible, no mass surveillance.

malandrew 13y ago
Can't we also make a server that is physically hardened against tampering? If servers get small enough and cheap enough and only need to support one individual, then you can always try encasing that server in some material that is physically difficult to penetrate without risking destruction of the server itself. i.e. encase the server in concrete or opaque resin with a thin lead shielding to prevent x-raying of the device for precise drilling and exposing only the power leads and the network interface. As long as the network software interface is totally secure, you leave no way for any other attacks that I can think of. You could go further and booby trap the enclosure so that it destroys it's contents. At the end of the day, many of these ideas have already been explored in the safe manufacturing industry, such as glass panels that shatter upon drilling, permanently locking the safe. A glass enclosure with a strong liquid corrosive could be used around a small server. Tampering with the outer enclosure could result in likely breakage of that glass vessel, thereby destroying the server beyond recovery.
- cdjk 13y ago
  It's called a hardware security module (HSM) [1]. The basic idea is to store the private key in the tamper-resistant hardware, along with a microprocessor to perform the basic encryption options you need. They can be relatively cheap, like a smart card + usb smart card reader, to very expensive, like an IBM 4764. Yubikey sells a usb HSM if you want to run your own authentication server for around $500. There's a whole chapter dedicated to HSMs in Security Engineering [2], which is available online. There are clever ways to attack them, and yes, the booby trap idea has been done, typically by using something light-sensitive. I'm not aware of any concrete-encased HSMs, however... It's an interesting topic. That are lots of challenges around them too. It will probably have a battery backup, so how do you allow someone to replace the battery without wiping the keys? Or can only people with access to the keys replace the batteries? That won't work if you're doing mathematical secret sharing, however, since there's no physical way to do that. [1] http://en.wikipedia.org/wiki/Hardware_security_module [2] http://www.cl.cam.ac.uk/~rja14/book.html

px43 13y ago

Have you looked into systems like Mailvelope? (similar to what FireGPG once was) Private keys are kept in the domain of a browser extension, so even if your webmail provider served up malicious javascript (via xss or court order), they would not be able to directly read the contents of your emails since they are being encrypted/decrypted in a separate domain. Ideally the crypto APIs in browsers would work nicer with hardware tokens etc, but until then, at least people can start moving towards GPG without having to trust large, scary, poorly maintained email clients like thunderbird and evolution, which tend to segfault with a terrifying frequency.

girvo 13y ago

I'm currently using Geary as my local MUA (Linux only, FWIW) -- I'm unsure if it has encryption built in yet, but I know it's on the radar, and is under heavy development. Check it out, if you're a Linux user. I replaced Thunderbird with it quite successfully :)