11 ms·

How many times do people have to say this: There is no such thing as secure email. Assume everything is being read. You can't bolt security on (SSL, mailbox e

How many times do people have to say this: 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.

harrytuttle 13y ago
To downvoters: do the honour of explaining yourselves.
modoc 13y ago
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.
- FedRegister 13y ago
  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: modern content encapsulation / PKI / mandatory authentication / SPAM control.
  - cwp 13y ago
    What do you mean by modern content encapsulation?
    - FedRegister 13y ago
      MIME blows
- Shish2k 13y ago
  > making PGP easy to use which solves the lions share of the issues Does it encrypt the "from" and "to" headers?
- JshWright 13y ago
  The NSA doesn't care what's in my message. They care who sent it, who received it, and when it was sent. None of those things are protected by PGP. Heck, they often get the source IP address and subject line, which is just a bonus.
- harrytuttle 13y ago
  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)
  - bio4m 13y ago
    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/ http://xkcd.com/538/
  - crocowhile 13y ago
    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.
sipior 13y ago
Okay, Harry, let us know when you're done with that :-) I suspect most of the rest of us would prefer the perfect not be an enemy of the good.
- harrytuttle 13y ago
  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. As for good, it's not even that. See my comment here: https://news.ycombinator.com/item?id=6244196 https://news.ycombinator.com/item?id=6244196 Also, bear in mind I had the unfortunate job of designing and running ISP mail systems for a number of years so I know the whole stack inside out.
  - sipior 13y ago
    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!!"
- gioele 13y ago
  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.
toomuchtodo 13y ago
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.
- harrytuttle 13y ago
  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.
  - mike-cardwell 13y ago
    "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.
malandrew 13y ago
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. [0] http://ritter.vg/blog-deanonymizing_amm.html http://ritter.vg/blog-deanonymizing_amm.html
- hershel 13y ago
  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.
reeses 13y ago
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: Next: baz Data: Ardhrcbeebdhvfdhnzrfgdhvqbyber zvcfhz,pbafrpgrghe,nqvcvfpviryvg 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: From: POSTMASTER@quux.com To: reeses@example.com Subject: (none) -----BEGIN PGP MESSAGE----- Version: 2.6.2 PnyyzrVfuznry.Fbzrlrnefntb-arirezvaqubjybat ... 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. Plus, rubber hose.
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.
  - 13y ago
samstave 13y ago
It's amazing how this is all coming about. 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.
- kylec 13y ago
  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-internet-is-yours-again http://www.kickstarter.com/projects/600284081/adtrap-the-int...) but for email or other sorts of communication.
  - gwu78 13y ago
    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.
Aloisius 13y ago
> 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/ 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 :/).
FooBarWidget 13y ago
Yes, I'm sure a complete redesign will be a success. Let's give it a cool name too... how about "Wave"?
colin001 13y ago
good
balabaster 13y ago
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.

harrytuttle 13y ago

To downvoters: do the honour of explaining yourselves.

modoc 13y ago

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.

FedRegister 13y ago
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: modern content encapsulation / PKI / mandatory authentication / SPAM control.
- cwp 13y ago
  What do you mean by modern content encapsulation?
  - FedRegister 13y ago
    MIME blows
Shish2k 13y ago
> making PGP easy to use which solves the lions share of the issues Does it encrypt the "from" and "to" headers?
JshWright 13y ago
The NSA doesn't care what's in my message. They care who sent it, who received it, and when it was sent. None of those things are protected by PGP. Heck, they often get the source IP address and subject line, which is just a bonus.
harrytuttle 13y ago
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)
- bio4m 13y ago
  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/ http://xkcd.com/538/
- crocowhile 13y ago
  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.

sipior 13y ago

Okay, Harry, let us know when you're done with that :-) I suspect most of the rest of us would prefer the perfect not be an enemy of the good.

harrytuttle 13y ago
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. As for good, it's not even that. See my comment here: https://news.ycombinator.com/item?id=6244196 https://news.ycombinator.com/item?id=6244196 Also, bear in mind I had the unfortunate job of designing and running ISP mail systems for a number of years so I know the whole stack inside out.
- sipior 13y ago
  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!!"
gioele 13y ago
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.

toomuchtodo 13y ago

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.

harrytuttle 13y ago
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.
- mike-cardwell 13y ago
  "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.

malandrew 13y ago

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. [0] http://ritter.vg/blog-deanonymizing_amm.html http://ritter.vg/blog-deanonymizing_amm.html

hershel 13y ago
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.

reeses 13y ago

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: Next: baz Data: Ardhrcbeebdhvfdhnzrfgdhvqbyber zvcfhz,pbafrpgrghe,nqvcvfpviryvg 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: From: POSTMASTER@quux.com To: reeses@example.com Subject: (none) -----BEGIN PGP MESSAGE----- Version: 2.6.2 PnyyzrVfuznry.Fbzrlrnefntb-arirezvaqubjybat ... 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. Plus, rubber hose.

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.
- 13y ago

samstave 13y ago

It's amazing how this is all coming about. 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.

kylec 13y ago
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-internet-is-yours-again http://www.kickstarter.com/projects/600284081/adtrap-the-int...) but for email or other sorts of communication.
- gwu78 13y ago
  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.

Aloisius 13y ago

> 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/ 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 :/).

FooBarWidget 13y ago

Yes, I'm sure a complete redesign will be a success. Let's give it a cool name too... how about "Wave"?

colin001 13y ago

good

balabaster 13y ago

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.