11 ms·

Hackers Unveil Their Plan to Change Email

130 points by hachiya 12y ago

guylhem 12y ago
The concept is very interesting - apparently, each "doll" or layer is encrypted, and only the target can decode the message - so I guess the equivalent of the MX would be the outmost doll, while the equivalent of a To: field would be the innermost doll. This reminds me of something else I've found quite interesting - the idea of publishing pubkeys or at least their hashes as DNS records (yes, unsafe unless there is DNSSEC etc, but that would be much better than now), so that the sender could encrypt the message automatically, without requiring the user to select say GPG target keys. I wonder if that's what they will be using. Do they have technical documents or RFCs? A new and non backward compatible email system using that (say even running on a different port) would indeed be quite interesting, but I wonder if there wouldn't be weaknesses that would make spam a problem as serious as in 2004/2005 (or maybe SPF is yet another of their "dolls"?) Edit: about anonymous remailer and tor, it doesn't look the same to me. Say I publish 2 keys, one for my domain, one for my user. Everything one wishes to send to my domain is encrypted first with my key, then with my domain key, and then signed with the sender domain key (to add equivalent of SPF). Once it arrives, the equivalent of an MTA can try and decrypt that - if it suceeds, it can then put it in a spool of mail "not fetched yet" (so to as add a layer of protection against a malveolent sysadmin - the user could download all the encrypted mails in the spool and try to decrypt them itself) The only thing that would be seen (besides the DNS lookups, but they could be cached by the client with a TTL) would be that domain A is sending a message to domain B.
- pinkyand 12y ago
  The doll concept sounds awfully close to either tor or anonymous remailers(which are much more private). But anonymous remailers had much trouble with authorities so i wonder how that will work.
  - higherpurpose 12y ago
    I think they said in this video that the model is somewhat similar to Tor: https://www.youtube.com/watch?v=hRwArF3BAZk https://www.youtube.com/watch?v=hRwArF3BAZk For something that actually works over Tor (or something very similar), there's Adam Langley's Pond: https://pond.imperialviolet.org/tech.html https://pond.imperialviolet.org/tech.html
  - codys 12y ago
    Yep, I was imediately reminded on onion routing (which is what tor uses) when reading the article.
  - icelancer 12y ago
    Speaking of: Were the anon.penet.fi days REALLY 20 years ago? Good lord. they were.
- e12e 12y ago
  Are there any (new) technical info on this? I recall it's been discussed here before[hn] -- and as then -- I don't really see what's wrong with anonymous remailers (the old kind). I suppose DKIM and DNSSEC might form the foundation for additional standards to augment mixmaster remailers: DKIM should allow for rudimentary SPAM filtering on the "in" side of the remailer network/onion -- and DNSSEC might be one way to at least get "any" domains "remailer" public key (so that you could send eg all gmail mail to eg: reamailer@gmail.com, with the actual mail wrapped inside) -- and "any" standard mail client could wrap up mail like that (as a minimum, optionally with an additional remailer added). I don't know how big the need for is DKIM (from an anti-spam view) -- how many receive gpg-encrypted and signed spam anyway? As I've mentioned before, I think this has similar problems as remailers -- as far back as 1996 intelligence agencies were running quite a few of them[1] -- and I imagine that would be the case going forward as well (ditto for tor nodes). I don't think that makes these things a wasted effort, just not a silver bullet. Either way, having eg Apple Mail, Thunderbird and Gmail (yes, the webmail) automatically wrap any outgoing mail in a remailer-like envelope might not be a bad idea at all. And once wrapped, everything smtp (with the exception of content-based spam filtering at the intermediary servers) works just like it always has. [1] http://www.hypertekst.net/misc/anon-remail/ http://www.hypertekst.net/misc/anon-remail/ [hn] https://news.ycombinator.com/item?id=6642106 https://news.ycombinator.com/item?id=6642106 https://news.ycombinator.com/item?id=6671219 https://news.ycombinator.com/item?id=6671219
  - mike_hearn 12y ago
    > I don't know how big the need for is DKIM (from an anti-spam view) -- how many receive gpg-encrypted and signed spam anyway? Modern spam filters (at sites like Gmail) rely very heavily indeed on the notion of reputation. Without something like DKIM it's hard to calculate accurate reputations: you can do it but it relies on lots of hacks and heuristics. So reputation mechanisms of some form are pretty vital.
    - e12e 12y ago
      My point was that spammers typically wouldn't gpg encrypt mail to the recipient, even if just through a generic mixmaster wrapper service (the service could filter on content and dkim as normal on the incomming side). So if setting up such a network, i don't know if dkim would be useful on the "inside" and/or for opaque/encrypted-to-recipient messages. I suppose one could simply recommend smtp servers to clear-sign any trusted (originating at smtp servers domain) mail and stash server gpg keys in dns...
- mike-cardwell 12y ago
  I store the fingerprint and URL to fetch my public PGP key in a DNSSEC protected DNS record. It's called PKA: mike@blob:~$ dig +short txt mike.cardwell._pka.grepular.com "v=pka1\;fpr=35BCAF1D3AA21F843DC3B0CF70A5F5120018461F\; uri=http://grepular.com/0018461F.pub.asc" mike@blob:~$ My HN profile is GnuPG signed. You can automatically fetch my key using my PKA record and verify it by running it through the following command: sed 's/^[ ]*//'|gpg --verify-options pka-lookups --keyserver-options \ auto-key-retrieve --verify
- Joeri 12y ago
  Spam could be prevented by attaching an encryption cost to each message. It would make bulk mail prohibitively expensive. Inside companies you could have a trusted mail concept to allow mails to entire departments, but as soon as a mail leaves the domain a proof of work is implied.
  - eli 12y ago
    The bad spammers are using botnets. This would be extremely difficult to implement and would mostly hurt mailing lists.
  - mike_hearn 12y ago
    Spam filtering is not about blocking bulk mail.
mockery 12y ago
A big downside is that it seems like this would make spam harder to block. (Intuitive claim, I'm not familiar with the technical details.) It also seems like it has the disadvantage of chicken-and-egg adoption before it's a useful service. So here's a possible solution to both problems at once: I've always liked the idea of disincentivizing spam by charging a micropayment per email. So include a tiny bitcoin payment encoded into each layer of the doll to reward the intermediary, and you'll simultaneously provide an incentive for participation in the network (payment for participating) while simultaneously discouraging frivolous emails (since you now have to pay per spam message.) Obviously you'd make the charge small enough to not matter to most people for daily use (<$0.01) but I assume any nonzero price would hurt spammers badly. You'd have to prevent intermediaries from decoding all the layers and taking the full payment, but presumably the Dark Mail folks have a solution for this already. Otherwise otherwise anyone in the middle could decrypt all the layers and read the contents of the email, and Dark Mail wouldn't work at all. Or maybe I'm missing something. (Decent chance of that, since all I'm going on is a Time article and I'm not a security guru.)
- weavejester 12y ago
  I suspect make more sense to build in a hashcash check into the protocol. It would be easier to implement and wouldn't tie the protocol to the Bitcoin blockchain.
- ewillbefull 12y ago
  This will just put a lower-bound on the market for spam emails, at the cost of making legitimate email more expensive (especially at scale). It doesn't matter if it's a micropayment through bitcoin or hashcash. The only real way to solve the spam problem is a web-of-trust where spam is disincentivized because it harms your reputation in the system. That is kind-of the situation we have now, except encryption isn't baked into email yet (if it will ever be).
  - jwatte 12y ago
    Why is it a problem if legitimate email costs $0.01? If it's not even worth that to you, perhaps it's not so "legitimate" after all. (Organization internal mail doesn't need to pay itself) The main casualty would be mailing lists, which would likely have to move to forums or subscriptions. It might be technically possible to also say "I accept mail from X without demanding payment" but that's not necessary to make a pay-for email market work, and have much less spam.
kijin 12y ago
> So if you’re on Google, you get a doll that says ‘This doll came from Yahoo.’ Then you hand it to the next layer and they open it up and say, ‘This is for Alice.’ Then when Alice opens it up, Alice gets the whole message. And where does Alice store her private key? A very large percentage of email users currently use either webmail (e.g. Gmail) or a vendor-provided app (again, Gmail) to access their email. In order for Google to show you the content of your emails in such settings, it needs to be able to open up the last layer. So your private key gets stored on Google's servers, and they can capture your passphrase every time you log in. Remember that Lavabit used your passphrase as the key to your auto-generated private key, which was stored on their servers. This was necessary, not only for compatibility with existing IMAP clients, but also in order for the webmail to work at all. Other companies like Hushmail developed a workaround using Java applets and/or a copious amount of JavaScript cryptography, but all of that is also rubbish because you can't guarantee that they aren't serving you a backdoored version of those scripts. The only way end-to-end security could possibly work in the context of webmail would be for everyone to install a vendor-neutral browser plugin that does all the heavy lifting and that is completely beyond the control of the webpage on which it works (you can't allow the webpage to fetch the decrypted content back into the DOM). But if you're going down that route, you might as well install a standalone email app. It's basically going to be Thunderbird + Enigmail on steroids. Anybody who doesn't want to do that will be stuck keeping their private keys on someone else's machine. Guess what, most users really, really hate having to manage their own keys. tl;dr: This proposal means either the death of webmail as we know it, or little more than an illusion of security.
- weavejester 12y ago
  You could still have webmail under this proposal; it just wouldn't be much more secure than the current email system.
- hrjet 12y ago
  > vendor-neutral browser plugin It might begin that way, but it could evolve into a standard that is supported by many browsers. The "HTML6 email module".
  - 12y ago
logn 12y ago
Time's page has too much space for the header.
FiloSottile 12y ago
> The creator of an ultra-secure email service once said to be used by Edward Snowden [...] By the way, for those that don't recognize the name, the "ultra-secure" email service is Lavabit, that was secure only by pinky-swear (that is, they just promised to encrypt the emails they were seeing).
- michaelmior 12y ago
  > Ladar Levison, creator of the Lavabit encrypted email provider...
  - garrettgrimsley 12y ago
    >But rather than compromise the privacy of his other 400,000-plus email users, Levison says, he shut the entire project down. Shouldn't that read "he shut the entire project down, and then handed over the records of 400,000-plus email users?"
    - Havvy 12y ago
      No, he deleted the records his users had.
      - garrettgrimsley 12y ago
        Citation? I know that deleting records and handing over the encryption keys are not mutually exclusive, but this is the first I'm hearing about destruction of data that the government requested.
whoopdedo 12y ago
“Ironically, we have been protecting the stuff that they’re not collecting,” Callas said. Or, they were collecting it because it's not protected. If not by encryption at least by the law. That said, I have a feeling the NSA was also checking out the message bodies. Wasn't there one leak about analysts sharing nude photos from intercepts?
- deleted 12y ago
  [deleted]
- idlewords 12y ago
  I believe those were Yahoo Messenger (chat) intercepts: http://www.theguardian.com/world/2014/feb/27/gchq-nsa-webcam-images-internet-yahoo http://www.theguardian.com/world/2014/feb/27/gchq-nsa-webcam...
jawngee 12y ago
Sounds awesome but the naming is unfortunate. Dark Mail, to the average person, will have a negative impression. It sounds scary and intimidating and something those darn illegal hackers use.
- newaccountfool 12y ago
  I just went to the talk and they have renamed it to DIME. Possibly for the reasons you have stated. Levison stated that all big projects go through a name change when in development.
  - newaccountfool 12y ago
    I would upload the Slides, but I can't find it on the disc that every one gets with a ticket.
- higherpurpose 12y ago
  It's not just average people, but "average tech writers" too. If it keeps the name Dark Mail, most of them would use the angle: "Dark Mail is for hackers and criminals who want to escape law enforcement's snooping"....or something like that - rather than the "DIME is for people who value privacy and want to escape the government's mass surveillance" angle.
dkathayat 12y ago
I'm assuming it's open-source. Any clue how can one get started as a contributor? Would like to pitch in.
tomjen3 12y ago
So what is going to prevent the US from just serving NSL to everybody in the paths of the emails? They already read all the network traffic anyway. Freenet works substantially the same way, with routers not knowing the end paths and endpaths not knowing the sender, but it is build for file transfer - something where you would think the average person has an interest as it would prevent nasty letters from RIAA - and it hasn't taken of. Why should this?
- wcummings 12y ago
  The provider has no data to turn over. It doesn't trust the server. In the case a message is being delivered between two users on the same email provider, the provider can still outsource part of the process to a third party, somehow.
rythie 12y ago
Sounds great but it's really hard to get adoption of a new protocol. If I want to get a secure message to someone all I need is: me --(TLS)--> my SMTP --(TLS)--> receiving SMTP server All any third party will know is that I'm sending email to gmail/yahoo/ms or whereever. If I can't trust my ISP's outbound SMTP server, then I could have one on my own machine or even built in the mail client. The problem of course is that many ISPs put client IP addresses on RBL lists.
- calpaterson 12y ago
  I think he's trying to address more than just people intercepting emails in transit but there are a lot of things a government body could do to compromise your suggestion, for example: MITM the connection at a network level (mail daemons normally don't check certificates came from CAs), take control of the receiving SMTP server or maybe even just use an unpatched OpenSSL bug (heartbleed is still unpatched on quite a lot machines, including mail servers). Securing email will require a lot more than just turning encryption on, IMO.
  - rythie 12y ago
    I'm taking it as read that users would use message encryption - which already exists. Would creating a new protocol force daemons to check certificates came from CA? stop third parties controlling servers? or using unpatched OpenSSL though? anymore than a properly setup SMTP server though?
    - wcummings 12y ago
      No, it protects metadata. It's more than just message encryption.
      - rythie 12y ago
        TLS protects the metadata, as long as you know both ends have trustworthy SMTP servers.
- peteretep 12y ago
rythie 12y ago
Should we re-think email addresses too? Currently most people have just one email address they give to everyone. What we gave everyone we want to talk to a unique address e.g. <random_long_string>@provider.com - even with this simple change, it would be very hard for a government to track an individual though metadata. You could even create new from address for each outbound email - since you assume that if you digitally sign your email the recipient will know it's you.
gima 12y ago
For anyone interested, the webpage of "Dark Mail / DIME": https://www.darkmail.info/ https://www.darkmail.info/
yutah 12y ago
This way of hiding meta-data should probably be used at a lower level so that all Internet traffic benefits from it.
- wcummings 12y ago
  That's a lot of overhead and complexity considering most traffic doesn't need that level of protection
IvyMike 12y ago
Younger HNers may not remember the anonymous remailer days (ah, pre-spam internet, how I miss you) but this kind of technology has existed before. Specifically, this sounds a lot like mixmaster, the "Type II" anonymous remailer from the mid-90's that was pretty popular amongst the cypherpunks crowd. http://mixmaster.sourceforge.net/faq.shtml http://mixmaster.sourceforge.net/faq.shtml

130 points by hachiya 12y ago

The concept is very interesting - apparently, each "doll" or layer is encrypted, and only the target can decode the message - so I guess the equivalent of the MX would be the outmost doll, while the equivalent of a To: field would be the innermost doll. This reminds me of something else I've found quite interesting - the idea of publishing pubkeys or at least their hashes as DNS records (yes, unsafe unless there is DNSSEC etc, but that would be much better than now), so that the sender could encrypt the message automatically, without requiring the user to select say GPG target keys. I wonder if that's what they will be using. Do they have technical documents or RFCs? A new and non backward compatible email system using that (say even running on a different port) would indeed be quite interesting, but I wonder if there wouldn't be weaknesses that would make spam a problem as serious as in 2004/2005 (or maybe SPF is yet another of their "dolls"?) Edit: about anonymous remailer and tor, it doesn't look the same to me. Say I publish 2 keys, one for my domain, one for my user. Everything one wishes to send to my domain is encrypted first with my key, then with my domain key, and then signed with the sender domain key (to add equivalent of SPF). Once it arrives, the equivalent of an MTA can try and decrypt that - if it suceeds, it can then put it in a spool of mail "not fetched yet" (so to as add a layer of protection against a malveolent sysadmin - the user could download all the encrypted mails in the spool and try to decrypt them itself) The only thing that would be seen (besides the DNS lookups, but they could be cached by the client with a TTL) would be that domain A is sending a message to domain B.

pinkyand 12y ago
The doll concept sounds awfully close to either tor or anonymous remailers(which are much more private). But anonymous remailers had much trouble with authorities so i wonder how that will work.
- higherpurpose 12y ago
  I think they said in this video that the model is somewhat similar to Tor: https://www.youtube.com/watch?v=hRwArF3BAZk https://www.youtube.com/watch?v=hRwArF3BAZk For something that actually works over Tor (or something very similar), there's Adam Langley's Pond: https://pond.imperialviolet.org/tech.html https://pond.imperialviolet.org/tech.html
- codys 12y ago
  Yep, I was imediately reminded on onion routing (which is what tor uses) when reading the article.
- icelancer 12y ago
  Speaking of: Were the anon.penet.fi days REALLY 20 years ago? Good lord. they were.
e12e 12y ago
Are there any (new) technical info on this? I recall it's been discussed here before[hn] -- and as then -- I don't really see what's wrong with anonymous remailers (the old kind). I suppose DKIM and DNSSEC might form the foundation for additional standards to augment mixmaster remailers: DKIM should allow for rudimentary SPAM filtering on the "in" side of the remailer network/onion -- and DNSSEC might be one way to at least get "any" domains "remailer" public key (so that you could send eg all gmail mail to eg: reamailer@gmail.com, with the actual mail wrapped inside) -- and "any" standard mail client could wrap up mail like that (as a minimum, optionally with an additional remailer added). I don't know how big the need for is DKIM (from an anti-spam view) -- how many receive gpg-encrypted and signed spam anyway? As I've mentioned before, I think this has similar problems as remailers -- as far back as 1996 intelligence agencies were running quite a few of them[1] -- and I imagine that would be the case going forward as well (ditto for tor nodes). I don't think that makes these things a wasted effort, just not a silver bullet. Either way, having eg Apple Mail, Thunderbird and Gmail (yes, the webmail) automatically wrap any outgoing mail in a remailer-like envelope might not be a bad idea at all. And once wrapped, everything smtp (with the exception of content-based spam filtering at the intermediary servers) works just like it always has. [1] http://www.hypertekst.net/misc/anon-remail/ http://www.hypertekst.net/misc/anon-remail/ [hn] https://news.ycombinator.com/item?id=6642106 https://news.ycombinator.com/item?id=6642106 https://news.ycombinator.com/item?id=6671219 https://news.ycombinator.com/item?id=6671219
- mike_hearn 12y ago
  > I don't know how big the need for is DKIM (from an anti-spam view) -- how many receive gpg-encrypted and signed spam anyway? Modern spam filters (at sites like Gmail) rely very heavily indeed on the notion of reputation. Without something like DKIM it's hard to calculate accurate reputations: you can do it but it relies on lots of hacks and heuristics. So reputation mechanisms of some form are pretty vital.
  - e12e 12y ago
    My point was that spammers typically wouldn't gpg encrypt mail to the recipient, even if just through a generic mixmaster wrapper service (the service could filter on content and dkim as normal on the incomming side). So if setting up such a network, i don't know if dkim would be useful on the "inside" and/or for opaque/encrypted-to-recipient messages. I suppose one could simply recommend smtp servers to clear-sign any trusted (originating at smtp servers domain) mail and stash server gpg keys in dns...
mike-cardwell 12y ago
I store the fingerprint and URL to fetch my public PGP key in a DNSSEC protected DNS record. It's called PKA: mike@blob:~$ dig +short txt mike.cardwell._pka.grepular.com "v=pka1\;fpr=35BCAF1D3AA21F843DC3B0CF70A5F5120018461F\; uri=http://grepular.com/0018461F.pub.asc" mike@blob:~$ My HN profile is GnuPG signed. You can automatically fetch my key using my PKA record and verify it by running it through the following command: sed 's/^[ ]*//'|gpg --verify-options pka-lookups --keyserver-options \ auto-key-retrieve --verify
Joeri 12y ago
Spam could be prevented by attaching an encryption cost to each message. It would make bulk mail prohibitively expensive. Inside companies you could have a trusted mail concept to allow mails to entire departments, but as soon as a mail leaves the domain a proof of work is implied.
- eli 12y ago
  The bad spammers are using botnets. This would be extremely difficult to implement and would mostly hurt mailing lists.
- mike_hearn 12y ago
  Spam filtering is not about blocking bulk mail.

mockery 12y ago

A big downside is that it seems like this would make spam harder to block. (Intuitive claim, I'm not familiar with the technical details.) It also seems like it has the disadvantage of chicken-and-egg adoption before it's a useful service. So here's a possible solution to both problems at once: I've always liked the idea of disincentivizing spam by charging a micropayment per email. So include a tiny bitcoin payment encoded into each layer of the doll to reward the intermediary, and you'll simultaneously provide an incentive for participation in the network (payment for participating) while simultaneously discouraging frivolous emails (since you now have to pay per spam message.) Obviously you'd make the charge small enough to not matter to most people for daily use (<$0.01) but I assume any nonzero price would hurt spammers badly. You'd have to prevent intermediaries from decoding all the layers and taking the full payment, but presumably the Dark Mail folks have a solution for this already. Otherwise otherwise anyone in the middle could decrypt all the layers and read the contents of the email, and Dark Mail wouldn't work at all. Or maybe I'm missing something. (Decent chance of that, since all I'm going on is a Time article and I'm not a security guru.)

weavejester 12y ago
I suspect make more sense to build in a hashcash check into the protocol. It would be easier to implement and wouldn't tie the protocol to the Bitcoin blockchain.
ewillbefull 12y ago
This will just put a lower-bound on the market for spam emails, at the cost of making legitimate email more expensive (especially at scale). It doesn't matter if it's a micropayment through bitcoin or hashcash. The only real way to solve the spam problem is a web-of-trust where spam is disincentivized because it harms your reputation in the system. That is kind-of the situation we have now, except encryption isn't baked into email yet (if it will ever be).
- jwatte 12y ago
  Why is it a problem if legitimate email costs $0.01? If it's not even worth that to you, perhaps it's not so "legitimate" after all. (Organization internal mail doesn't need to pay itself) The main casualty would be mailing lists, which would likely have to move to forums or subscriptions. It might be technically possible to also say "I accept mail from X without demanding payment" but that's not necessary to make a pay-for email market work, and have much less spam.

kijin 12y ago

> So if you’re on Google, you get a doll that says ‘This doll came from Yahoo.’ Then you hand it to the next layer and they open it up and say, ‘This is for Alice.’ Then when Alice opens it up, Alice gets the whole message. And where does Alice store her private key? A very large percentage of email users currently use either webmail (e.g. Gmail) or a vendor-provided app (again, Gmail) to access their email. In order for Google to show you the content of your emails in such settings, it needs to be able to open up the last layer. So your private key gets stored on Google's servers, and they can capture your passphrase every time you log in. Remember that Lavabit used your passphrase as the key to your auto-generated private key, which was stored on their servers. This was necessary, not only for compatibility with existing IMAP clients, but also in order for the webmail to work at all. Other companies like Hushmail developed a workaround using Java applets and/or a copious amount of JavaScript cryptography, but all of that is also rubbish because you can't guarantee that they aren't serving you a backdoored version of those scripts. The only way end-to-end security could possibly work in the context of webmail would be for everyone to install a vendor-neutral browser plugin that does all the heavy lifting and that is completely beyond the control of the webpage on which it works (you can't allow the webpage to fetch the decrypted content back into the DOM). But if you're going down that route, you might as well install a standalone email app. It's basically going to be Thunderbird + Enigmail on steroids. Anybody who doesn't want to do that will be stuck keeping their private keys on someone else's machine. Guess what, most users really, really hate having to manage their own keys. tl;dr: This proposal means either the death of webmail as we know it, or little more than an illusion of security.

weavejester 12y ago
You could still have webmail under this proposal; it just wouldn't be much more secure than the current email system.
hrjet 12y ago
> vendor-neutral browser plugin It might begin that way, but it could evolve into a standard that is supported by many browsers. The "HTML6 email module".
- 12y ago

logn 12y ago

Time's page has too much space for the header.

FiloSottile 12y ago

> The creator of an ultra-secure email service once said to be used by Edward Snowden [...] By the way, for those that don't recognize the name, the "ultra-secure" email service is Lavabit, that was secure only by pinky-swear (that is, they just promised to encrypt the emails they were seeing).

michaelmior 12y ago
> Ladar Levison, creator of the Lavabit encrypted email provider...
- garrettgrimsley 12y ago
  >But rather than compromise the privacy of his other 400,000-plus email users, Levison says, he shut the entire project down. Shouldn't that read "he shut the entire project down, and then handed over the records of 400,000-plus email users?"
  - Havvy 12y ago
    No, he deleted the records his users had.
    - garrettgrimsley 12y ago
      Citation? I know that deleting records and handing over the encryption keys are not mutually exclusive, but this is the first I'm hearing about destruction of data that the government requested.

whoopdedo 12y ago

“Ironically, we have been protecting the stuff that they’re not collecting,” Callas said. Or, they were collecting it because it's not protected. If not by encryption at least by the law. That said, I have a feeling the NSA was also checking out the message bodies. Wasn't there one leak about analysts sharing nude photos from intercepts?

deleted 12y ago
[deleted]
idlewords 12y ago
I believe those were Yahoo Messenger (chat) intercepts: http://www.theguardian.com/world/2014/feb/27/gchq-nsa-webcam-images-internet-yahoo http://www.theguardian.com/world/2014/feb/27/gchq-nsa-webcam...

jawngee 12y ago

Sounds awesome but the naming is unfortunate. Dark Mail, to the average person, will have a negative impression. It sounds scary and intimidating and something those darn illegal hackers use.

newaccountfool 12y ago
I just went to the talk and they have renamed it to DIME. Possibly for the reasons you have stated. Levison stated that all big projects go through a name change when in development.
- newaccountfool 12y ago
  I would upload the Slides, but I can't find it on the disc that every one gets with a ticket.
higherpurpose 12y ago
It's not just average people, but "average tech writers" too. If it keeps the name Dark Mail, most of them would use the angle: "Dark Mail is for hackers and criminals who want to escape law enforcement's snooping"....or something like that - rather than the "DIME is for people who value privacy and want to escape the government's mass surveillance" angle.

dkathayat 12y ago

I'm assuming it's open-source. Any clue how can one get started as a contributor? Would like to pitch in.

tomjen3 12y ago

So what is going to prevent the US from just serving NSL to everybody in the paths of the emails? They already read all the network traffic anyway. Freenet works substantially the same way, with routers not knowing the end paths and endpaths not knowing the sender, but it is build for file transfer - something where you would think the average person has an interest as it would prevent nasty letters from RIAA - and it hasn't taken of. Why should this?

wcummings 12y ago
The provider has no data to turn over. It doesn't trust the server. In the case a message is being delivered between two users on the same email provider, the provider can still outsource part of the process to a third party, somehow.

rythie 12y ago

Sounds great but it's really hard to get adoption of a new protocol. If I want to get a secure message to someone all I need is: me --(TLS)--> my SMTP --(TLS)--> receiving SMTP server All any third party will know is that I'm sending email to gmail/yahoo/ms or whereever. If I can't trust my ISP's outbound SMTP server, then I could have one on my own machine or even built in the mail client. The problem of course is that many ISPs put client IP addresses on RBL lists.

calpaterson 12y ago
I think he's trying to address more than just people intercepting emails in transit but there are a lot of things a government body could do to compromise your suggestion, for example: MITM the connection at a network level (mail daemons normally don't check certificates came from CAs), take control of the receiving SMTP server or maybe even just use an unpatched OpenSSL bug (heartbleed is still unpatched on quite a lot machines, including mail servers). Securing email will require a lot more than just turning encryption on, IMO.
- rythie 12y ago
  I'm taking it as read that users would use message encryption - which already exists. Would creating a new protocol force daemons to check certificates came from CA? stop third parties controlling servers? or using unpatched OpenSSL though? anymore than a properly setup SMTP server though?
  - wcummings 12y ago
    No, it protects metadata. It's more than just message encryption.
    - rythie 12y ago
      TLS protects the metadata, as long as you know both ends have trustworthy SMTP servers.
peteretep 12y ago

rythie 12y ago

Should we re-think email addresses too? Currently most people have just one email address they give to everyone. What we gave everyone we want to talk to a unique address e.g. <random_long_string>@provider.com - even with this simple change, it would be very hard for a government to track an individual though metadata. You could even create new from address for each outbound email - since you assume that if you digitally sign your email the recipient will know it's you.

gima 12y ago

For anyone interested, the webpage of "Dark Mail / DIME": https://www.darkmail.info/ https://www.darkmail.info/

yutah 12y ago

This way of hiding meta-data should probably be used at a lower level so that all Internet traffic benefits from it.

wcummings 12y ago
That's a lot of overhead and complexity considering most traffic doesn't need that level of protection

IvyMike 12y ago

Younger HNers may not remember the anonymous remailer days (ah, pre-spam internet, how I miss you) but this kind of technology has existed before. Specifically, this sounds a lot like mixmaster, the "Type II" anonymous remailer from the mid-90's that was pretty popular amongst the cypherpunks crowd. http://mixmaster.sourceforge.net/faq.shtml http://mixmaster.sourceforge.net/faq.shtml