- Lavabit + Silent Circle are starting a non-profit called the Dark Mail Alliance.
- Planning to release an open source protocol for end-to-end encrypted email, along with some open source implementations. Expecting feedback from the community to drive the direction.
- Sketch of the protocol: Mail body/details is saved encrypted on some server somewhere. Encrypted XMPP message containing URI describing where to retrieve the message is sent to the recipients. Recipient clients figure out how to fetch it and decrypt it.
- The protocol is based heavily on Silent Circle's protocol. Functional proof of concept already exists.
- There will be several modes of security, default being the most secure, but allowing the user to explicitly scale down on a case-by-case basis (e.g. to abide by regulations and corporate policies).
- Sounds like it's backwards-compatible with SMTP, perhaps through gateways. It'll be explicitly marked as insecure.
- Ladar's goal is to transition Lavabit from a services company into a software company, using the free/open source business model and offer support services around it.
- The protocol will be using "new elliptic curve cryptography we [Silent Circle] developed." They're expecting the encryption methods will change over time.
FWIW, I suspect Phil Zimmermann from Silent Circle is one of the very few people in the world for whom that reservation probably isn't automatically correct…
Strange that they say "we", because in the previous interview, they said Dan Bernstein helped them to create some new 205-bit curve or something. Previously they were using the NIST curves in the SCIMP protocol. They should probably just use Curve25519, unless they think that's too overkill.
I don't know too much about cryptography, but for an asynchronous communication method like email, is there such a thing as encryption overkill? For example, does it matter whether the message takes two seconds or five seconds to decrypt/encrypt (particularly if that encryption/decryption happens in the background of your mail app)? Are there other issues as you increase the number of bits on the curve?
I seem to remember quite a bit of hubbub recently about how meta-data related to communication could be useful, even if you couldn't get the content of the communication.
Now I see a proposal for a "Secure email", which involves giving an additional third party access to that meta-data.
I think it's important that we separate our support for Ladar's legal problems from our support from his technical decisions.
I think we should support Ladar as a person for bravely deciding not to comply with the government's request, but that we should be extremely critical of the technical decisions that lead to his ability to have complied.
LavaBit was a service offering "secure" email using a mechanism known to be insecure, which unnecessarily put a lot of users at risk. It seems injudicious to fund its redeployment, and even a little bit strange to fund the same person to develop something new.
I dont understand. Lavabit's full process, including the last resort off switch, worked. Snowden was well served to rely on it, his emails were not read by the government.
1) The server operator could choose to obtain access to plaintext.
2) An attacker who compromised the server could get access to plaintext.
3) Anyone capable of intercepting the SSL communication could get access to plaintext.
Incidentally, those are the exact same points of vulnerability for a normal (unencrypted) mail service.
One interesting question is why the US government requested Lavabit's SSL key rather than just getting a CA to sign their own. My assumption is because they were interested in past communication that might have already been deleted (perhaps by Snowden). We now know that the US government often logs and stores ciphertext, and we know that Lavabit was not selecting PFS SSL cipher suites.
So when Ladar did eventually provide the SSL key to the government, it's likely that the government was able to use that to decrypt all previously stored traffic and obtain the entire history of transmitted email.
So it's quite likely that Snowden (and all other Lavabit users) did have their email read by the government.
What is different about the government logging traffic between Lavabit and the user versus the SMTP between another host and Lavabit? With Lavabit's key, they can get all incoming mail (and many providers don't even use STARTTLS). Perhaps their logged traffic was incomplete or is difficult to search?
Email just isn't very secure as a protocol; people that care need something they can verify, like PGP (which Snowden used). It's unfortunate that the asynchronous nature of email (which we tend to view as an important feature) is incompatible with client-verifiable forward secrecy.
He had the keys and encrypted messages on the server. Everything but passwords (to unlock the private key), which he received from users and chose not to store. There is no way for users to audit that the passwords are not stored or intercepted (with or without Ladar's consent). He took a commendable stand, but had he built the technology differently, he never would have been in a position of having to choose and users would not have to trust his integrity and endpoint security.
The technical challenge is in designing a system in which the server does not have to be trusted, but that integrates well with existing protocols. I'm not aware of a proposal that offers the desired level of security while transparently integrating with SMTP, but perhaps Moxie has ideas.
One can get part way if the users generate their own key pair and only provide the server the public key, then either use a PGP-capable mail client or perhaps run a local (open source and audited) IMAP proxy to decrypt. You'd still have to trust the server not to store a clear copy of incoming mail, but once it is encrypted, only the client would be able to decrypt.
FWIW, I think there's a disconnect between what people expect/need from their email hosting provider and the "obvious" security solutions. Especially these days with many many people relying on IMAP to provide server-side search when using mobile devices.
If you need the server to be able to text search through your mail archive (and I do that a _lot_ on my phone), you need to "trust" the server with your clear text.
If you don't want to run and secure your own server - you need to choose what level of compromise you're prepared to accept.
My current project is a mail server on a RaspberryPi, hidden behind my home NAT gateway and firewall, that opens reverse ssh tunnels for ports 25 and 465 to inexpensive VPSes configured to not log anything - with IMAP (and webmail) access limited to my local network (and to my phone and iPad via vpn). It uses Vagrant and Ansible to provision and configure VPSes on the fly, and DNS hosting with APIs that Ansible can update MX records for as my receiving mail server moves around different VPS vendors in different jurisdictions.
>If you need the server to be able to text search through your mail archive (and I do that a _lot_ on my phone), you need to "trust" the server with your clear text.
How many megabytes of body text are you searching through? Is your phone actually incapable of doing the search in milliseconds?
Disk space doesn't matter. That's going to be mostly extra headers and formatting and attachments. I can't find many sources for the number of words in an email, but what I did find suggests about 50. Let's assume that's an entire order of magnitude off, and you have 500 words * 5800 emails. That's 17MB. A laptop or a phone can easily cache that much data and search it in a tenth of a second. All you have to do is filter out the junk beforehand instead of repeating the work every time you search.
I have a million emails occupying 20GB, and receive several hundred per day. I search my mail archive using xapian (via notmuch) on my laptop, but such solutions are less practical for phones and even some desktop users expect IMAP search to work. Indexing is definitely a problem if you want the server's store to be encrypted.
Lavabit had the capability and will to share information with law enforcement in the past; it was only in Snowden's case that Levison refused.
> Levison isn’t an privacy absolutist. He has cooperated in the past with government investigations. He says he’s received “two dozen” requests over the last ten years, and in cases where he had information, he would turn over what he had.
> “I’m not trying to protect people from law enforcement,” he said. “If information is unencrypted and law enforcement has a court order, I hand it over.”
Lavabit's encrypted storage was a paid feature that was used by less than 10% of users. From the wording, it sounds like he never stored passwords for those accounts. It's possible that Snowden was the first premium customer for which Lavabit was issued a warrant.
Agree, but then again, most of the parroting that has taken place with respect to this entire debacle has served to expose people to many of the issues and practices around online privacy, so there is that (albeit under poor circumstances, but lemons -> lemonade).
What's with the weird goal amount though? Is there some significance there that I'm not aware of?
I'm disappointed with this Kickstarter campaign. One 23 minute video and almost no text explaining the project. The video isn't even made for Kickstarter, it's just the announcement video from Inbox Love. How do they expect to get almost $200,000 in donations with a campaign that looks like it was put together in 10 minutes?
I want Darkmail to succeed (and I don't mind the name like many here), but I have serious questions about the protocol and the community, no one which have been answered.
I couldn't believe that the Kickstarter video was the unedited conference recording. I don't think campaigns need to be exceedingly polished but I do expect a bit more effort than this.
>Reward levels at different price points with identical rewards? Check.
Come on, that's not fair. This is a kickstarter that gives the normal contributor no rewards. That is an entirely different discussion, and not inherently bad.
I'm not talking about what's fair/not fair or what's bad/not bad. I'm talking about attributes of successful (or not) Kickstarter campaigns. Do you know of a successful campaign with reward levels at different price points that have identical rewards/text? Do you think that increases the chances of success for this campaign?
I'm saying that your classification of multiple tiers as having the 'same' reward is misleading, because those tiers have no reward.
I can't answer your question because I've only paid attention to a handful of kickstarters, and they were product-selling rather than goal-fundraising.
Whether a project creator chooses to provide an actual reward in the sense that most people use the word is up to him or her. I'd wager that electing not to do so is strongly correlated with a project not reaching its funding goal.
I'm not complaining about terminology. Okay let me put this another way. Let's pretend they had a $20 tier where you get nothing, plus the $5000 and $10000 early access tiers. If someone donates $20, they get nothing. If someone donates $437, they get nothing. Does it actually hurt the project to create a $400 nothing-tier in addition to the $20 nothing-tier? I am skeptical of this. But that's what you called out as a negative in your original post, having multiple tiers that are the same.
It's been said before but the name seriously needs to change if the initiative wants to get any sort of support from the general public. It's only slightly better than say "pedomail".
Similar to authoritarian conservative political groups using names like "Freedom" and "Liberty"?
They can sugar-coat it however they want but I'm ok with "dark". That is the fact of life in a surveillance-state. In such an environment, one who wishes to communicate in private must do it in the dark.
At my alma mater, we had a club named "Player's Club". Only the sketchiest of people ever went there, and thus the business suffered. One year, they made a single change - they renamed it "Indigo". Without changing a single thing besides the name, the club turned around and is now one of the most popular bars on campus.
Being a dance club, "Player's Club" might have been a more accurate name. Unfortunately, nobody wants to say to their friends "tonight I'm going to Player's Club". I'm sure you can make the connection here.
As accurate as it may be, it's terrible from a PR standpoint. The grandmother next door will be less likely to adopt its use if she associates it with darkness/nefariousness. You may be OK with it and understand its true meaning, but this isn't about just you.
But why create the friction in the first place? News are mostly about soundbites, do you think that if grandma hears on the news that a defendant is part of the 'dark mail' initiative that she will be sympathetic towards him?
If I were starting a company to provide service for this protocol, or if I were an email provider considering supporting this protocol, I would be much more happy if it were called something other than Dark Mail.
If this really is just a protocol, and not a marketing name, then the main thing it needs to do is be inoffensive and distinguishable. Honestly, I would be much more comfortable starting a company around a protocol named something super-dumb like MURP or another non-descript acronym.
There are probably names that are just as bad for other reasons, but one of the top goals of naming something like this should be avoiding getting targeted as something intended for illegal use.
Nobody's grandmother uses or avoids Gmail because of any connotations of "Simple Mail Transport Protocol", because they never hear about it. Only the most crazy religious people (or the least imaginative trolls) ever get upset by "mailer daemon"
This, if successful, will be marketed as "Gmail's new secure mail feature" or "SparrowSecure Mail.app" or "$ISP's privacy-enhanced mail option", not as "dark mail, the replacement for your smtp imap and pop3 service".
I would call it RockMail or some other sort of strong or hard name. You don't become the punch line of jokes if your product fails in it's security purpose like you would get wtih SafeMail or SecureMail, but you don't have the nefarious naming that DarkMail gives.
Also RockMail fits with the Lavabit / Magma naming scheme Lavar has for his company and software. Or they can call it WhisperMail, QuietMail, FlutterMail, InvisibleMail or SilentMail to fit with silent circle's naming scheme.
There was a whole discussion about this the other day when it got posted on HN and since then, I have to say the name just seems more and more underground, and not in a good way.
Something like Secure Mail Alliance would have been a much better choice. I understand this is just for the parent company/working group/whatever and the end product may be called something else, but 1+1=3 very quickly in the media with political spin.
They point out that existing email leaks a lot of metadata, but I do not see any proposal to fix that in the new protocol. How would you hide/encrypt/otherwise protect the list of recipients? Someone somewhere has to know where to deliver the message, especially if you will continue to use human readable/memorable email addresses as we currently know them today.
You could have the server know the addresses to forward the message and then forget them. However, then the server knows this information at some point and it could be sniffed/recorded along the way.
Does anyone know any more details about the specifics of the protocol? How would you minimize metadata leakage if you were implementing such a protocol? I am not sure it is possible to guarantee the recipient list won't be leaked.
which worries me. Yes, the connection between the server and client will be encrypted, but my message still has metadata that isn't encrypted. I'd just like an answer from Silent Circle / Lavabit.
why dont they address the server and encrypt the user address at the server level, so a network eavesdropper would only see traffic too and from servers but not the particular addresses being addressed. The user puts in an address e.g. yaName@yaDomain.com the sender and receiver address (maName & yaName) are then stripped on sending the D-mail and encrypted with the D-mail servers private key the receiving server (maDomain) then goes through the public private key exchange with the sender (yaDomain) thus securely passing the user address between the two servers without the eavesdropper knowing from what user the D-mail originated and to what user the D-mail was addressed to. This system would become more secure the the greater the number of users on each domain.
To add extra security batch sending by the server would make it even more secure
e.g. every 3min || when unsent messages to domain x > 999 --> send D-mails.
this would add latency and create bandwidth spikes but would negate time based inference attacks.
I believe that the SCIMP whitepaper is from 2012. They haven't released their current protocol , and they said they don't want to talk too much about it because there could be changes.
A. Put a chain of servers between the sender and the recipient, each with a unique encryption key(which lets you reveal unique info for each server privately)
B. Make sure to hide traffic patterns: don't let your enemy know when sender is sending a message or when recipient is receiving a message. This can be done by creating false traffic at fixed times to hide true traffic.
you can design protocols that make sure that:
1. The first server in the chain only knows the sender.
2. The last server on the chain only the recipient.
3. Assuming you enemy hasn't cracked all the chain, he can't link sender and recipient
I don't know alot about the XMPP protocol(whichthey are using) , so i'm not sure how it fits all this though.
: Whiney warning :
I wish they'd put a bit more work into this kickstarter, rather than just dropping a terd on my doorstep. I'm really interested in this protocol, but I can't help but feel like there's a lot of entitlement evident in the lackadaisical approach.
: end whine :
Wow, $196,000? That's a lot of cash for cleaning up source code and releasing it, isn't it? My understanding is that the code is merely being modified to work in other environments, right? Finding great talent costs money and time, but surely finding great developers who support Ladar and his quest to release an open source email service wouldn't be that hard? I don't know C that well, but I'd volunteer my time to make the project a success.
Something about that almost 200k figure they're asking for doesn't feel right. Am I missing something here?
I can't find any information on the "newly developed dark mail protocol." Is this public anywhere? I need more information before I know if I want to donate to support it.
Their website does not contain any detailed information about the protocol. The kickstarter video is the most detailed information I have read/seen on the proposed protocols and general approach. They have referenced a whitepaper several times, but I do not think that it has been published yet. If it has been and anyone knows a link, please share!
It's written in C#, which I don't personally like. And there's no mention of which particular 'open source' license it is. But the source code should be informative for a port/rewrite, and maybe running it via Mono is viable.
edit:
If the DarkMail people happen to be reading this thread, please consider putting your full support behind BitMessage.
Ha, that's a pretty bullet-proof way to not get shutdown.
To expand a little bit for the less technical readers. This is about developing a new protocol for email, and an open source software package that supports that protocol for people to use it with.
So in the end there will be a software package that you could install on a server yourself and use for emailing others using the protocol. Most likely some businesses will use the software and charge users for the service, just like what Lavabit was doing before it shutdown.
So you could shutdown one provider, but you'll likely just make several new ones popup. This is similar to the war against bittorrent. You can shut down the trackers and the sites where people find the torrents but new ones will just appear.
I think chances are, the readers of HN already know the difference between a protocol and a service.
And the benefit you listed is already one given to email — the reason that lavabit was shut down was because the guy behind it didn't want to provide a service he knew to be flawed, in that the US government could request details about users.
The question is, how does this protocol have it built into it in such a way that both allows anonymity and so that providers can pop up in their place, as you say?
- Lavabit + Silent Circle are starting a non-profit called the Dark Mail Alliance.
- Planning to release an open source protocol for end-to-end encrypted email, along with some open source implementations. Expecting feedback from the community to drive the direction.
- Sketch of the protocol: Mail body/details is saved encrypted on some server somewhere. Encrypted XMPP message containing URI describing where to retrieve the message is sent to the recipients. Recipient clients figure out how to fetch it and decrypt it.
- The protocol is based heavily on Silent Circle's protocol. Functional proof of concept already exists.
- There will be several modes of security, default being the most secure, but allowing the user to explicitly scale down on a case-by-case basis (e.g. to abide by regulations and corporate policies).
- Sounds like it's backwards-compatible with SMTP, perhaps through gateways. It'll be explicitly marked as insecure.
- Ladar's goal is to transition Lavabit from a services company into a software company, using the free/open source business model and offer support services around it.
- The protocol will be using "new elliptic curve cryptography we [Silent Circle] developed." They're expecting the encryption methods will change over time.