There is no such thing as secure email. Assume everything is being read.
You can't bolt security on (SSL, mailbox encryption, PKI). You have to design it in from the start. SMTP/IMAP etc have crudely hacked on TLS implementations which aren't even guaranteed to be operational site to site. PGP is just an encapsulation which is rarely used.
It's a mess.
This is just a repackaging of the pile of hacks.
We need to start again and do it properly and consider: encryption, modern content encapsulation (better than mime), authentication, PKI, secure storage, mandatory authentication/authorisation and SPAM control.
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.
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.
Regardless of how safe it is, the problem is still social engineering hacks, key loggers etc (you'll always have this issue) - just wondering to what lengths a government will go...
Some key differences are that we do not store your emails, your email provider does. We do not ever, at any point, have access to your unencrypted keys. Therefore, we cannot, even if forced to turn over access to your data. That being said, as with all secure systems there may be bugs. The client however, is (will be) open source so that everyone can help solve whatever problems that may arise. The key point is that the architecture is set up so that we dont ever need access to your keys or data.
So now I really don't understand how this is any different from using Thunderbird and EnigMail/PGP to encrypt your mail - and if I've understood correctly then it actually isn't any different, you are just providing a glossier interface.
I think it's a worthwhile project, but beyond the tech community, I'm not entirely sure how much traction usage will get... Thunderbird/Enigmail is a PITA to setup and use for sure. A step in the right direction, but all m00t unless everyone is using encryption and it becomes the defacto when communication via email.
It is different in that it creates a key distribution interface for the average person. This interface allows things like decrypting emails in the browser and transparent security. It also allows you to know who has security and who doesnt (this allows people to incrementally start using encryption without the headaches of wondering who else is using it). These are problems that are not solved with any PGP type interface today.
I think that what you are missing is that the server stores encrypted keys, rather than no key.
Lavabit had a similar architecture, only with the password could the server-side email be unencrypted. Although we don't know for sure, it appears that the government insisted that they trojan their client side code to retrieve the password.
Your secret sauce, if I understand it correctly, is open sourcing the client side code and providing some mechanisms to assure end users that what they are executing matches the publically published code.
That makes sense to me, but I don't see why you wouldn't go one step further and store the secret key in the browser plug-in. Is it an multiple-installation issue?
> Your secret sauce, if I understand it correctly, is open sourcing the client side code and providing some mechanisms to assure end users that what they are executing matches the publically published code.
Yes, the js client is fully intended to work exactly this way.
> That makes sense to me, but I don't see why you wouldn't go one step further and store the secret key in the browser plug-in. Is it an multiple-installation issue?
There are a few issues here.
1. The first is the general crypto principle: minimize your TCB. I want the key to have to touch as few places as possible. For this reason, I have plans on moving the keys from the server to a clients machine(s). Doing so, however, involves a lot more problems including: NAT and the lack of a fallback. In the future, when I have more time to work on these details, I want to try and make that an option for people.
2. Another problem with placing the key in the browser is as you say: it allows anyone who is able to access the browser to access your key (including malware and other users).
3. Lastly, where would this key come from (remember rule #1: the server never has access to an unencrypted key)? If it is generated on the local machine that would then mean that you have no way of distributing it to your other machines (or at least not in ways that your grandmother will be able to do). Even if there were some super snazzy interface, it would be prone to attack as well.
Thanks for the response. I would look back at some of the articles that came out on the imessage protocol several months back. They face a similar key distribution problem given that iMessages can potentially be delivered to multiple devices. I don't remember if the reverse engineering ever figured out exactly how they cracked that nut, but I seem to remember that there were some reasonable hypothesis.
I imagine that you can then solve those other problems one at a time by implementing alternatives in your webmail client. The interface to the user can stay the same, but you can add additional more secure transports underneath that the client can opt to use when there is indication that the person they are communicating with uses a mail system that supports that upgraded security solution. In the interface, you just need an indicator of what information is being leaked on a recipient by recipient basis.
At the end of the day this is how filesharing evolved... from FTP to Napster to Kazaa to Torrents to Magnet links. They slowly solved each of the attacks out there.
You are probably correct. In fact, our solution allows for this type of checking explicitly so that we can (when possible) migrate to better protocols. Interestingly enough, I like your analogy because in all honesty, email is simply file sharing with routing and in path storage.
JS crypto makes sense, but I'm confused as to why a browser extension is necessary—you can safely deliver the JS crypto solution over an https connection, so the critical component is keeping the user's private decryption key distinct from their login/password.
Seems a shame to depend on a browser extension—you lose most of the advantages of webmail when you can't log into it from anywhere.
The usual argument against JS crypto is that a compromised (either technically or legally) host could send a malicious version of the code to steal your keys/data.
A browser extension could in theory be used to verify the code against a signature or something to that effect, or it could sandbox the crypto routines and keys from the app itself (though that wouldn't prevent the app from stealing the decrypted data)
What needs to happen for this to become generally usable is for the crypto part to be built into the browser - that way you only need to trust your browser and not a somewhat random plugin, nor the .js being served from a particular server.
And it'll "just work", so ordinary people have a chance to use and trust it too.
Sure, eventually, however I'd be just as comfortable using a plugin from, say, the EFF as I would having it built into the browser. It would be a fine stepping-stone (similar to how Google Gears contained many features which influenced HTML5)
And as I mentioned, merely having the crypto parts and key management built into the browser isn't good enough because a malicious site could still trick you into decrypting data which it could then steal, even if the keys themselves are perfectly safe.
As tlrobinson says, the problem is that we dont want you to have to trust us. One of our goals is to minimize the amount of trust you have to place in us. Therefore, we want you to be safe if we are forced to try and steal your keys. See my other comment for more info: https://news.ycombinator.com/item?id=6245617
Gotcha, makes sense. Still, I wonder if there might be a clever solution which exploits the same-domain policy to isolate the decryption activity from the rest of the app. That would considerably reduce the attack surface if it handles collecting the key and then you just postMessage strings back and forth.
As you hint at in the other comment, there are various ways that third-parties could vouch for the code running on the decryption domain.
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.
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.
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.
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.
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.
As far as some of the issues you raised like battery replacement, I would treat them as disposable. In the next few years a complete computer will be available for so little that we will consider it disposable. Prepare a server once, enclose it, make sure the only way in or out is an SSH connection. When it's time to set up a clone to replace it, clone everything via an SSH session and trash the first server.
That could work, but the advantage of an HSM is that the key material is physically prevented from leaving the device, barring acid/x-rays/other attacks. All encryption happens on the device itself. With an open ssh connection you could still remove the key material from computer.
Only the public key should be stored on the virtual mail server, since all it's doing is encrypting incoming mail. It's your local email client (e.g. Thunderbird) that then downloads the encrypted emails to your local machine and decrypts them with your private key. Signing and outgoing encryption are also done locally. At that point, all that someone raiding your VPS gets is a bunch of encrypted messages, which good encryption is supposed to make worthless, and your public key, which they should already have (along with everyone else).
Sure, your local machine could also be raided and the keys grabbed from that, but that's not a problem with using a VPS so much as a problem with your local setup.
This is pretty much the reason that Silent Circle shut down their email product. Their other offerings use custom protocols with full end-to-end encryption (and are still up and running), but for email, they were trying to interoperate with the legacy stuff, which left them handling plaintext in some cases.
It's also the focus of some of the speculation about the unknown demand that triggered the Lavabit shutdown.
> 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.
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.
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 :)
Lots of people are thinking about the problems we have right now.
I have been thinking of the following and want to get some feedback on the idea:
ComBoxen! Comm box is a VM image that, when run, launches with a set of services that allow fully encrypted communications between other ComBoxes.
Basically a secure linux distro on full lockdown that will register with a central directory only to state it is online. Messages are directly passed between comboxes when both are online. Messages are stored locally on the Combox until a secure direct connection can be made to the recipient.
The whole VM could be a stripped down truecrypted message store that only talks to others on a trust list.
Interesting idea. Instead of a VM though, what about a small, low-power box that you plug into your home network that handles secure communication transparently to the user? I'm thinking something like AdTrap (http://www.kickstarter.com/projects/600284081/adtrap-the-int...) but for email or other sorts of communication.
Why the need to sell hardware? I can accomplish what AdTrap does using a USB stick or SD card and any old i386 hardware I might have lying around. You might call this a "System on a Stick". It boots from the USB/SD media and runs in RAM (no hard disk is needed). You set your other devices (running your favorite graphical OS's) to use it as a gateway/router.
It can block ads. Easily. I do this via DNS and it works like a charm.
But that is only one of many things it can do. Could it establish secure end-to-end connections with other people running the same System? Of course. Could you form your own overlay networks? Yes. Could you run email on top of these overlays? Yes, you could. In fact, you could run almost any program over these networks that you could run on a LAN.
This has all been possible for many years. More than a few people know how to implement it.
Whether there is consumer demand (cf. enterprise demand) for this solution is an open question. At least, so I thought.
There are certain advantages to custom hardware. For example, the OS could be flashed onto a tamper-resistant ROM to prevent it from being surreptitiously altered. The device could include a smart card slot used on boot to decrypt the storage mechanism. And the device itself could be very small, light, low-power, and fanless, perfect for stashing out of the way next to your modem.
There's also advantage in offering up a single appliance for people that don't have the technical expertise to set up the necessary services on their own, who don't have a spare i386 they can use, or even people who just want something to work without spending too much time on it.
Secure communication requires parties on both sides to be capable of it, and it stands to reason that more people would buy into a system that provides the capability if you make it really easy to use. Of course, the communication network itself should be fully interoperable with whatever hardware you want to use to connect to it.
All good points, none with which I would disagree.
The System on a Stick could only be surreptitiously altered by remounting the root device as read-write. This is difficult for any non-technical user to do without instructions.
The System on a Stick is fully preconfigured. Insert Stick, turn on computer and away you go. It is every bit as easy as a new piece of hardware with its OS and configurations flashed on ROM.
I do not see a small, low power, fanless device as being incompatible with a System on a Stick. Plug computers or credit card sized computers should have slots for USB sticks, SD cards or CF cards. And they should be able to boot from them (no on-disk bootloader needed).
Not every consumer may be ready to make a purchase of new hardware. Evidence of this is the fact there are a suprising large number of people still using what we would consider "old" hardware. Desktop PC's in fact. Regardless of a consumer's appetite and budget for new gadgets, certainly they can afford a USB stick, SD card or a CF card. They probably own one already. They might even have a CF card left over from the days when digital cameras used CF cards. The System on a Stick will fit on a 16MB card.
I would imagine most people indeed currently have some i386 hardware, either a PC or a laptop. Thus they have what they need to try out the System _right now_, without making a new hardware purchase. When they eventually make their next hardware purchase (maybe an ARM tablet), they will then have spare i386 hardware.
As the System can run without touching the disk, there is no install anything. It can be used on i386 with OSX or Windows installed without affecting those systems. A user can perform tests of end-to-end connectivity and communications using any smartphone with a web browser.
I like the sound the AdTrap Kickstarter project. An additonal computer ("router") that sits between the user and her modem is I believe the right way forward for solving problems of privacy (e.g. blocking ads) and security (e.g. secure communications), not to mention other increased functionality. I simply wanted to point out that purchasing new hardware is not necessary to get started.
Whatever shape or form that router takes, I think it must be bootable from external media with the bootloader of the user's choosing. Any less means we are purchasing yet another closed system and putting someone else in control. By all means make this router function without any user input (turn it on and you're done). But by no means should the ability of the (more conscious) user to fully control the router be limited. That means open source OS and open source bootloader.
I've had similar ideas for a long while. My flavor is using the router as an encrypted protocol gateway and some other centralized user queues. The centralized queue would hold encrypted messages for first time connections. Subsequent messages could be delivered p2p utilizing the fact that most people's routers are publicly available 90% of the time. A local standard mail client connects to a trusted mail server (router) for short haul com (LAN). For long haul, an app could be developed to decrypt the messages locally.
Yeah, I have been talking about this with people for some time - and while the idea of a box is great - and needed for the long term, a VM is ideal to begin with because it can be widely, swiftly and freely distributed.
Further, I was thinking of the following scenario for message validation - (this is just a thought experiment, so it really needs some critical examination I am not sure this even gains one anything):
You run two instances of your VM. One is run locally to you - another is hosted. When a message is sent to you from another peer - it must reach both the hosted and the local one to be opened. When both instances are online at the same time - a hash is shared of the message between both instances and the local master can trust and open the message.
When you're locally off line and a message is sent - Thus, if your locally offline - your hosted instance receives the message. When you come online - your local instance will receive the message from your hosted instance AND a hash from the senders hosted instance. If the hash from the sender matches the message hash from your hosted instance - the message is trusted and can be opened. Else it is dropped.
The problem is that all these p2p secure connections can still always be slurped.
The addresses are only within the system and one would never know which hosted instance belongs to what actual address.... (This area needs a lot more thought)
And when someone connects to a Commbox, how can they tell (across the network) whether it's operating as described, or an imposter box reporting to the bad guys while pretending to be trustworthy?
This is a problem for a lot of these ideas, not only yours and mine (see my other post where the difficulty comes down to verifying the server).
Logically, the solution would seem to be a tamper-proof (or tamper-evident) hardware subsystem, working much like the evil, so-called "Trusted computing" scheme, except with the owner having full control of all the keys.
See my other post in this thread, where I posted the following. Which, please, tell me if this would work or not:
>You run two instances of your VM. One is run locally to you - another is hosted. When a message is sent to you from another peer - it must reach both the hosted and the local one to be opened. When both instances are online at the same time - a hash is shared of the message between both instances and the local master can trust and open the message.
When you're locally off line and a message is sent - Thus, if your locally offline - your hosted instance receives the message. When you come online - your local instance will receive the message from your hosted instance AND a hash from the senders hosted instance. If the hash from the sender matches the message hash from your hosted instance - the message is trusted and can be opened. Else it is dropped.
The problem is that all these p2p secure connections can still always be slurped.
The addresses are only within the system and one would never know which hosted instance belongs to what actual address.... (This area needs a lot more thought)
> You can't bolt security on (SSL, mailbox encryption, PKI). You have to design it in from the start. SMTP/IMAP etc have crudely hacked on TLS implementations which aren't even guaranteed to be operational site to site. PGP is just an encapsulation which is rarely used.
They are proposing making an email client that uses PGP. PGP does in fact let you bolt security on and end up with passable end-to-end security. Sure it has its problems (still a single public/private keypair, leaked headers), but it is, for lack of a better phrase, pretty good privacy.
Now I don't know why this is different than all the other email clients that support PGP. I use Mail.app with https://gpgtools.org/ and it works just fine (though I can't figure out how to keep it from signing every single message I send :/).
Silly question: If you can trust DNS, and require every client to connect to an SMTP server with TLS/SSL, and only permit SMTP server->SMTP server connections over SSL, how does that not fix the problem?
End to end encryption and MITM countermeasures should solve the issue, no? Then all the NSA knows is which mail server is talking to which mail server.
I admit, I could be very wrong. Please tell me why.
Well (E)SMTP works effectively by connecting, then knocking on the door and asking for a list of capabilities (EHLO). When the remote SMTP server says "no I don't support TLS", what are you supposed to do?
Email only works at the moment because in this scenario, usually the sending MTA just says "what the hell" and delivers it over the wire in plain text anyway.
The moment you force TLS as a requirement, the internet starts having lots of large black holes in it due to the number of SMTP servers that don't support it (still) or don't have valid certificates. At that point email fails.
However, the moment you agree to it, you are at the mercy of the root PKI (certificate authorities) who aren't necessarily all that trustworthy. Any fucker can buy an SSL certificate and masquerade as someone else. Also don't forget that CRL (revocation lists) exist that list naff CA certs that have been compromised. At that point, encryption fails.
That's why it's fucked - whack-a-mole all over the place.
"Well (E)SMTP works effectively by connecting, then knocking on the door and asking for a list of capabilities (EHLO). When the remote SMTP server says "no I don't support TLS", what are you supposed to do?"
If the DNSSEC secured DANE records specify that connections to this server must be encrypted, then I guess at that point, you drop the connection and bounce the message back to the sender.
I know of at least the Exim and Postfix projects which are both working on adding DANE support to their MTAs.
Also, even without any certificate verification, opportunistic SSL is extremely useful. It may not be able to stop targetted surveilance, but it can sure stop a large chunk (most?) of the dragnet style surveilance that has recently been reported.
We should do the best we can with our current system until a new system is deployed. We don't know how long we'll be waiting.
DNSSEC+DANE is fine and all that, but that's another layer of hack job on top of another lacker of hackjob. It's turtles (or turds in this case) all the way down.
The fact that a simple delivery stack turns into a mish-mash of SpamAssassin, virus scanning, DKIM, DNSSEC, DANE, SPF, PGP, certificates, CA's, numerous ports open, severla products and many more TLA's is the problem.
I would say it’s patching a hole, and it’s the feasible way to make email secure, rather than throw it all out and convince the world to switch to a new system.
Most (internet) standards evolve this way. That’s the curse of evolving a standard that is already in widespread use.
Mostly because it rests on CA's and if the government can compel the CA to give them a signed cert for something that your security relies on, all they have to do is pose a MITM attack and you're blissfully clueless that they're spying on you. The whole system is broken and if you don't fix the foundations upon which your house is built, no amount of band-aids are going to keep the walls standing.
I think that's the problem though. My browser connects to Gmail with SSL/TLS/HTTPS. The internet community moves fast when we decide something (Goodbye support for Internet Explorer 6!), why can't we decide on this:
You will use a mail client that requires SSL to connect to our mail server, or one that does support SSL will be provided for you.
Would you ever allow fallback to HTTP of authentication or credit card data? NO! It is time for unencrypted mail transport to die.
GSM communication is actually encrypted [1], albeit lightly.
I remember having an unencrypted NMT handset and ditching it circa 2000 in favor of a GSM handset. NMT support was dropped by my service provider 3-4 years later.
So transitions like this are definitely possible, though not overnight. Remember the slow introduction of https.
You're forgetting POTS lines. I can call someone on a POTS line, with a 1992 handset, and it works the same as if I called someone with a brand new GSM phone.
Right. But at the same time, you don't see any of the forklift upgrades that have gone on behind the scenes. All the GSM<->POTS or long-distance POTS calls? They're all being converted to VoIP at some point (private network, but still IP).
Then all the NSA knows is which mail server is talking to which mail server
Unless they have backdoor access to one of the mail servers themselves (e.g., apparently, gmail).
Even without that, knowing "which mail server is talking to which mail server" could be enough to get a good amount of information. This would be especially true if you're using a relatively small mail provider (like Lavabit) or especially so with your own dedicated mail server.
Did you read what Mailpile is doing? Basically making PGP easy to use which solves the lions share of the issues at stake here with the NSA and your complaints.
Yes. Being a bit Theo de Raadt here, but it's a stupid proposition which makes security guarantees that are disingenuous.
a) This assumes that everyone is going to be using Mailpile or something which makes PGP easy to use. This is unrealistic. The moment you fart out an email to gmail, it's useless.
b) this assumes people actually understand PKI. This is unrealistic. Most people can't even manage their own data let alone a mail server hosting environment or a private key securely.
c) Security is still optional. It uses the same insecure protocols as a baseline.
d) It doesn't solve endpoint / mailbox security.
e) There is no technical information or credibility. It's not been field tested, no security reviews have taken place.
f) PGP only encrypts the contents, not the envelope. The envelope is enough to warrant digging out the $5 wrench and whacking you with it until the key appears.
I'm proposing verifiable mandatory protocol level encryption and authentication end to end (MUA to MUA) which is the RIGHT solution. If there is the ability to plausibly deny a message then that's even better (which goes against sender verification so this should be choosable).
The only thing going for it is it looks like a reasonable webmail client (probably better than roundcube)
I've spoken to one of the Mailpile guys on twitter, and his answer was that they're trying to improve adoption and implementation of existing standards, before they look at improving transports.
Giving their timescales are already measured in years, I don't think Mailpile will significantly change the game. Kudos to them, but they'll just be Yet Another Commercial Pseudo-Secure-Email Seller.
I agree that the problems are inherent in the protocol. Ideally I'd like messages to have exactly one cleartext field - "To" - and servers to be dumb async routers communicating over encrypted channels. Make it computationally expensive, I don't mind: it will send us back to '90s-style "wait for POP download" timeouts, but if it's the price for half-decent security, I'll pay it.
Jk, the main difference is that mailpile wants to be fully web-based, whereas Enigmail is a fat client. I guess they plan on working heavily on key generation and storage (which is typically the sore point in tools like Enigmail).
Exactly this. Mailpile sounds like a good idea in principle until you start looking at the underlying tech. They explicitly say they will not be implementing a MTA. Since an eavesdropper knows who youre sending to and what the subjects are youre a bit vulnerable to a literal brute force attack: http://xkcd.com/538/
It seems to me the mailpile people are quite aware of what they are building and do not oversell their product. They even talk of risk assessment right in the indiegogo webpage.
Regarding your points:
a-d) I assume that mailpile to mailpile communications will be PGP armed by default. It's enough for them to clear this unambiguously (for instance with a STAR next to "secure" addresses or a popup that says "you are sendind a message to a gmail account, be aware that...)
e) alright
f) there are other quite trivial ways to protect identities, such as a pen-name and a starbucks connection. Those are quite useless, however, if the message is not encrypted.
From: anonymous_acct_101@mailpile.is
To: anonymous_acct_77@mailpile.is
Mime-shit....
DEFKJiwfou3hoqwdnhoqiwfhoqifowqihwqoidhqwod==
This is quite a secure message and it would be as easy to send as any other email with mailpile or similar services. My point is that security is not a black&white concept. There is a continuous of security, and part of the job of mailpile could be to give a "security score" to your message before you hit the send button, similarly to what we do when we calculate entropy on password and give a "security score" on the password. A password with a good score does not guarantee the security of your login but at least it will help you understand more about the entire process.
No. That really looks like another anon.penet.fi. If that is the case, then if 101 (let's call 101 Alice) or 77 (let's call 77 Bob) are using providers that are in bed with the NSA, the NSA can easily still grab the metadata from this.
If Mailpile is the MTA, and the NSA is following the connections to Mailpile's servers they can use time correlation to find out the metadata.
Metadata is hard to hide^.
Anyway, as the other posted mentioned, the correct solution is definitely full security across the board, with full encryption MTA->MTA. That needs to happen so it can't be sniffed on the wire. But of course full security between Alice's MTA and Bob's MTA is ultimately pointless when Bob's MTA (e.g. Gmail) is sleeping with Evan (the NSA).
The actual message contents need to be decrypted with keys that only the recipient has access to, and GPG is as good a solution as any for that. You can only trust what only you have. Don't trust Google. Don't trust Mailpile, either.
^ anon.penet.fi was an OK solution, but still was subject to possible timing attacks (and legal attacks since a table exists SOMEWHERE in the universe that correlates your name to your nym).
A nym.alias.net solution is better when you're chaining remailers and using random timing delays.
Deadrops are better, post your message anonymously to a newsgroup/forum/etc via a Tor or other anonymous connection, and your recipient does the same to retrieve the message anonymous. There's no metadata there to capture.
So, Alice encrypts message with Bob's public key, that's EM1.
Then Alice encrypts EM1 with the server's public key, outputing EM2. And sends that to Bob thru the MTA.
The server decrypts EM2 revealing EM1 and some plaintext metatdata arbitrarily specified by Alice.
The MTA random-delays to keep them all out of order, and sends it on to Bob with encrypted body, whatever Alice felt like putting in the plaintext metadata supposedly representing the prior travels, and no attempt to disguise the MTA's IP, etc..
NSA now can see Alice's post to the MTA, but none of the mails coming out of the MTA match the text of Alice's email. The best the wiretapper can do is decide "someone in set A sent to someone in set B", and maybe apply statistical analysis. It is easy for the wiretapper if there are only a few people using this and hard if there are a lot.
The objection will be, but NSA/FBI etc. will trojan the code, coerce the secret keys, make the server deceive users. So the server owner would like to put in something that makes it all unavoidably, and conspicuously break if the code is compromised. Securing the latter behavior remains a problem when the adversary has, one must assume, physical control of the server.
You just described more or less the behavior of how a nym.alias.net address worked back in the day, which had the added benefit of not even knowing who you were, because you chained as many remailers together as you wanted.
Metadata is most hideable (but still exists) in a crowd. At scale (i.e. millions of users) an improved version of shared shared mailboxes like alt.anonymous.messages can be effective. I reckon that it can be effective at a lesser scale if initial participants all generate enough random noise to protect anonymity of the first users to adopt the system. Once it has scaled in users, they can scale back the random noise generated.
@Harry I've drawn the same conclusion, the only secure method is MUA to MUA... it seems like you're on the same wavelength. We should talk. How can I contact you?
Except it doesn't solve the traffic analysis problem. It doesn't because it can't. Out of the list posted by the GP the following aren't fixed by mailpile and can't be because it has to use SMTP:
Ultimately we need something that is a cross between Skype's old decentralized architecture and alt.anonymous.messages.
We can now stream videos of a few gigabytes with a large enough swarm. That should be enough to create large shared mailboxen among several hundred random people that lasts about a month at a time, at the end of which your mail program would automatically mail all the people in your address book at their anonymous addresses informing them of the next large anonymous mailbox you'll be using with other people.
Everyday, your mailclient would download the entirety of all new encrypted messages for your peer group and would parse out your messages using your private key.
Let's say that every shared mailbox is capped at 10GB of total shared mailbox space. Every peer in the swarm using that mailbox replicates that mailbox. Once that mailbox hits 9GB of total messages, your client attaches to a new 10GB mailbox being created with a random set of N strangers. It then takes the address of that new mailbox and mails all your contacts a special kind of "update your address book" message with a new mailbox address and a new private key. Upon receiving that message, their client now knows to send any messages addressed to you to the new mailbox and use a new private key.
This approach makes it nearly impossible to perform social network analysis because your address essentially betweens a cross between that shared box and your private key that only you have.
There has been work done de-anonymizing alt.anonymous.messages [0], but a lot of the attacks all relied on the small number of participants on alt.anonymous.messages using that same shared mailbox over many many years. At scale with many more participants and automatic mailbox rotation, these types of attacks become far more difficult.
Won't mailbox rotation enables attacking it by comparing users in different mailboxes - the users who stayed over some time in shared mailboxes , probably want to communicate with each other ?
And few hundreds is a pretty small group if you want anonymity.
And according to the presentation in the link you gave(very interesting work on the subject of anonymity) - if messages are posted correctly, using the right tools(mix networks, nymservers) and those tools are developed to high enough quality(which is not the case today) , and enough people are using the service , the anonymity achieved can be very high using standard mailboxes.
I would imagine that any shared mailboxes should be capped to force mailbox rotation at the exact same time. Once a mailbox hits a predetermined limit, all the peers refuse to accept additional messages. Basically the exodus of users from a mailbox should happen all at the same time. Those users then randomly choose any of the other new mailboxen out there being formed. You would never be with the same cohort from one mailbox to the next. A few hundred randomly allocated and rotated monthly should help. I need to go back through that presentation again. Anyone thinking about anonymity should read it. It's brilliant.
The other thing we need is a way to easily handle multiple keys so that if one key is comprimised then we only get up a small amount of data. Ideally we would want one key per contact, but this of course would be prohibitively expensive computationally because I'd have to compare every message in that 10GB against every key I have per person. However being able to have maybe a half dozen public keys randomly distributed among your contact list would help. A totalitarian government forcing key disclosure with the threat of jail time would have to have all your public keys to determine whether or not you have disclosed all the information you have received. This would do the same for shared mailboxes as Truecrypt did for deniability that additional partitions exist. You can even distribute your keys among the different bootable Truecrypt volumes you have.
At the end of the day, public key disclosure shouldn't be a lookup but a give a key, get a key system. Basically, I would submit a new public key to you via some secure web interface
which would deliver a one time message to you at the shared mailbox you're using. At some later date, you generate a new public key for communicating with me (or use one of your current keys in rotation) and send me a message that contains the address of the mailbox I'm currently using and that key which I should use until I revoke it or issue a new one.
Ultimately we need a system that disguises how many people we are communicating with, partitions those people with multiple keys, that affords me plausible deniability since an attacker wouldn't know how many keys or mailboxes I'm using and where the level of security I am afforded is only bounded by the disk space, bandwidth and CPU time I'm willing to throw at the problem. This scales with paranoia.
On top of that we need a system that provides us temporal security. If all my files and communications are partitioned cryptographically by date, I can aquiesce to a warrant that specifically details the dates in which they are interested instead of giving them everything I have. If they have a specific crime they are investigating (which they should have), then they should be able to state the specific date ranges that contain the evidence they are looking for. This prevents fishing for dirt.
I think forward security is the equivalent of temporal security, in a sense. You can't give anything from past, unless you saved it. The problem it does need secure key exchange, which only work over low latency networks, and low latency anonymity networks, like TOR , have their limits. In a similar fashion , i'm not sure how key exchange for temporal security will work over mail.
Regarding multiple keys: Using multiple emails/nym accounts gives you that.
Agreed, I've been trying to consider an end to end solution. A single site by a single company is a bad idea... easy to shut down... PGP encryption at the client requires delivery of public keys from the desired recipient, but potential man-in-the-middle attacks mean you can't even trust that the public key you're receiving is from the recipient you think it does, your mail server could act as a go-between on behalf of your client software to go get the public key for the recipient, but that's not safe either. In the end, when nothing electronic can be trusted as sacred, how do you encrypt in such a manner as your recipient can decrypt it reliably without it being insecure... plus, if you encrypt messages end to end, how do you handle the issue of SPAM?
There are many challenges to overcome and basically as you stated, the whole concept of email needs a complete overhaul. It needs to be secure, distributed and open source.
Unfortunately, much as I'd like to claim the expertise to be able to put all this together, I would need a team of experts to help me solve the problems any solution is going to face and get it to market. This is by no means a one person job, the challenges are hard-to-solve problems and the solution needs to be usable. The reason that nobody encrypts their email now is because the payoff isn't worth the headache of trying to understand what needs to be done. I'm struggling to understand what I need to do to get GPG installed on my computer for crying out loud.
In encryption there is no "good": it is either "perfectly working" or "fundamentally compromised".
If there is only a small flaw in an encryption system, be assured that it will be exploited to break down the whole system. A simple example are all the issues with random number generators producing not perfectly random numbers; yes, it is just a slight problem in an otherwise good solution but that problem completely debases the overall system.
Yes gioele, I know. But we're not talking about flaws in the mailpile cryptosystem. Obviously their implementation of GPG will have to be professionally vetted. The other flaws (vulnerability to traffic analysis, reliance upon the recipient to store the message contents securely), are, to put it mildly, very hard to solve with email in its current incarnation. Taking the piss out of the mailpile folks because they don't solve these issues seems churlish at best.
With luck, they'll deliver a good, self-hosted gmail replacement with a secure mail store that's easy for folks to install on their own. That's surely a step forward.
Not really. NSA already use their mail mass-dumps mostly for aggregated analysis, to pinpoint networks of interlinked individuals which they can then pass to other agencies for parallel construction.
Mailpile will not change that.
At the very least, we need metadata encryption right about now.
I don't disagree with your last statement, but I also wish to point out that there are, believe it or not, other reasons to encrypt email that do not involve the NSA.
I have no desire to solve the problem. If I wanted to be an evil terrorist and blow shit up, which I don't, I'd quite happily do it without communicating with people.
Actually, I don't believe you when you say you have no desire to solve the problem. Your referenced comment suggests otherwise.
Taking the piss out of the mailpile folks is probably professionally satisfying, on some level, but I think you have to admit that, once your done, we're still left with a fundamental problem. Your objections are perfectly correct, but surely you can appreciate the frustration when folks who should know what they're doing can only contribute a, "well, someone else should design a new email system with these features." Thanks for the help.
Yes, it is not perfect. Yes, traffic analysis is still a problem. Yes, it has not yet been vetted (because it doesn't really exist yet, which I think you have to admit is a pretty good reason). Still, it's better than flapping your arms about, helpfully declaring, "THE PROBLEM IS UNSOLVABLE!!"
We have options already, although we abandoned them once the Internet became ubiquitous. UUCP would allow encrypted envelopes that would only allow trusted nodes to decrypt enough to forward to the next destination or to the local user.
It would be ungainly, especially at first, and just as easy to scoop associations between users (although, not subject lines or other metadata) by tracing the limited paths. As a critical mass were achieved (yay network effects), along with peer-to-peer sharing, you could source route your messages to anyone.
Given this message:
From: reeses
To: hagbard
Subject: fnord
Please immanentize the eschaton at your earliest convenience.
I could route it through the equivalent of a bang path (foo!bar!baz!bob), each step of which is a trusted node whose private key(s) I have in my routing table. Instead of bang paths, however, the envelope could be something as simple as:
baz would receive the "Ardhrcbeebdhvfdhnzrfgdhvqbyberzvcfhzdhvnqbybefvgnzrg,pbafrpgrghe,nqvcvfpviryvg" blob and unwrap it, forwarding it to bob, who would have exchanged keys with reeses.
Multipath routing and multiple recipient support would be possible by having additional Next: headers and the encrypted blob would serve as a sufficient identifier, or input into an identifier generator, to deduplicate messages if a transmission fork were coalesced.
This is off the top of my head, so it's wrong in a bunch of ways, but it's a simple model that could easily be deployed among circles of people who need a degree of anonymity. As in the later days of UUCP, with comp.mail.maps and the like mapping a combination of FQDNs to named hosts, initial, intermediate, or terminal nodes could involve forwarding over (E)SMTP. (foo!{bar|baz}|quux|reeses@example.com) would route through a number of machines, and the message in my inbox would look like the following:
Again, at the beginning, it would just be necessary to know about quux (or just the message fingerprint) and monitor its traffic to identify reeses@example.com as someone up to no good and watch for sidechannel communications to create a correlation between conversants. "Hmm, reeses received a message at 3:14pm from an unknown source. Ah, he received a phone call from 415-555-1212 at 2:58pm and called that number at 3:18pm." Multiple transmission sources, split messages (torrent file pointing to message, etc.), unconventional channels, and the like could wrap enough layers of encryption (and yes, STO) that the feasibility of a timely interception of content would be significantly reduced.
Amusingly, it seems like we've come full circle to the early days of Linux when getting your own domain was the definition of hardcore (and Linux itself typically involved booting from floppy).
timely interception of content would be significantly reduced
The thing is, most people are not interested in such security because they don't see themselves as engaged in a race against government surveillance. You want privacy on general principles, that makes perfect sense. But if you're proposing obfuscation of message paths as a temporizing tactic, it becomes attractive of attention because the naturally question to ask is 'what's the rush, exactly?'. If anything, this gives ammunition to the proponents of 'ticking time bomb' scenarios, notwithstanding the inherent flaws in their arguments. I don't really think that the smart response to their claims is to propose that everyone carry loud mechanical alarm clocks, for the same reason that the 4th amendment is not best upheld by advising everyone to carry miniature safes.
Oh my, the miniature safe analogy was one of the methods I used to try to explain to my wife why messaging privacy was an issue. :-) "OK, I don't know the combination, I just have a bunch of safes with your name on them, and only you know the combination..."
I'm not so concerned about the "timeliness" issue on a sub-yearly scale. It was a throwaway possible benefit of using multiple keys, cryptosystems, and decentralized transmission. As one of the elements is compromised by advancements in the art, they can be deprecated in favor of a stronger one.
By timely, I meant that it would be less economical to slurp up everything with the goal of SNA on a cohort of college friends or whatever.
I'd like an increase in the reasonable expectation of privacy with email. I would of course comply with a legal demand, authorized by a judge in my country, to surrender cleartext emails that are on my systems or in my accounts. I would expect my partners in conversation to do the same.
What I do not like, and I think we agree, is the convenient slurping of all the traffic, storing that, and then mining it for correlations with "un-American" conduct.
What I've found to be a more useful explanation trying to explain "security" as we usually mean it is to get to the reason why I think people should have privacy from their government or the agencies to whom they willingly transmit information about individuals. We've come a long way in securing rights for people who are not white, christian (of accepted denominations), straight, men. We have a lot longer to go.
I am really quite uncomfortable with a HUAC-style group having access to all electronic communications. It was communism fifty years ago, it's obviously terrorism now, but it will always be some threat to "national security" that is used as an excuse to be proactive about looking for suspicious characters because of what crimes they may be inclined to commit.
(And I kept using my own boot-root installation on my first Linux box (which could now legally buy alcohol in the USA) until 2000 or 2001, when I tried this "Redhat" thing. :-))
Hey all! Mailpile tech lead here. Just wanted to say THANKS to those of you who helped make this happen so quickly.
Improving e-mail security, flawed as the underlying protocols may be, is long overdue. We don't promise perfection, but we do have clear ideas about things that can be improved and how. We strongly believe in a pragmatic, backwards compatible approach that helps people slowly migrate to better habits.
For some background on the wider philosophy of the project, check out the slides from my OHM presentation where I launched this: http://mailpile.is/files/OHM2013%20-%20Rescuing%20e-mail%20f... - this project is as much about rebooting FOSS e-mail development and fostering decentralization, as it is about encryption and security.
We will be posting more details to our blog at http://www.mailpile.is/blog/ as soon as we get stuff written down. :-)
Why even bother with S/MIME? How long until the government corrupts the certificate for it if Mailpipe becomes as important to them as Lavabit was, in the future? And I hope their PGP implementation is really user-friendly.
This sounds like more of the same of what we've had so far, perhaps with the ability to become a little more mainstream, but I don't see any breakthroughs in terms of encryption here, like say the way Bitmessage is. I think that if we want NSA-proof secure messaging we'll need to come up with new stuff, and not just use the same old PGP with centralized email databases.
This could definitely be a (very short-term) win against NSA if say Gmail implemented PGP in a very user-friendly way, but for something starting from scratch, I'd rather it was a breakthrough in security.
Why even bother with S/MIME? How long until the
government corrupts the certificate for it if Mailpipe
becomes as important to them as Lavabit was, in the
future?
The way I see it, Mailpile won't be issuing certificates for people to use, they merely enable you to use your existing certificate infrastructure.
I have a machine with a certificate authority that issues S/MIME certs for us to use internally for sensitive emails. Currently we use Thunderbird and Mac Mail to handle this but people like web mail and we need a system that can run a web interface (or phone app) to handle these certificates.
I'd say the people that can set up and manage their own CA, and the people that need a new mail client to be able to send/receive encrypted email are non-overlapping groups.
The reason why I need something like Mailpile (and the problem they will hopefully solve) is to have a client-side app with a user-friendly system for managing S/MIME certificates.
I can set up the CA and generate user (employee) certificates on my own, there's no way the end-user should have to do that. But what's frustrating right now is that the current tools for configuring S/MIME signing and encryption for email either (a) don't exist, or (b) are heinously complicated to use.
Have you ever tried getting S/MIME certificate auth set up in Mac Mail? It's doable but I had difficulty walking my tech-savvy brother through the process over the phone.
If Mailpile has a simple method of selecting a certificate file for an email account then the hard part is done IMO. The process just becomes IT issuing new certificates every year to employees, and employees uploading said certificates through their (web) mail app.
The biggest value here is having a web mail client, hosted locally, that can support PGP/SMIME in a user friendly way. Then signed/encrypted emails are that much easier to configure for the masses.
* User-friendly support for both OpenPGP and S/MIME encryption and signatures
* A very fast, scalable search engine
I'd like to know how they achieve both without having the keys, and without shipping code (JS, java applet) that has access to the keys.
Also, excuse my lack of trust, but why should I trust a SaaS created by a Google employee, as opposed to trusting a SaaS created by Google ? That makes no sense to me.
If you're worried about privacy, store your own emails. Period.
I don't understand, are you generally concerned that Mailpile's web JS can search emails, and therefore has access to private user keys/certificates? I mean, doesn't that just come to whether or not you trust the javascript that Mailpile is writing? I don't think this any less secure than say Thunderbird with respect to PGP/SMIME.
Unless I'm misunderstanding, the goal of the Mailpile project is to create a user-friendly client for an arbitrary (including self-hosted) email server.
Is there any reason to not just put up all of my random project ideas on indiegogo and see if they get funded? If I'm having trouble financing the development new features for my SaaS application, should I just create a funding project for it?
Because I'm really not seeing the difference between that and this...I wish someone could explain this phenomenon to me.
Well, we're crowd funding an open source email client. Maybe it's not how these things have been done in the past but I'm happy to pay in advance to get someone to else to do most of the build. I can hack on it once it's more mature and stable.
If you have a SaaS app that's not open source and you're making money off then it's probably not going to be so successful in the crowd-funding arena - but you're still welcome to try.
> If I'm having trouble financing the development new features for my SaaS application, should I just create a funding project for it?
Sure, why not? No one is stopping you.
> I wish someone could explain this phenomenon to me.
Many people invest small amounts of money in a person or group of people. There are risks, like any investment, and the payoff is a product which the investors will find useful or entertaining.
it is not really an investment, it is more like charity... you more then likely never get more then what you paid for and you have a risk of loosing it all.
> you more then likely never get more then what you paid for
They tell you beforehand exactly what the payoff will be. If that doesn't sound economical to you, you don't pay in. There's absolutely no deception here. There's no promise of riches. There's just a promise of a product that is worth what you paid for it.
> and you have a risk of loosing it all.
...which is exactly like every other investment in the history of commerce.
But you have 0 chance of getting back more then what you spent, unlike an investment (the reward is always worth less then what you spent, if you think about it as an investment).
People have the option of paying people to work on projects. I don't see why this is so complicated. If you want to try to get people to crowd fund your project then go ahead and try. If you don't think someone else's project is worthwhile then don't contribute to it.
Each time someone attempts to make email more secure, the HN response is "no use! need to start from scratch, do it right!"
So, I guess what I'm saying is:
1) Are you working on an inherently-secure messaging protocol? Awesome! Link to the project?
2) If you're not, shut the fuck up. Any improvement is better than no improvement, and dismissing any attempts to fix some of these problems while you wait for The Perfect Solution™ is why we're in this mess in the first place.
It seems to me it's time email followed the file-sharing industry and moved to a distributed, peer-to-peer system. End-to-end encryption and no servers to shut down... There's a couple of research papers on the topic:
Congratulations on getting the funding. I really hope that over the next 22 days it's pushed much higher so you can develop the product faster.
I installed the current version last week to have a play. Even in its current state it's very promising - too far away to really be used yet but once it matures it could be a great product.
Maybe the better solution is a completely new distributed delayed messaging system that works just like e-mail, but fixes all the crustiness and problems that we know about these days.
There's very little that's more demoralizing then spending months cultivating a relationship with somebody in a company you want to work for, getting glowing recommendations, prepping yourself diligently for the interview then showing up to a cattle call where half the interviewers can't even be bothered to show up and the recruiters are a blind mess the entire day.
You aren't even being treated with basic human dignity at that point, there's no respect for your time and you've just wasted a good deal of effort to get into a hiring process where the candidates are selected for non-interview talents anyways...like what school they graduated from or the roll of some dice.
So there are no actual "perks" for the $1 and $8 contribution levels listed under the "Select a Perk" table?
$1 Binary E-mail User: You're part of the revolution, baby! - the revolution that started in the 1960's with the creation of the first e-mail systems.
$8 Futurist Telegrapher: Having not spent a dime on webmail for the last decade, you've realized that the telegraph operators of the world have been keeping copies, and it's time to change that. Thanks for helping us help you!
So what do the contributors actually get for $1 or $8?
They get nothing. I think those “reward” levels are just a cute way to trigger anchoring (http://en.wikipedia.org/wiki/Anchoring) and make the job of choosing how much money to give easier by suggesting some choices. In fact, the $13 contributors don’t get anything extra either – they get “access to Mailpile's online source code”, but that’s already available at https://github.com/pagekite/Mailpile.
I would like to mention that the details of this project seem a little sparse. For a truly secure solution, this system will need to (1) define a secure standard and (2) allow domain owners to personally host this system which can connect to legacy mail servers as well as the "new" secure standard. This way, when persons communicate within the same email domain and between secure systems, the communication can be considered secure.
Just my 2 cents I guess.
A system like this can succeed, but I think it's too early to judge.
What bothers me a little is this is basically a reinvention of the wheel for sup-mail, developer by a Twitter developer and was/is very cool (I use it on Mac occasionally for backups of email I have in a Maildir). Maipile would add the web interface, and they just started transitioning to that idea in the sup community, calling it heliotrope.
IMHO, the plus for this is that if more and more people move to encrypted communication across the board, it will a) increase the work load of the likes of the NSA and GCHQ, and b) send a message to government.
Nothing, of course, will work as well as people actually voting for real change. Of course the tragedy of that is that after the scary Bush years, the US people thought they were voting for changes, and all they got was more of the same. I despised Bush, but like we Brits used to say about Thatcher, at least we all knew where we stood. (Blair was our Obama, we thought we were voting for change.)
Sooner or later, we will realize we need to break away from our traditional parties, and vote for something very different, instead of voting int he same thing over and over again because we are too scared of fundamental change, and frankly risk.
For now, we are all too spaced out with our retail and media narcotics to notice or want to change.
"Mailpile will download your e-mail from a mail server much like Thunderbird or Mail.app and process it locally."
PRISM and other efforts at tracking associations operate at the server and header level, this is not a useful countermeasure. It may reduce the amount of mail you leave on the server -- but so would a reasonable mail reader configuration.
If it makes it easier to use encrypted email, then it does a little--any emails with someone with whom you have exchanged keys would be encrypted, and thus while they do indeed still fly across insecure channels, they are (presumably) uncrackable.
Obviously, the vast majority of emails would still be unencrypted, and this does nothing for metadata. But anything that makes encryption less cumbersome to use is a good thing in my book.
Great work guys, it would be great this takes off and introduces PGP to a wider audience. Maybe one day we can stop sending electronic postcards to each other. Now if only someone would restart Mixminion development...
as ever, the criminals and terrorists have already solved the problem; they communicate privately using closed community forums (search for "carding/carder forums"). The people left using SMTP e-mail are mostly PETA, EFF and other political groups the government is interested in monitoring.
There is no such thing as secure email. Assume everything is being read.
You can't bolt security on (SSL, mailbox encryption, PKI). You have to design it in from the start. SMTP/IMAP etc have crudely hacked on TLS implementations which aren't even guaranteed to be operational site to site. PGP is just an encapsulation which is rarely used.
It's a mess.
This is just a repackaging of the pile of hacks.
We need to start again and do it properly and consider: encryption, modern content encapsulation (better than mime), authentication, PKI, secure storage, mandatory authentication/authorisation and SPAM control.