Lavabit’s founder responds to cryptographer’s criticism(arstechnica.com)
arstechnica.com
Lavabit’s founder responds to cryptographer’s criticism
http://arstechnica.com/security/2013/11/op-ed-lavabits-founder-responds-to-cryptographers-criticism/
1 comments
Levison's surprise that the DOJ could compel him to hand over TLS keys
This is the part that baffles me. The lavabit about page clearly identified the FBI and NSL as a threat. Lavabit was supposedly designed to be secure against the FBI, even if the FBI didn't play by the rules. But then he still expected them to play by the rules?
This is the part that baffles me. The lavabit about page clearly identified the FBI and NSL as a threat. Lavabit was supposedly designed to be secure against the FBI, even if the FBI didn't play by the rules. But then he still expected them to play by the rules?
Right! He even leads today's apologia with these words:
Lavabit was designed to protect the privacy of e-mail by allowing users to encrypt messages stored on the Lavabit servers. Once encrypted, an e-mail could only be decrypted with a user’s password. The system was made to protect messages on Lavabit’s servers from prying eyes. Quite simply, the goal was to remove Lavabit from the surveillance equation.
Quite simply, Levison failed to remove Lavabit from the equation, because Levison was only willing to provide privacy to a point where it didn't compromise convenience.
Lavabit was designed to protect the privacy of e-mail by allowing users to encrypt messages stored on the Lavabit servers. Once encrypted, an e-mail could only be decrypted with a user’s password. The system was made to protect messages on Lavabit’s servers from prying eyes. Quite simply, the goal was to remove Lavabit from the surveillance equation.
Quite simply, Levison failed to remove Lavabit from the equation, because Levison was only willing to provide privacy to a point where it didn't compromise convenience.
You cannot refuse to hand over data when given a warrant, but if the data is encrypted (and you do not possess the key to decrypt it) the information is essentially worthless and they won't throw you in jail for refusing to comply.
Fun fact: Lavabit turned over an archive of encrypted emails from Snowdens account when he was first contacted by the feds. Those emails are still perfectly secure, because Snowden is the only person who knows the password required to decrypt the mail files. The reason the feds demanded the SSL keys (a few weeks after he first turned over the emails) is because they could not decrypt the mail files and wanted to try and capture Snowdens password the next time he accessed his account.
Fun fact: Lavabit turned over an archive of encrypted emails from Snowdens account when he was first contacted by the feds. Those emails are still perfectly secure, because Snowden is the only person who knows the password required to decrypt the mail files. The reason the feds demanded the SSL keys (a few weeks after he first turned over the emails) is because they could not decrypt the mail files and wanted to try and capture Snowdens password the next time he accessed his account.
Well, they could be secure, unless the FBI also has a previously recorded session which they can now decrypt with the SSL key to recover the password.
Since 'tedunangst is being coy, let's be clear that what he's saying is that they aren't at all secure.
That is a key point--that no system can ever be secure as long as the host has some way of intercepting messages. The fact is that no matter how secure Levison makes the system, there will always be some way he could intercept messages if he really wanted to, even if it meant modifying the code a bit. And if he can do it, the feds can compel him to do it.
> no system can ever be secure as long as the host has some way of intercepting messages.
Erm, that's only the case for systems that use cleartext in transit. If you encrypt and decrypt (and we assume you're doing it right) at the endpoints then the intermediate can't do anything with the content.
Your 'no matter how' bit is correct, and it was flawed to rely on SSL for transit only and hope the law would protect the keys. Hence tqbf's point that using cleartext in-out is just plain bad to begin with.
Erm, that's only the case for systems that use cleartext in transit. If you encrypt and decrypt (and we assume you're doing it right) at the endpoints then the intermediate can't do anything with the content.
Your 'no matter how' bit is correct, and it was flawed to rely on SSL for transit only and hope the law would protect the keys. Hence tqbf's point that using cleartext in-out is just plain bad to begin with.
Not having had a need for this kind of secure email I didn't hear much of Lavabit until it went under. That being said, didn't it raise alarm bells with any of its users when the security model is essentially a black box (as Moxie points out) and the message in transit is only secured using SSL (turned out to be suboptimal there too).
What's the demographic for people who actually needed this service, and why didn't they spot those glaring errors earlier? Is it for lack of other services?
Just seems strange to me it took someone experienced like Moxie to be the first to finger this (and that's in hindsight).
What's the demographic for people who actually needed this service, and why didn't they spot those glaring errors earlier? Is it for lack of other services?
Just seems strange to me it took someone experienced like Moxie to be the first to finger this (and that's in hindsight).
People believe what they want to believe. If you're in the market for totally secure email, you're going to find something you believe is totally secure email.
Or, you're going to use something rock solid to encrypt your message and use some sensible approach to obscure your signals.
Not an expert here, but if you don't want to give out signals by the mere fact that you're sending an email with encrypted content, set something up to send encrypted messages regularly, at scheduled intervals, and allow a real message drop in on the queue. As long as your encryption method reveals nothing about the cleartext you can put something in the cleartext to notify your recipient this one is real. I say this in the hope nobody who needs these things for life and death situations will look at HN for advice.
Not an expert here, but if you don't want to give out signals by the mere fact that you're sending an email with encrypted content, set something up to send encrypted messages regularly, at scheduled intervals, and allow a real message drop in on the queue. As long as your encryption method reveals nothing about the cleartext you can put something in the cleartext to notify your recipient this one is real. I say this in the hope nobody who needs these things for life and death situations will look at HN for advice.
The previous reply wasn't to hack on your comment, just wanted to make that clear.
It seems to me a lot of people want totally secure email... in a pretty box handed to them. I don't see how you can achieve end to end security while relying on a middleman. Even if you control the middleman, it shouldn't be able to tell anything about your message (it has no reason to, so it shouldn't).
So you have to do the work yourself. Making that easier to do would be great as long as it doesn't add obscurity to the process.
Tl;dr I don't see totally secure email services provided by an external entity as a feasible thing.
It seems to me a lot of people want totally secure email... in a pretty box handed to them. I don't see how you can achieve end to end security while relying on a middleman. Even if you control the middleman, it shouldn't be able to tell anything about your message (it has no reason to, so it shouldn't).
So you have to do the work yourself. Making that easier to do would be great as long as it doesn't add obscurity to the process.
Tl;dr I don't see totally secure email services provided by an external entity as a feasible thing.
It is not possible to "FIX" security with email as it currently stands. That would require a completely different protocol and it wouldn't be compatible with any existing email platforms, so it would effectively be worthless.
There is a reason why a "perfectly secure" email platform does not exist, it is simply not possible to design such a system and maintain compatibility existing email software.
I'm not sure if you guys are just incredibly naive or if you lack common business sense or what the deal is. This is akin to bitching that Tesla isn't really "environmentally friendly" because they make electric cars and you really need cars that run on unicorn farts to be truly carbon neutral.
There is a reason why a "perfectly secure" email platform does not exist, it is simply not possible to design such a system and maintain compatibility existing email software.
I'm not sure if you guys are just incredibly naive or if you lack common business sense or what the deal is. This is akin to bitching that Tesla isn't really "environmentally friendly" because they make electric cars and you really need cars that run on unicorn farts to be truly carbon neutral.
> I'm not sure if you guys are just incredibly naive or if you lack common business sense or what the deal is. This is akin to bitching that Tesla isn't really "environmentally friendly" because they make electric cars and you really need cars that run on unicorn farts to be truly carbon neutral.
Someone releases a product. They say "This product is secure against well funded government agencies. It's secure against correctly-formed legal documented requests". Someone else comes along and points out that, in fact, it isn't secure against those threats.
That's not wanting a Unicorn-fart powered crypto system. That's just pointing out that a product doesn't, can't, work as advertised.
Some people get tortured or killed by their governments for saying the wrong thing, so it seems reasonable to point out that their communications might not be secure.
Someone releases a product. They say "This product is secure against well funded government agencies. It's secure against correctly-formed legal documented requests". Someone else comes along and points out that, in fact, it isn't secure against those threats.
That's not wanting a Unicorn-fart powered crypto system. That's just pointing out that a product doesn't, can't, work as advertised.
Some people get tortured or killed by their governments for saying the wrong thing, so it seems reasonable to point out that their communications might not be secure.
Can I call nonsense on that? Nothing prevents you from encrypting your actual message and there are plenty of options available to secure transit.
The reason such a platform may not yet exist is that it security is HARD (or cumbersome, or both).
The reason such a platform may not yet exist is that it security is HARD (or cumbersome, or both).
> It can be accomplished today, using tools with graphical interfaces that are available on all mainstream platforms.
Aww. Don't leave us hanging :) Does Linux count as mainstream? What are these interfaces? Do they cost money (I don't mind paying money - I pay money for snail mail). Can I roll my own? Does this mean Dark Mail is a more or less pointless endeavour in your opinion regardless of your opinions of the initiators? Enquiring minds would like to know.
Aww. Don't leave us hanging :) Does Linux count as mainstream? What are these interfaces? Do they cost money (I don't mind paying money - I pay money for snail mail). Can I roll my own? Does this mean Dark Mail is a more or less pointless endeavour in your opinion regardless of your opinions of the initiators? Enquiring minds would like to know.
You do not need to run Linux to have end-to-end encryption. Apple Mail has supported PGP and S/MIME for years. PGP is available for Windows, as are dozens of clients that support S/MIME. Worried about metadata? Remailers already exist and already provide as much security as is possible (don't trust the remailers we have now? You can run your own, as it only takes one trustworthy remailer to provide security).
"Does this mean Dark Mail is a more or less pointless endeavour"
I still want to know what Dark Mail does that current systems are not already capable of doing. What new design do we need? We have smart cards, PGP, remailers, and Usenet. At worst all we are missing is a nice front-end, and even that is a shaky suggestion. We are faced with an infrastructure deployment problem, not a problem with protocols.
"Does this mean Dark Mail is a more or less pointless endeavour"
I still want to know what Dark Mail does that current systems are not already capable of doing. What new design do we need? We have smart cards, PGP, remailers, and Usenet. At worst all we are missing is a nice front-end, and even that is a shaky suggestion. We are faced with an infrastructure deployment problem, not a problem with protocols.
Start by understanding this: end-to-end (e2e) security is not a crazy pipe dream. It can be accomplished today, using tools with graphical interfaces that are available on all mainstream platforms. Though we could surely use better, more convenient tools for providing it, there's no valid argument that is premised on e2e being intractable.
Marlinspike's argument was simple. Levison's site made expansive claims about its security properties. Marlinspike highlighted them. Then he explained how the system could only provide those properties under an "avert-your-eyes" attack model, because it was fundamentally a plaintext-in plaintext-out system. It could provide no security without Levison's own say-so, but could subvert its users the moment Levison's will or capabilities broke.
Levison replies with a series of technical details that are irrelevant to the avert-your-eyes problem. Levison thinks that marking memory secure was a meaningful countermeasure against a state-sponsored adversary (compelled disclosure was his stated threat model), because attackers would not have had the source code. This is a baffling statement in an era where people reverse engineer smartphone basebands for fun, because it's an obstacle that the FBI would have had no trouble surmounting in 1999.
Similarly, Levison's surprise that the DOJ could compel him to hand over TLS keys (in a configuration that Marlinspike points out wasn't even forward-secure --- that is, a configuration that provided sub-Google levels of resilience versus DOJ) doesn't have anything to do with Marlinspike's argument. If Levison's own keys determine the security of the system, it is an avert-your-eyes system. However meaningful you believe avert-your-eyes promises to be, the are undeserving of promotional security copy that discusses the details of asymmetric encryption.
Levison argues that it's unfair to judge his system by the standard of PGP. His system was designed solely to protect emails at rest. But that's a meaningless distinction, obviously so, because Levison had to shut his system down after being compelled to reveal keys that could decrypt prior sessions. Plaintext-in plaintext-out mail encryption is like a bulletproof vest you store in your attic --- perhaps useful for protecting you against bullets flying in your attic, but little else.
I believe we need two kinds of privacy enhancements: laws that constrain the actions of governments and limit the scope of investigations, and better privacy-enabling technology. But I have no illusions about which of those two enhancements users should rely on: they should ignore the limitations supposed for governments, and choose technologies that offer end-to-end security, where the endpoints make the judgement calls about the degree of safety they have, not the operator of the service.
And while that concludes my direct response to Levison's post, I'd like to make a tangential argument:
"I wasn't trying to fix security, only improve it" has for the last 20 years been the siren song of bad security systems. It lured customers into the rocks in the 1990s when it was used to rationalize stack canaries as a cure for memory corruption vulnerabilities, shipwrecked web developers with promises of "smart quoting", got Hushmail customers backdoored, inspired 100 different secret-salt password hashes, installed tens of thousands of packet sniffing "intrusion detection" systems on networks around the globe, and got us elliptic curve-based chat systems... incorrectly implemented in browser Javascript.
Alarm bells should go off in your head when you hear that sentiment spoken aloud. Loud ones. If you start to feel persuaded by it, tie your self to the mast: reinstall GPG, generate new keys, and refuse to send plaintext messages.