Lavabit's Dark Mail Initiative | Hacker News Reader

Lavabit's Dark Mail Initiative

kickstarter.com

210 pointsp4bl087 comments

Video summary:

- 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.

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.

Thank you for the summary!

>"new elliptic curve cryptography we [Silent Circle] developed."

???

is... this a good idea? I would of thought libraries for this technique abound.

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…

http://en.wikipedia.org/wiki/Phil_Zimmermann

For the rest of us - HELL YEAH! Do not develop your own crypto!

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?

It's still not clear if the protocol will support decentralization (private servers)

ok. I listened video and looks like it will be decentralized and it might work.

we still need till they come out with protocol spec, but such thing _can_ be implemented.

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.

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?

>What's with the weird goal amount though? Is there some significance there that I'm not aware of?

It seems to be 2^16 * 3

No idea what that means.

I'm impressed you worked that out.

It's a regular Hamming number. The 363th. Yeah, not sure what's the significance either.

Maybe the three of them working on it want 64k each because they like round numbers.

>using a mechanism known to be insecure

Can you elaborate? I'm not sure what you're referring to.

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.”

http://www.forbes.com/sites/kashmirhill/2013/08/09/lavabits-...

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.

Thanks for the clarification.

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.

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?

My inbox currently contains 5800 e-mails and takes ~500mb of disk space. Doing a full text search takes a bit, even on a laptop.

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.

You do not need the full text for search. You can hash every word and search hashes.

That sounds completely insecure.

Lavabit was vulnerable to three attackers:

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.

Are you sure, that Lavabit did not select PFS? Is this documented somewhere? That's quite a fumble for someboday advertising secure email services.

BTW: shouldn't we assume, that the US government operates at least an own intermediate CA for such purposes rather than getting single Certs signed.

Ladar says so in this interview, starting around 32:30:

http://www.youtube.com/watch?v=7LzKjxj0u_s#t=32m30s

Are there any other projects with similar goals that you would support?

Well tried NSA, but I'll try to fund the campaign.

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.

First shut down Lavabit (for whatever reasons). Then ask for donations to do something else.

This Kickstarter campaign reads like a What Not to Do If You Want Your Kickstarter Campaign to Get Funded.

23 minute video that isn't specifically created for the Kickstarter campaign? Check.

Very little explanatory text? Check.

Reward levels at different price points with identical rewards? Check.

Basic spelling errors (their != they're)? Check.

Campaign started by someone with a dog as their profile pic? Check.

I hope this project succeeds. I don't think this Kickstarter campaign will, though.

>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.

When I used the word reward I used it in the context of Kickstarter. That's the terminology they use: http://www.kickstarter.com/help/faq/backer%20questions

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.

I'm suggesting that if the $25 tier has nothing as a reward, the $100 tier should not also have nothing as a reward.

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.

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.

They are creating a new protocol to be adopted and marketed by other email providers (including Lavabit).

Those companies can take care of Grandma.

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?

Viewed slightly differently, given that news is mostly soundbites, which is going to be more memorable?

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.

This.

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".

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.

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.

Just call it SafeMail. Keeping it safe from prying eyes. It sounds both positive, and implies why you would want privacy.

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.

I nominate the name "NSA-Mail" -- No Spying Allowed Mail.

It's descriptive and co-opting the enemy's own name is the kind of thing people who want to stick it to the NSA can really appreciate.

Hahaha that's an excellent name! I'd love to sign up for that. Maybe with a little default footer in the emails that explains what the domain means.

Give in to your anger at the name; it will only make the Dark Side Mail Alliance stronger.

Or maybe, Dark Mail is like Blackmail, but with some plausible deniability?

(I agree, it's an awful name for appealing to non-criminals.)

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.

I've read over the SCIMP protocol. From their white paper, a sample message looks like this:

   <message type="chat"from='velma@silentcircle.com' to='daphne@silentcircle.com'
   id="0FF6CF98-32FE-4EED-9DEF-D66A0E50EA8F"><body/><x xmlns="http://
   silentcircle.com">?
   SCIMP:ewogICAgImRhdGEiOiB7CiAgICAgICAgInNlcSI6IDE1MDcyLAogICAgICAgICJtYWMiOiAiZlp
   YYURlQ1ljVTA9IiwKICAgICAgICAibXNnIjogIkloT051Sm9kK0Fjb09KQ1prZ0xHQXliSmJjbC9WNzhl
   cmMrSFY4K1FHcUJ2cEdlb2RaSWZwNTRKVWluU2g0N0lZTjFORkJOaXBjTVdubWlsMXVtbi9pcG5rVk8rd
   VJZdUJuQjdpZXZEK1pZQzBYV0hHQWQ3WWJtOWRsYkpSd0oyIgogICAgfQp9Cg==.</x></message>

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.

edit: relevant xkcd; http://xkcd.com/927/

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.

>> guarantee the recipient list won't be leaked.

Basically , if you

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 :

Neat, but they really need to repeat what's said in the video in the text. Currently it's not amenable to obtaining a quick understanding.

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?

> Am I missing something here?

Yes, watch the video. Or read the comments here with a summary.

Even the summary of the kickstarter says more than 'OSS the code.'

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.

Seriously? It's the first result for "dark mail".

http://www.darkmail.info/

I don't see any information on that page.

Those are the same partners, what are you saying?

Please show me the spec. Or even a high level discussion of the protocol.

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!

"Yet another communication system that offers better encryption" is not going to solve fundamental problem. Even if it is named "dark".

The communication system that conceals the very act of communication will.

The best way to conceal anything is to make others think that it never existed.

Pissing off enemies with stronger encryption will just get more people hurt and hunted for.

I like this project:

https://bitmessage.org/

Bitmessage is not very viable for mobile devices unless you offload hash cash to a server.

Then there's this, built on top of the protocol:

https://bitmessage.ch/

The source code is here:

https://github.com/AyrA/BitMailServer

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.

I used to support bitmessage, but they were unwilling to fix their gaping security wholes.

Donated. Good luck to Ladar.

Previous discussion: https://news.ycombinator.com/item?id=6642106

"sell the sizzle not the steak"

What is keeping this service from getting shut down as well?

It is a protocol, not a service.

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?

pledged.

I like the name didapper mail. A fun sounding duck inspired protocol.

Reply on news.ycombinator.com