Live data from Hacker News

How Lavabit Melted Down

newyorker.com

161–170 of 177 posts

Re: How Lavabit Melted Down

#161
post #146

Earlier quoted context omitted.

"It was the best current technology could offer" Sure, if we ignore the existence of things like PGP, S/MIME, smart cards, and the dozens of other ways we can have secure email without relying on some trusted third party like this. "this technology was not meant to deal with the oppressive government that can compel any company to reveal any information" Then it was not meant to deal with the evil hacker who takes co…

How PGP or S/MIME would help you if any provider could be required to turn over all the traffic it gets, unencrypted? The only way you could securely communicate is peer-to-peer with the trusted party, but the email doesn't work this way. Unless you always send mail directly to your target's SMTP server which is hosted by the recipient himself (which kind of defies the whole idea of having email as a service and turn…

"the adversary would have access at least to the envelope information."

This is a strawman, because Lavabit never did anything to protect headers. What you are missing is that Lavabit could respond to a demand for plaintext, if Ladar were willing to do so; on the other hand, Google cannot give anyone access to the plaintexts of PGP encrypted messages that I send through their servers because of technical barriers. That is the point of doing your encryption locally, and that is why security and privacy are not a service.

"Indeed, it is not. If the hacker gets full control of your mailserver, at least your envelope information is completely compromised."

Except that with Lavabit, an attacker could also get all your message bodies.

"Security depended on adversary not having full access to the Lavabit servers, not on Ladar's "whim"."

Let's put it this way: if you were involved in a lawsuit against Ladar, would you trust your communications with your lawyer to Lavabit? Of course not, because Ladar could have modified the code at any time and without alerting his users at all to read any plaintext that he wanted to read. If he had been willing to cooperate with the government, he could have and nobody would have a clue.

"Assuming your adversary doesn't have full access to your service is kind of a precondition of using the service as means of security."

In other words, security is not something you can get as a service. The entire model is fundamentally and fatally broken.

"That's like using lock is assuming the adversary does not have the key, if he does, the lock is useless as a security measure"

No, it is like storing your key with the bartender at your favorite night club and assuming that he will not allow your adversaries to use it.

"As soon as Lavabit became essentially useless for the purpose it was created, it was shut down."

It was shut down because Ladar chose to shut it down rather than capitulate. He could have chosen to keep it going while the government eavesdropped on it instead. That means that, as I said, security boiled down to Ladar and his principles. That is why PGP and S/MIME provide you with better security: mathematics are not subject to the choices that human beings make, and with PGP, S/MIME, etc. your security is a matter of mathematics.

Re: How Lavabit Melted Down

#162

Earlier quoted context omitted.

Suppose that Lavabit sold smart cards for end-to-end encryption, and as a service would store ciphertexts for you. The government shows up with a warrant, Lavabit says, "Sorry, we cannot comply because we cannot access secret keys or decrypt messages by some other means." What exactly does the government do after that? The point is that Lavabit's architecture did not resist these kinds of demands at all. At best all…

So here's a hypothetical for you. Suppose we build an architecture which you feel is more secure. Then the NSA people say "we have analyzed it, and there's a theoretical information leak. because that information leak exists you have to install our software which will exploit it. but if you'd designed your system better you would have been okay. also, incidentally, you're now legally forbidden from fixing this leak."…

"Suppose we build an architecture which you feel is more secure. Then the NSA people say "we have analyzed it, and there's a theoretical information leak. because that information leak exists you have to install our software which will exploit it. but if you'd designed your system better you would have been okay. also, incidentally, you're now legally forbidden from fixing this leak.""

One of the features of a good security system is that there is no single party that can be compromised in a way that violates everyone's security. Basically, your example assumes that the system has a fundamentally risky design.

Even if you need a trusted party in your design, it should be the case that the party only has a limited ability to violate everyone's security. For example, consider an identity-based encryption system, which by its nature requires a trusted party to generate keys. Under the right circumstances, that party can delete the master secret key needed to generate keys; one can imagine setting things up so that the master secret is destroyed periodically, say once per month, so that only keys that were recently issued can be compromised if the authority is compromised (your identity under such a system might include some information about when your key was issued).

"I reject your justification and others which rely on a technical deficiency in Lavabit's implementation to endorse the legality and moral authority of the court's orders."

I think it would be fantastic to have a trustworthy government, but that is orthogonal to the issue here, because the security of a system like Lavabit is not limited to resisting court orders. Suppose the Lavabit have become as big as GMail i.e. big enough that the government might threaten an antitrust investigation if special favors were not performed. Suppose that a foreign government was trying to conduct industrial espionage against Lavabit's users, and surreptitiously installed eavesdropping software or equipment.

For that matter, suppose that you were personally involved in a lawsuit against Ladar. Would you communicate with your lawyer using Lavabit in that situation?

Also consider the reality that laws can change. It might take a massive terrorist attack to cause laws to change for the worse. Maybe a dictator will rise to power. Maybe people will just stop caring. Maybe it will be a combination of things, but the point is that building a system that relies on the law to protect users' rights is a fundamentally bad approach. It was not merely laws that stopped mass surveillance previously; when letters were sent primarily via the postal system, it was the lack of abundant and automatic copying that prevented mass surveillance. Laws are easy to change; widely deployed and widely used technologies are much harder to change (at least in ways that conform to the desires of politicians and governments).

Re: How Lavabit Melted Down

#163
post #146

Earlier quoted context omitted.

How PGP or S/MIME would help you if any provider could be required to turn over all the traffic it gets, unencrypted? The only way you could securely communicate is peer-to-peer with the trusted party, but the email doesn't work this way. Unless you always send mail directly to your target's SMTP server which is hosted by the recipient himself (which kind of defies the whole idea of having email as a service and turn…

"the adversary would have access at least to the envelope information." This is a strawman, because Lavabit never did anything to protect headers. What you are missing is that Lavabit could respond to a demand for plaintext, if Ladar were willing to do so; on the other hand, Google cannot give anyone access to the plaintexts of PGP encrypted messages that I send through their servers because of technical barriers. Th…

>>> This is a strawman, because Lavabit never did anything to protect headers.

Since SSL keys are mentioned, I assume SSL was used in communication. This means the claim that Lavabit did nothing to protect headers is false.

>>> Except that with Lavabit, an attacker could also get all your message bodies.

This is true, however body of the message may contain encrypted information, which is useless to observer. Envelope information can not be encrypted in a way that is not readable by the mail server, that's the point of the mail server.

>>> The entire model is fundamentally and fatally broken.

That is kind of what I was saying - that current technology of the email can not do what Lavabit tried to do if the adversary can do what the courts said it can do. I'm not sure what you're disagreeing with here.

>>> He could have chosen to keep it going while the government eavesdropped on it instead.

That would be a betrayal of his user's trust, since any claim about what his service does would be necessarily false and he would become a liar if he ever claimed his server allows to communicate securely. I agree that this boils down to one's principles. I think a principle of "don't lie to your customers" is a good one to have.

>>> That is why PGP and S/MIME provide you with better security

No they do not, unless you can establish a peer-to-peer channel with your other party. In which case you're not using email anymore. Neither PGP nor S/MIME can prevent adversary from collecting envelope information in emails, and unability to do this is what made Lavabit impossible to continue.

>>> mathematics are not subject to the choices that human beings make,

You seem to be either genuinely confused about how email works and what running a secure email server involves, or trying to say something else than you're actually saying, or not making any sense. There are no "choices" that allow you to create secure email server in situation in which Lavabit found itself.

Re: How Lavabit Melted Down

#164

Earlier quoted context omitted.

> i don't think this is the correct interpretation. in a court of laws, acquiring evidence is something procedural and governed by rules and regulations. having a third party (lavabit) acquire the evidence and then turn it over to the government is probably something that wouldn't pass muster in court due to chain of custody and other rules. Search for "$" on this page: http://paranoia.dubfire.net/2009/12/8-million-r…

On page 100 of the actual documents [1], the refusal was not based on chain-of-evidence concerns, but that by using the solution proposed by Levison, the FBI would not have real-time access to the data: The e-mail again confirmed that Lavabit is capable of providing the means for the FBI to install the pen-trap device and obtain the requested information in an unencrypted form. AUSA[censored] replied to Mr. Levison's…

Great point. On page 46 it says Levison "would be able to collect the data required by the pen register and provide that data to the government after 60 days (the period of the pen register order)."

Then, "The prosecutors informed Mr. Levison that the pen register is a devise used to monitor ongoing email traffic on a realtime basis and providing the FBI with data after 60 days was not sufficient."

So, I am not sure what to think. After some research I couldn't tell whether "pen register" data is required to be real-time. The original order on page 7 doesn't seem to say "real time", but there could be some legalese or other laws that imply it.

Levison was clearly dragging his feet, but it seems sort of bizarre that they escalated their demands in response. Why not just get him charged with contempt and move from there? Since they played the "we can't trust him since he's been uncooperative" card, does this mean they would have trusted him if he complied immediately? What if he immediately turned over info and it didn't help their investigation or went counter to their preconceived notions -- would they have accused him of withholding some and demanded his private keys anyway?

There's weird things on both sides here. It sounds like Levison's actions on the whole are not very defensible though. :/

Re: How Lavabit Melted Down

#165

Earlier quoted context omitted.

Sure, if we ignore the existence of things like PGP, S/MIME, smart cards, and the dozens of other ways we can have secure email without relying on some trusted third party like this. As I understand it Snowden was using Lavabit to communicate with journalists who didn't themselves have/use/understand PGP. Lavabit is technology you can use even if no-one else uses it. How do PGP and S/MIME solve the bootstrapping prob…

There is no bootstrapping problem. Snowden was also able to get journalists to use OTR, without relying on some web interface with questionable security claims. The problem with PGP and S/MIME is that the existing software is too hard to set up. It is hard to tell journalists to go use Thunderbird, get Enigmail set up, and publish a key. The situation is even worse with S/MIME, despite the built-in support in many em…

qr codes for gpg public keys - sounds a great idea. Any idea why no one done it yet - seems like it could be a simple transform from an ASCII armoured output.

Bookmarking reply

Re: How Lavabit Melted Down

#166

Earlier quoted context omitted.

This is an inaccurate account of events. If you read the actual documents [1], you can see that the FBI had exactly 2 demands: A pen register device, attached to his servers; and his SSL private key. That is the sum total of what they wanted: complete, near-real-time access to all of Lavabit's data. A physical device to copy the server traffic and send it to the FBI, and the SSL key, to decrypt that traffic. The stat…

It's entirely possible it's an inaccurate account of events. I haven't read all of the primary documents, just secondary sources. In your linked documents,Exhibit 1 is the original June 10th order. Attachment A of it(page 4 of the PDF) details what he was order to hand over. It does not mention SSL keys at all. Instead it asks for a bunch of meta-data. In fact, it explicitly doesn't even cover communication contents.…

The June 10th order is on page 2, and seems to be only for the Target's account details (not metadata on messages, AFAICT.) Page 19 (and again on 97) says "Mr. Levison provided very little of the information sought by the June 10,2013 order." This sounds like he did not refuse it, and may have actually not had much data to turn over since part of his business niche was to not collect that kind of stuff. (Page 98 says "Levison claimed 'we don't record this data'" although in context "this data" appears to be non-content message data, which would not apply to the June 10th order.)

The June 28th order ("pen register/trap and trace order", page 7) is the one he started refusing, then tried to negotiate on later. I think the order "that Lavabit shall furnish agents from the Federal Bureau of Investigation, forthwith, all information, facilities, and technical assistance necessary to accomplish the installation and use of the pen/trap device" includes keys implicitly. The June 28th Order Compelling Compliance Forthwith (to the earlier order on the same day) notes, "To the extent any information, facilities, or technical assistance are under the control of Lavabit are needed to provide the FBI with the unencrypted data, Lavabit shall provide such information, facilities, or technical assistance forthwith."

The first explicit order referring to keys seems to be the July 16th search warrant, specifically Attachment B on page 36. According to page 98, FBI agents discussed encryption keys with Levison as early as June 28th.

Re: How Lavabit Melted Down

#167

Earlier quoted context omitted.

There is no bootstrapping problem. Snowden was also able to get journalists to use OTR, without relying on some web interface with questionable security claims. The problem with PGP and S/MIME is that the existing software is too hard to set up. It is hard to tell journalists to go use Thunderbird, get Enigmail set up, and publish a key. The situation is even worse with S/MIME, despite the built-in support in many em…

qr codes for gpg public keys - sounds a great idea. Any idea why no one done it yet - seems like it could be a simple transform from an ASCII armoured output. Bookmarking reply

You have to use a very large QR code to do it. It won't fit on a business card and phones are picky about scanning them.

Re: How Lavabit Melted Down

#168
post #167

Earlier quoted context omitted.

qr codes for gpg public keys - sounds a great idea. Any idea why no one done it yet - seems like it could be a simple transform from an ASCII armoured output. Bookmarking reply

You have to use a very large QR code to do it. It won't fit on a business card and phones are picky about scanning them.

Sure, but we have key servers for distributing the actual keys. You would only need the fingerprint in the QR code.

Re: How Lavabit Melted Down

#169
post #163

Earlier quoted context omitted.

"the adversary would have access at least to the envelope information." This is a strawman, because Lavabit never did anything to protect headers. What you are missing is that Lavabit could respond to a demand for plaintext, if Ladar were willing to do so; on the other hand, Google cannot give anyone access to the plaintexts of PGP encrypted messages that I send through their servers because of technical barriers. Th…

>>> This is a strawman, because Lavabit never did anything to protect headers. Since SSL keys are mentioned, I assume SSL was used in communication. This means the claim that Lavabit did nothing to protect headers is false. >>> Except that with Lavabit, an attacker could also get all your message bodies. This is true, however body of the message may contain encrypted information, which is useless to observer. Envelop…

"Since SSL keys are mentioned, I assume SSL was used in communication. This means the claim that Lavabit did nothing to protect headers is false."

That is like saying that GMail is protecting the privacy of your headers, because GMail uses SSL.

"This is true, however body of the message may contain encrypted information, which is useless to observer"

Except that in the case of Lavabit, that encryption was just a side show since all the cryptographic operations were performed on the server.

"current technology of the email can not do what Lavabit tried to do if the adversary can do what the courts said it can do"

Except that someone who encrypts their message bodies before sending the message i.e. performing cryptographic operations locally leaves the server unable to fulfill demands for plaintexts.

">>> That is why PGP and S/MIME provide you with better security

No they do not, unless you can establish a peer-to-peer channel with your other party. In which case you're not using email anymore."

Really, you think I am not using email anymore if I am running my own personal mail server? It is also false to claim that one must have a peer-to-peer system to protect header information, or that PGP on its own is not enough. You could broadcast an encrypted message via Usenet. You could use anonymous remailers (e.g. "Type I" remailers, which use PGP). In all these cases, however, you need to perform your cryptographic operations locally.

"There are no "choices" that allow you to create secure email server in situation in which Lavabit found itself."

Sure there are: Ladar could have sold smartcards instead of selling cryptography as a service. There, one design decision that could have given his users meaningful security while still maintaining the convenience of webmail. To boost security even more, those smartcards could be coupled with a thumb drive that includes the necessary client software, so that Lavabit could not pull a Hushmail on its users.

Re: How Lavabit Melted Down

#170
post #167

Earlier quoted context omitted.

You have to use a very large QR code to do it. It won't fit on a business card and phones are picky about scanning them.

Sure, but we have key servers for distributing the actual keys. You would only need the fingerprint in the QR code.

Kind of defeats the point - how do you know you're downloading the private key you scanned?

While someone might have their business cards replaced, it's a lot easier just to send a different key to someone.

Post reply on HN