moxiemarlinspike

Lavabit was advertised as a system that couldn't read users' emails. In reality, you were simply choosing not to read users' emails.

When you provided your SSL key to the government, all of your users' emails were compromised. That's unfortunate, but what makes it criminal is that your users were engaging with your service based on the promise that this wasn't possible. If you still believe that you were "removing Lavabit from the surveillance equation," that's a problem.

Ladar, I have great respect for your decision to notify your users that they'd been compromised (in violation of a gag order), and I will do everything that I can to help support you in your legal defense, but it's unforgivable that you knowingly misled users about your capability to access their email in the first place. To use handwaving about ECC cryptography in your advertising was just snakeoil, and I believe it should give us pause about supporting your future technical endeavors.

From @tqbf: https://news.ycombinator.com/item?id=6692321

Yes, it is completely true that there was nothing Lavabit could have done within the configuration of a standard SMTP/POP/IMAP server to be secure in the way that it advertised, without dedicated client support.

It's not Ladar's fault that the e-mail infrastructure doesn't natively support end-to-end security, but I do think that we should hold him accountable for advertising that his system provided a false level of security.

When people knowingly sell snake oil, I think we should hesitate to support their future security endeavors, particularly endeavors with virtually no technical information available in advance. What if it puts users at risk all over again?

As for whether the statement about the Lavabit system being "so secure that even our administrators can't read your e-mail" was true; I maintain that was indeed true. Without modifying the platform I was unable to access the account in question. That is why the government felt it needed to demand my SSL key. They were able to deploy resources I didn't have access to.

"Without modifying the platform?" I find it quite unsettling that you're hoping to develop a new secure email protocol and still think this statement has value. You could, at any point, have chosen to modify the platform. Not the kind of modification that would require earth shattering changes, but the kind of modification that would require adding a single line of code and typing git push.

What is the practical difference between choosing "not to modify the platform" (that you have complete and unfettered control over) and choosing not to read an email stored in plaintext?

Using this type of argument to sell security is the very definition of snakeoil. Again, I'd be interested if you could find a single well recognized contributor in the security community who would say otherwise.

Now if your claiming my statement was untrue because it was theoretically possible for an attacker to capture the plaintext data, then I have no response. Although I'd add that such an argument also means no system can claim it is secure because there is always a theoretically possible method of breaking the security of the system. For example its theoretically possible for someone with a quantum computer to efficiently break many of the cryptographic methods we rely upon today.

It wasn't "theoretically" possible for an attacker to use the encryption password that was being transmitted to the server in plaintext every 60 seconds by a POP/IMAP client. That's practically possible, and exactly what any attacker who compromised your system would do.

To compare the difficulty of using the plaintext being sent in the clear to an attacker with some other hypothetical attacker who would need to do groundbreaking research in physics (that many physicists feel is impossible) is frankly absurd.

What's really at issue is whether the SSL attack my system fell victim too was practical in 2006 when statements you are pointing to was written and posted on the Lavabit website. Based on the research I did in 2006 an attack against data in transit when protected via SSL was considered impractical for technical and legal reasons.

First, saying that you wrote something a long time ago is a strange argument for someone selling a security product. You should be accountable for what you're advertising, even if you've chosen not to update it for 7 years.

Also, this wasn't even a realtime interception attack, but a passive recording attack. Certainly in 2006, it was more than possible to record all the traffic to your system off a SPAN port without any difficulty at all.

Even realtime interception was no biggie then as well. By 2006, the only limit for sslsniff (freely available) on a single system was the number of file descriptors. Not to mention the commercial software like Verint available specifically to perform those types of attacks.

2006 is even the year that room 641a was exposed, so I'm not sure how you could claim ignorance on this.

The front page of Lavabit proudly claimed "so secure even we can't read your email." Either they really believed that, which means they have trouble understanding how security works, or they were being disingenuous. I'm not sure which is worse.

You're correct, Lavabit worked within the confines of existing email technology. A standard email service is vulnerable in three places: the service owner can choose to access user email, anyone who compromises the service can access user email, and anyone who compromises the SSL connection from the user to the service can access user email. Lavabit was vulnerable in exactly the same three places, despite all the cryptography handwaving.

In any other light, anyone in the security community would have laughed the Lavabit design out of the room, or written it off as just another snake oil security product. It's really not even a question, and I'd be interested if you could find a single well recognized contributor in the security community who would say otherwise.

Ladar is trying to do more handwaving with really embarrassing explanations of his "secure memory" system (insanely ridiculous and again, really troubling), but doesn't address the fundamental question of whether his primary security claim ("even we can't read your email") was true.

Let's also not forget that when Ladar complied with the government's request and provided his SSL key, the entire history of his users "secure" emails were compromised.

So here's the situation: we have someone who was either previously disingenuous or failing security first principles who is asking for funding for a followup endeavor that we have no technical details for, and are supposed to trust that he will develop appropriately. If the only metric we have to evaluate is Ladar's past technical performance, it seems like caution is in order. Because last time, 400k users were compromised unnecessarily.

I'd prefer it if you apologized to your 400,000 users for misleading them.