SoylentNews is people
SoylentNews
Wired reports that Ladar Levison (of Lavabit fame) hired the convicted ex-hacker Stephen Watt to create DarkMail — a set of protocols and servers which apply a similar approach as onion routing to the email metadata (sender and recipients) and would still enable the existing email clients go "dark".
The internet is littered with burgeoning email encryption schemes aimed at thwarting NSA spying. Many of them are focused on solving the usability issues that have plagued complicated encryption schemes like PGP for years. But a new project called Dark Mail plans to go further: to hide your metadata.
The project has made for an interesting pairing between Texas technologist Ladar Levison and convicted hacker Stephen Watt, whom he's hired to help develop the code. Both have had previous battles with the government in very different ways.
The project is composed of several parts: an email client called Volcano; server software called Magma Classic and Magma Dark; and the Dark Mail, or Dmail, protocol, which they're designing to replace existing protocols for sending and retrieving email that don't hide metadata.
"If you trust your server, you can use Outlook and the server will handle everything for you," Levison says. "The preference would be that you use the Dark Mail client, but I understand that this is not even a possibility for some organizations."
Dark Mail is modeled loosely on TOR — The Onion Router... With Dark Mail, there are primarily two main servers involved in an email transaction: the sender's domain and the recipient's. And although the sender's server can identify the source from which the email was sent, it doesn't know the recipient, just the recipient's domain. The server at the recipient's domain decrypts the "to:" field to deliver the correspondence to the right account, but doesn't know who sent the email — just the domain from which it came.Seems like in the today's society one need to rely on outlaws to claim back some freedom (as in: being an honest citizen is no longer enough to guarantee it).
(Score: 1) by doublerot13 on Monday July 21 2014, @05:24PM
This may obscure some of the transaction on the wire. Unfortunately, knowing the recipient domain is more than enough info for the APT that is GO's. Especially, given the level of access they have to the major domains[gmail,outlook.com, yahoo, etc.] via NSL/Prism/etc.
PGP has been and continues to be your only safe bet. It really doesn't matter if the sender address and recipient address are known. It's the contents that must be opaque.
If PGP is too hard then run your own server/domain and give your contacts accounts on your box. You can encrypt everything on it. They can use VPNs/Tor(which maintains their IP anonymity) and just use their account on your box to send you mail on the same domain. It will never even have to leave the box.
(Score: 4, Interesting) by frojack on Monday July 21 2014, @05:35PM
TFS wasn't too specific, but it seems quite possible you would want to include PGP for your text body.
This mechanism is all about obscuring the the headers and metadata, so that none of the handlers can actually see both where it came from and where its going, and only the first and last servers have the knowledge to determine the final recipient.
Sort of like PGP for headers. Your client need only know/fetch the public key of the receiver's domain.
Still each server along the route (and presumably direct routes would be selected AGAINST, in favor of TOR, as you mention), needs only to know about the target domain, and couldn't decrypt any of the rest of the routing information, or the payload.
The most a spy agency could determine was that there were X number of messages destined for Location Y, but only if they managed to insert themselves into the chain.
No, you are mistaken. I've always had this sig.
(Score: 3, Insightful) by CRCulver on Monday July 21 2014, @06:03PM
That's a very pre-Snowden perspective. Metadata alone is capable of revealing things people would rather keep private, and it can drag innocent people into a dragnet. I'd highly recommend reading Schneier's post Metadata Equals Surveillance [schneier.com]. Under current snooping guidelines, someone determined to be one or two "hops" away from a target, by things like e-mail communication or social networking lists, can then have all of his online activity recorded.
Not only is your perspective pre-Snowden, it might even be called a 1990s one. Already by the turn of the millennium, crypto idealists were starting to ponder technologies that would obscure links between individuals, because crypto alone just isn't enough.
(Score: 2) by emg on Monday July 21 2014, @08:48PM
"Already by the turn of the millennium, crypto idealists were starting to ponder technologies that would obscure links between individuals, because crypto alone just isn't enough."
Anonymous remailers were commonplace in the early 90s. In some cases, they just dumped the final message onto Usenet, where the recipient would pick it up when it arrived at their local machine.
(Score: 2) by egcagrac0 on Monday July 21 2014, @06:16PM
I don't think that the major domains are going to adopt DarkMail (soon).
This is for setting up a replacement for the current email system.
Single-box email isn't realistic. Once you remotely access it, it's left the box. Administering foreign users becomes a big hassle, and a big social engineering backdoor into the system. ("I forgot my password, can you reset me?" - and then attacker can get all the data they weren't supposed to get.)
The whole idea of this is that I can set up my DarkMail server and do my own user authentication, and you can set up your server and do your own user authentication, and our two userbases can intercommunicate with a reasonable degree of security and obscurity. There's nothing that says we can't generate a new keypair monthly/weekly/daily/hourly (as appropriate to threat level) to deter realtime or near-realtime traffic analysis - the remote server just needs to be able to request & authenticate the public key at time of interchange (mostly trivial now, not much harder to work private CA's into the mix).
Connecting to more DarkMail servers should be a minor incremental amount of work, although given the system goals, it's probably reasonable to make that be a manual process (like a key-signing party), rather than an automatic process (like the current SMTP-to-any-server system).