Op-ed: Lavabit’s primary security claim wasn’t actually true

Moxie Marlinspike is a cryptographer, software developer, and security researcher who regularly appears at the Black Hat security conferences. His critique of HTTPS Web encryption has led browser makers to change the way they implement it. He is also developer of the TextSecure and RedPhone Android apps for encrypting text messages and voice calls. In 2011, Twitter bought his encryption startup Whisper Systems for an undisclosed sum. The pseudonymously named Marlinspike originally posted this editorial on his ThoughtCrime.org blog.

In August of this year, Ladar Levison shut down his e-mail service, Lavabit, in an attempt to avoid complying with a US government request for his users' e-mails. To defy the US government's gag order and shut down his service took great courage, and I believe that Ladar deserves our support in his legal defense of that decision.

There is now an effort underway to restart the Lavabit project, however, which might be a good opportunity to take a critical look at the service itself. After all, how is it possible that a service which wasn't supposed to have access to its users' e-mails found itself in a position where it had no other option but to shut down in an attempt to avoid complying with a request for the contents of its users' e-mails?

The guarantee

This was the front page of Lavabit in July, the month before its shut down:

The front page proudly claims Lavabit is "so secure that even our administrators can't read your e-mail." That sounds like exactly what one wants from an encrypted e-mail provider, so let's drill down and see what the details are on that "secure" link:

Again, this sounds awesome. They advocate that in today's world, a service which merely promises to respect its users' privacy with a policy statement isn't enough. Users should demand technical solutions which employ the use of cryptography to protect their privacy. This is the critical difference between a service that "can't read" and one that "won't read" your e-mail, which was presumably the draw for many of Lavabit's 40,000 users.

The mechanics

But how did it actually work? And if, as Lavabit said, it wasn't capable of reading its users' e-mails, how could it have been in a position to provide those plaintext e-mails to the US government?

Unfortunately, Lavabit's primary security claim wasn't actually true. As Ladar himself explained in this blog post, the system consisted of four basic steps:

At account creation time, the user selected a login passphrase and transmitted it to the server.

The server generated a keypair for that user, encrypted the private key with the login passphrase the user had selected, and stored it on the server.

For every incoming e-mail the user received, the server would encrypt it with the user's public key and store it on the server.

When the user wanted to retrieve an e-mail, they would transmit their password to the server, which would avert its eyes from the plaintext encryption password it had just received, use it to decrypt the private key (averting its eyes), use the private key to decrypt the e-mail (again, averting its eyes), and transmit the plaintext e-mail to the user (averting its eyes one last time).

Unlike the design of most secure servers, which are ciphertext in and ciphertext out, this is the inverse: plaintext in and plaintext out. The server stores your password for authentication, uses that same password for an encryption key, and promises not to look at either the incoming plaintext, the password itself, or the outgoing plaintext.

The ciphertext, key, and password are all stored on the server using a mechanism that is solely within the server's control and which the client has no ability to verify. There is no way to ever prove or disprove whether any encryption was ever happening at all. Whether it was or not makes little difference.

Measuring up

A typical (unencrypted) e-mail provider has three main adversaries:

The operator who has access to the server.

An attacker who can get access to the server.

An attacker who can intercept the communication to the server.

Despite the use of cryptography, Lavabit is also vulnerable to all three, just like a conventional (unencrypted) e-mail service. The operator can, at any time, stop averting their eyes, an attacker who compromises the server can log the password a user transmits, and an attacker who can intercept communication to the server can obtain the password as well as the plaintext e-mail.

Even though Lavabit's security page went on at length about how, in the age of the PATRIOT act, users shouldn't accept a Privacy Policy as enough to protect them, that is almost exactly what it implemented. The cryptography was nothing more than a lot of overhead and some shorthand for a promise not to peek. Even though it advertised that it "can't" read your e-mail, what it meant was that it would choose not to.

Perhaps we're just not reading between the lines, and all this handwaving was a ruse designed to trick the legal system (by claiming it was "unable" to respond to subpoenas) rather than a ruse designed to trick Lavabit's users. That could have been a plausible experiment to try, but Hushmail already tried the exact same experiment a decade earlier and met the exact same fate.

It's not clear whether the Lavabit crew consciously understood the system's shortcomings and chose to misrepresent them, or if it really believed it built something based on can't rather than won't. One way or the other, in the security world, a product that uses the language of cryptography to fundamentally misrepresent its capabilities is the basic definition of snake oil.

The big question

In the end, the US government requested Lavabit's SSL key. One big question is why the government didn't just get a CA to make it its own.

Maybe it was just lazy and assumed that since Lavabit previously complied with government subpoenas, the company wouldn't resist this one. The other possibility, however, is that the government was more interested in past e-mails than future e-mails. If the government wanted access to e-mails that might have already been deleted, its own SSL certificate wouldn't help it.

We know that the US government stores large amounts of ciphertext traffic, and since Lavabit wasn't preferring perfect forward secrecy SSL cipher suites, the government would have been able to go back and decrypt previous traffic with Lavabit's SSL key.

When Lavabit did eventually provide the SSL key (albeit in really tiny font!), perhaps that's exactly what the US government did. Any user who signed up thinking they were using some kind of special secure e-mail was compromised.

The quest for secure e-mail

I think we should celebrate and support Ladar for making the hard choice that he did to at least speak out and let his users know they'd been compromised. However, I think we should simultaneously be extremely critical of the technical choices and false guarantees that put Ladar in that position. There is currently an effort underway to release the Lavabit infrastructure under an open source license, which I worry will result in more of the same. Given its technical foundations, I wouldn't advocate supporting the continuation of the Lavabit project.

Rather than funding Lavabit, if you're interested in supporting a secure e-mail project, I have two alternate recommendations:

Mailpile: Despite what anyone tells you, end to end encrypted e-mail is not possible in a webmail world. The first precondition for developing a usable and forward-secure e-mail protocol is a usable mail client, and I currently believe that Mailpile is our best shot at that.

Leap Encrypted Access Project: This is a secure e-mail project by people who fundamentally understand the challenges, the history, and the politics. They've been working on an incremental plan for developing a secure e-mail system with some really smart people, and I think we'll all benefit from their work.

Trevor Perrin has also been doing some excellent work on an asynchronous protocol for secure e-mail, which I encourage everyone to take a look at and follow along.

Promoted Comments

"Despite what anyone tells you, end to end encrypted e-mail is not possible in a webmail world."

Sure it is. Anything a stand-alone client can do, a browser can do....

Exactly. The author either doesn't understand that you can implement stuff client side (Javascript for example) or he is making the leap that because doing so could potentially be too slow (in execution cycles) to be usable equates to "not possible"

If you start doing the decryption with javascript, then there are a number of issues that make it impractical and not totally secure. The question of where the private key is stored still exists. For practical and usability reasons, it's most convenient for the service to maintain the keys on their servers. It's possible that those keys can be password protected to provide limited protection against snooping, but users are notoriously bad at picking good passwords. Alternatively, you have to find some way to let the user store the private key themselves, leaving them wholly responsible for keeping it secure and backed up.

But assuming you have a workable solution for private key storage, you also need a way for the browser to perform the decryption of the email content, which is separate from normal decryption performed as part of the SSL/TLS connection. If, as you suggest, this is done by some JavaScript in the page. Then that exposes a huge security hole.

If you give the JavaScript access to the key and the user's password for decrypting the key, then it is also possible for that script to send a copy of the password and/or decrypted key back to the server. You have to have a certain level of trust in the service provider that they won't do this. But, that is exactly what HushMail did, and they were forced to snoop the credentials of some specific users in order to turn over unencrypted emails to the authorities.

It's also, unfortunately, the approach taken by services like LastPass when you log in via the website, rather than the extention, or use their security check tool. Users have to trust that LastPass is never going to send any javascript for the purpose of stealing their credentials. But they could certainly do so if they were ordered to. They could theoretically even direct this malicious version of the script to a specific IP address or user account, so no-one else could possibly notice it.

But, let's assume you've solved the key storage problem and you have enough trust in the service provider to believe their scripts that they are sending you are not malicious, the next problem is that by having all mail encrypted, you basically lose all ability to search your email. You're limited exclusively to client side searching, and performing that in the browser is completely infeasible. You would have to download all encrypted mail from the server, decrypted it, index it and search it all with javascript, which runs in a single process in a web browser. Good luck solving performance issues with that.

The only way to solve this problem would be to run your own trusted private server with which you can entrust your private key, so that it can store, index and search all your mail for you, where you would have to be running your own private instance of a "webmail" service. But for all intents and purposes, doing that is, from the perspective of your email service provider, functionally equivalent to you running a standard IMAP client and receiving PGP encrypted mail.

113 Reader Comments

What a scam!But the similar analysis could have been done since the beginning . Too much biased advocacy journalism and lack of serious critique everywhere

Reading between the lines, I think you just nailed it. Right on the center.

I will be expecting the professional thing to do now, that would be to reach out to Ladar Levison, offering his right to response and posting it ASAP if he so desires.

It's no news that I'm not the sharpest pencil in the box, nonetheless I'm sensing a kind of a lightweight attack on him and his service. All cleverly disguised with technical arguments and sprinkled with a handful of accusations.

If this guy, a well respected security guru is right on the issues he addresses, and I have no reason to believe otherwise, he would do better reaching out to Ladar & Co. and offering his expertise, if in the end, he's altruistic enough to side with us the internet peasants and tech ignoramus.

Or at the very least his counsel, pro bono or not. Of course he is in no obligation to do so, but maybe he should have finished this article NOT ONLY by pointing to other promising alternatives, but also extending his much needed helping hand and wits.

Anyway, just my thoughts, now you can rape my ass with negative votes. Peace out.

For a long time I used email on Linux. When the SPAM got too bad I wrote my own SPAM filter. But it was a never ending arms race. I had to constantly update my SPAM filter. I finally gave up, got an account on GMail and changed the MX records to forward my email. GMail has an excellent spam filter. Although every spammer in the known Universe has my email address, I rarely see any SPAM. Without the GMail filter I could not use email.

Perhaps the point here is to use this crypto-email only for other encrypted email and all free text email would be rejected. But then you'd have to have too email accounts, one for common open text email and one that was only used for encrypted communication.

Most people are not going to go to this trouble. You would have to have something really covert to say. A more usable course would be to have email that can do both encryption and open text. But then this runs into the SPAM problem.

This issue can not be set aside. I ran my own email servers for fifteen years but server side and client side combination could not come close to stopping the spam. Last time I checked my spam folder i was still getting hundreds of spam messages a day. Perhaps improvements have come since I switched but I used to spend way too much time getting through spam to get to my actual email. Which I get more than I can manage as is.

The big picture is about more than just privacy, usability is a huge factor and that is why there is no easy of perfect solution out there.

Sure it is. Anything a stand-alone client can do, a browser can do. You just have to do all the crypto client side, in the browser, and never give your keys to the server, but rather carry them with you yourself from machine to machine.

The problem with that, is that in this scenario, the weakest link isn't the crypto on the message itself; it's the fact that you download the code to do the crypto afresh, every time you hit the website, and you have limited ability to verify the code, and no ability to be selective about what certificate authorities you're willing to accept when downloading code via HTTPS. With downloaded clients, you are at least alerted if the code is going to change; and you do have the ability to verify signatures on code updates for Java, C#, and Android apps, and the option to perform extended authentication of the updates before you install them. Not so with a browser app.

It seems to me that you have to ask some serious questions about your email provider and your ISP within the troubling context of the Patriot act. Setting aside the question of how you decide whether you trust your email provider (which is, in fact, a very difficult question), you also have to consider the question of what things the government can compel your ISP and email provider to do, with an without a court order in hand. If "feed that person a modified javascript file that leaks information on a back channel" falls within the scope of pen trace orders, or wiretapping orders (and it seems to me that it might), then ISP and email providers may not have any choice in the matter.

The most significant advantage I can think of that that native apps have over browser apps is that the software for your client doesn't have to come from an ISP or an email provider that may be subject to coercion under the various telephone acts, and the Patriot act. That's not an option with a web application.

I can see how this might be more heavily encrypted... But wouldn't this only encrypt what you send yourself? How does this help if all other mail server on the planet would send you plaintext when email is travelling through them?

I guess I am having more questions than answers...

There are a few things in that. First, the passphrase should never be sent to the server. Ideally, the server shouldn't even hold onto the key, but if they really must then the key must be sent to the client, the passphrase entered there, and then decryption also done at the client. Of course, then you have to trust that the client-side code isn't just forwarding on your passphrase to the server anyway...Lavabit was a little bit more than 'on server storage that is encrypted' because it didn't actually store your passphrase (although as MM pointed out, that's just because they chose not to; that could have changed at any moment). That meant that so long as they didn't keep your passphrase, and so long as the SSL traffic wasn't decrypted (because it contained your passphrase) your data was safe at rest on the server when you weren't using it. That's some big ifs through.

In terms of encrypting incoming mail: that can be achieved by having a public key on the server which is used to encrypt your incoming e-mail. That way, only your private key (which as discussed earlier, should really stay with you and not on the server) can be used to decrypt it.

In brief: if you're decrypting at the server end, then the server can cheerily spy on you.

What we need to do (and will never happen due to practicality) is completely replace all of the email protocols with new versions that weren't designed in the Internet equivalent of the stone age.

I agree with this 1000%. A ground up new protocol built with security first is what is needed. However it is almost impossible for any of the underlying fundamental pieces of the Internet to be changed.

Well he's correct, as usual (Moxie never really gets this stuff wrong). Their mistake was trusting SSL/TLS for anything...

Yes and no. The release of Lavabit's SSL key allowed any previously collected SSL traffic to be decrypted, which compromised all the keys stored on the server because the previous traffic included passphrases being sent to the server. Had Lavabit been using ephemeral keys for TLS/SSL, then releasing of their SSL key would not have compromised that previous traffic, because using ephemeral keys (e.g. DH or ECDH agreed keys) provides forward secrecy.

That said, holding private keys on the server and sending passphrases from the client to the server in order to perform decryption was also a mistake in design (although a hard one to avoid with web-based email).

Edit: Note, I agree with you about sketchy CA providers. For the current SSL/TLS cert infrastructure to work, you have to trust companies that you know will roll over and make certificates for sites they shouldn't - as has happened in the past.

Mailpile: Despite what anyone tells you, end to end encrypted e-mail is not possible in a webmail world. The first precondition for developing a usable and forward secure e-mail protocol is a usable mail client, and I currently believe that Mailpile is our best shot at that.

I don't quite get what he is saying here. "Secure webmail is not possible, thus I recommend this webmail client." I'm obviously missing something.

Mailpile is webmail, but it runs on your own workstation.

This is what I don't understand. That is, I understand "webmail" as meaning that you use your Web browser to view a Web page, so you don't have to install a separate email application. So I'd think running webmail on my own workstation would mean running a Web server locally only, and using my Web browser as my email client. I don't see what advantage this would have over a typical email client.

Given that several people I generally trust recommended Mailpile, I decided to support the project, and I get their newsletters and so forth, but I'm not actually sure what they're doing. Creating an email client that makes it very easy for end users to use public key encryption is definitely worthy of support, but I'm confused that all I see discussed is that Mailpile will be self-hosted webmail.

Sure it is. Anything a stand-alone client can do, a browser can do. You just have to do all the crypto client side, in the browser, and never give your keys to the server, but rather carry them with you yourself from machine to machine.

The problem with that, is that in this scenario, the weakest link isn't the crypto on the message itself; it's the fact that you download the code to do the crypto afresh, every time you hit the website, and you have limited ability to verify the code, and no ability to be selective about what certificate authorities you're willing to accept when downloading code via HTTPS. With downloaded clients, you are at least alerted if the code is going to change; and you do have the ability to verify signatures on code updates for Java, C#, and Android apps, and the option to perform extended authentication of the updates before you install them. Not so with a browser app.

Couldn't that be solved with some sort of open source browser plugin to do the encryption?

I think that any secure web based solution has to work in a world without plugins as I know of no plugins that you can install on an ipad. Especially if you want any sort of mass market adoption. Now one way you could achieve this is by setting up a secure, trusted login service that only acts as a key and decryption repository (a la Facebook, Google, Microsoft, et al but secure and trusted) that's fully audited by the cryptographic community. Then have the communication go through that service.

However any web based solution inherently requires there to be trust of the communication and decryption service.

Another thought is that you could never keep lots of emails because of the increasing difficulty of changing a compromised key.

If anybody can explain, why is it that encrypted messaging found under Android and iOS app stores have working models of end to end, locally encrypted communications, along with ZRTP communication embedded within the XMPP protocol can be achieved but not email (assuming future protocols)?

Splendid, I am not a complete idiot after all. It was even worse than I expected - who would have thought that even the transport was unencrypted (beyond regular TSL/SSL). I would like to understand why MM rules out all webmail. Obviously it is the client that should do the decryption and it needs to be immutable (completely under the control of the user) and it must have information that the server cannot access. But why could an add-on or extension not do the job? Is it because of current browser (in)security architecture?

It also boggles the mind why an intelligent NSA contractor like Snowden would have ever used this service (did he really?). Or whether he used it for anything sensitive at all.

The main problem with any "secure email" providers is that if your incoming emails are unencrypted you cannot avoid trusting the server and network operators. And if your parties already send you encrypted emails then you do not care whether your provider is secure (they can only do denial of service). Where is the market for secure email companies then...

Oh noes this is sad! At first I was happy that he made an unbreakable email system, then sad that he just gave up instead of fixing his security holes. Now I am scornful that he is just another HBGary security wannabe. Stop toying with my emotions Ars!

"Ooh, I made this dramatic attention getting gesture. Hey lookit all the free publicity, it's going to rake in millions when I invent my new Awe-Somo 5000 mail system. Man I hope the bad "secure mail" I wrote before does not become public and ruin my bogus rep."

None of this matters until an implementation is created which is as easy for people to use as Gmail. IE. Not needing a FAQ or detailed, multi-page instructions for setting up email with encryption.

Maybe you don't like what the NSA did, but the fact is we don't really know what they were after or why and whether they had probable cause or not. I definitely don't like it that under the current laws, they didn't need it, and that's definitely a problem.

But that does not excuse Lavabit for tricking their customers into thinking they were getting secure email when Lavabit was either completely incompetent or intentionally committing fraud.

If what the article says was is true, not only should Lavabit be shut down, but its principles AND its programmers should be going to jail for fraud.

In fairness to Lavabit, I don't see any difference between their claims and the representations Apple has made about its purported inability to read people's iMessages. At one level, the problem here involves the semantics and what the word "can't" means.

That's nonsense, and you should know it. And did you really have to bring Apple into this? iMessages are encrypted from when they leave the phone, so there is a big difference in the amount of effort any company operator would have to go through to read the messages, and a big difference in the amount of eye-averting happening at Apple vs Lavabit. In both cases the use of the "can't" might be incorrect, but there is still a big difference.

If anybody can explain, why is it that encrypted messaging found under Android and iOS app stores have working models of end to end, locally encrypted communications, along with ZRTP communication embedded within the XMPP protocol can be achieved but not email (assuming future protocols)?

First note that while in themselves secure, those protocols are breakable by several routes as explained in previous Ars articles.

Next, note that they are all examples of single providers.

Third note that they provide messaging, and not email.

Now on with the show. The Apple thing works something like this (or something analogous can be done this way):

Each device generates its own secret / public key pair. This is done by its TPM (trusted platform module) hardware or something similar. Separately a user authenticates to the device. This authentication enables use of the underlying key pair. Perhaps an application specific key pair is generated from these two keys etc.

Next, the central service (say Apple) stores the public key for the service for each device.

Finally, Alice sends a message to Bob. Her device retrieves Bob's public key and encrypts and authenticates the message using some well known secure algorithm. This is done for each of Bob's devices. The message can then travel all the way to one or more of Bob's devices which each use their own unique keys + Alice's public keys to decrypt and authenticate.

We know this end to end process is secure because of the underlying mathematical security.

Ok fine, so why not do that for email? Note the part that it is messaging where it is ok to lose old messages when you replace a stolen phone or get a new one (new keys generated on device, old info goes bye-bye). Also it is strictly Apple - Apple. You could implement this for say gmail - gmail users. Why bother though? Any outside of gmail CC leaks it becuae it is plain text. Or to make it inter-operate you need massive new infrastructure to handle the keys. This means certificate authorities not just for big corporations with web sites etc. but for every single email user and every email account they ever create. Doable in theory but are you willing to fork over the money for that? Btw, the existence of gmail is proof that statistically you are unwilling to pay for email for any reason whatsoever. Implementing the equivalent of a CA is trivial inside a company, but between companies costs money and introduces massive risk, especially when using a pot smoking Dutch CA.

But omg, secure email is super cereal important! No it is not. As long as people use porn download programs and click on anything that pops up on their screens, email security is irrelevant.

I've been using Thunderbird, GPG and Enigmail for a while now and it works as a desktop email solution. Message headers are not encrypted but the message contents are, when stored on my desktop or on an email server and when in transit. The weak point is the private key - crack that and all my current and past messages can be read, but at least I'm not sending my private key password in plaintext to a server like with Lavabit.

This would work on mobile devices if we can get desktop-level storage and processing power. My Thunderbird IMAP and POP mailboxes are a few gigs each but K9 on Android chokes on huge mailboxes.

Why not treat email as an inherently unreliable service? Let the message contents be encrypted and signed, sender/receiver optionally encrypted, then let it bounce along as many peer-to-peer paths until it arrives. The NSA can have a free peek too You don't look at the server paths to see if it's spam, you verify the message authenticity and sender ID based on the signature.

Yeah I have used that exact combo too. It lasted for a few months but I just could not be effed to constantly type in passwords and stare at unintelligible rubbish that ... again with the passwords wth!

Insecure gmail is such a superior solution. I recommend getting rid of whatever it is you do that requires secure email.

If it is a company that needs it then put up with it for the money they pay you of course!

Marlinspike is obviously right in his analysis, but not in his critique.

What continues to worry me (in this story, but also in the story about Chrome "protecting" your passwords with the keychain password), is the amount of technically literate people among the Ars crowd, that seemingly expect the impossible.

An IMAP provider can't do asymmetric crypto client side. A webmail provider could, but really shouldn't, because you're downloading the encryption code from an untrustworthy provider every single time.

Lavabit as an IMAP and webmail provider did what best it could do: protect data at rest. They came up with an architecture that did exactly that, given the intricacies of email. Anything more would require a different client access protocol, which could easily rely on Lavabit's server architecture as is. But you can't expect the impossible.

The biggest mistake they made, which we can scald them for, was not using PFS in SSL. Because of it, we must assume all past emails have been compromised at this point. They should've done better here.

If anybody can explain, why is it that encrypted messaging found under Android and iOS app stores have working models of end to end, locally encrypted communications, along with ZRTP communication embedded within the XMPP protocol can be achieved but not email (assuming future protocols)?

The main reason (I think) is software. Some XMPP clients just have encryption and key exchange built into them, and so take care of it. With e-mail, that is much less the case.

Part of that is probably because setting up the encryption is really easy when both ends are online at the same time: there are key exchange protocols specifically for that purpose. There are limitations - online key exchange where you don't already have some pre-existing authentication is vulnerable to man-in-the-middle attacks, but these attacks have to be made during the initial encryption set-up.

With mail, the keys need to be generated, then exchanged using a mechanism that isn't synchronous. I need to drop my key somewhere so you can get it to e-mail me. They are key servers out there to achieve that, but they don't seem to be widely used. Also, the software to generate and upload the keys seems to be pretty clunky.

Another reason is that people basically accept crappier security via XMPP and ZRTP. Particularly with XMPP where you are communicating via a central server, it is trivial to intercept all communication and just apply a MITM attack. Supposedly, the idea is that you should check the fingerprint when you're interacting with the other person - ideally via a sideband so someone doing a MITM can't just change the fingerprint in transit to make it look OK. However, virtually no-one does that. They just kind of assume there isn't an intercept and run with it. Some software (e.g. Moxie's own TextSecure) allows you to check the key if you have both endpoint devices together at some stage - you can check the keys directly.There are some ways to avoid this risk: having signing keys which you can use to sign the session keys and allow validation. However, you still have to validate them the first time you interact, or exchange them via some other means (which brings you back to the original key distribution problem).

A third reason is that for e-mail keys, people tend to be told to use passphrases on their keys. That generally isn't the case for IM clients etc. For some unknown reason, having your IM client key stolen and able to be used without a password is pretty much ignored as a problem, whereas having your e-mail key stolen is considered much more serious.One possible reason for that is that keys used in IM, ZRTP etc are ephemeral: that is, the key actually used for the interaction is created at the beginning of the interaction, used for the conversation, then destroyed. Even if someone steals your IM key, they can't use it to read your previous conversations if they've captured the network traffic. The same doesn't apply for e-mail. Because e-mail can't synchronously create session keys, it uses the main key (e.g. the GPG key) as the key. If someone gets your key, they can read all of your previous encrypted email.Moxie (and others) have made some efforts to come up with ways to allow for 'session' type keys with e-mail, but it is a hard problem.

In summary, though, the basic reason that encryption is easy with XMPP clients and ZRTP and is hard with e-mail comes down to the ease of key exchange, and usability of software.

(regarding MITM attacks on OTR, etc: OTR now uses what's called the 'socialist millionaire' problem to try to detect MITM attacks, but I don't know how - or if - it works).

That's nonsense, and you should know it. And did you really have to bring Apple into this? iMessages are encrypted from when they leave the phone, so there is a big difference in the amount of effort any company operator would have to go through to read the messages, and a big difference in the amount of eye-averting happening at Apple vs Lavabit. In both cases the use of the "can't" might be incorrect, but there is still a big difference.

No, it's not. He is absolutely right.

Data in flight was encrypted every step of the way, and data at rest was irrecoverably encrypted as well. Somewhere in the middle data was unencrypted in RAM, but still, Lavabit can't be taped without Lavabit's cooperation. If it could we wouldn't be discussing their corporate harikiri.

iMessage may be end-to-end, but Apple is the central directory for iMessage public keys. With Apple's cooperation tapping a user is as easy as providing anyone who sends messages to him with a different key, and standing in the middle watching. Would Apple harikiri before swapping Snowden's keys?

Assuming a system like iMessage can offer the assurances Apple did, because of [buzzword] end-to-end asymmetric encryption [/buzzword] is another mistake the Ars crowd seems to fall for every single time.

An IMAP provider can't do asymmetric crypto client side. A webmail provider could, but really shouldn't, because you're downloading the encryption code from an untrustworthy provider every single time.

I'm not quite sure what you mean here. Encryption works fine with IMAP, but it is done at the client side rather than the server side. It's true that the provider can't do asymmetric crypto client side, but that's because they don't exist at the client side - the client software does. That said, if the client software is not encrypting the content then the IMAP (or any other) provider can do nothing but store the data encrypted at rest, and then at best getting a passphrase from you to use on the key to decrypt it - which is basically useless. (Edit: I think the latter is what you were saying - people expect an IMAP server to be able to encrypt for them, but that's just not how it works so they are expecting the impossible)

Re: the webmail: you're spot on - if you're downloading the code each time, then it can just be changed to harvest your key and passphrase.

The real problem with encrypted email is not in the user interface of the clients. You can make the UI for choosing to encrypt an email when you send it completely user friendly, or even completely automated and transparent. You can even forego services that would require the server to have access to your unencrypted email, such as server side search and indexing. But, the underlying problem still exists: The secure generation, storage and exchange of keys.

Users who have public/private key pairs need to be really proactive in storing their private key in a location where it is readily available to use when they need it, secure enough to prevent third parties accessing it, and unlikely to get lost.

Hosts like HushMail and Lavabit worked around this problem by managing the keys for the user, at the expense somewhat reduced security. Letting a user manage their own keys is certainly more secure, but extremely difficult.

Private keys can be password protected and stored server side. But users are notoriously bad at picking good passwords, especially if they have to enter them frequently. If an attacker gets access to the password protected private key, the possibility of bruteforcing the password is a very real threat, and there is no chance of ever changing the password once they have it to thwart their attempts.

I keep a backup of mine on a remote server, but the key itself is password protected, and the key file is contained within a password protected archive that is encrypted with a different password, and both passwords are really long, completely randomly generated passwords that I spent weeks committing to memory and learning to type efficiently. That kind of security for private keys is well beyond what most users would be capable of, let alone willing to attempt.

Using the key requires me to explicitly install it into my email client, which basically means for any encrypted mail, I’m restricted to using only my trusted devices on which I’ve installed my key. I could never access my encrypted mail when I don’t have access to my own computers.

Distributing my public key to senders is also a problem. Although my public key is published on my website and in various public key servers, people sending me mail don’t take the effort to look up my public key and use it before sending me mail. People to whom I’ve sent signed email would have my public key, but I haven’t previously emailed everyone who would ever want to send me email. This is something that could potentially be handled automatically by the mail client, if it were to send a request to a pubic key server for my public key before sending mail. But then there is still the problem of verifying that the retrieved key really is mine, and not that of someone pretending to be me.

Participating in the web of trust schemes used by GPG/PGP is a hassle, and is really only something that a handful of geeks take the effort to do. It is also only a subset of the already small number of people who’ve taken the effort to generate their own keys, and so not something that the average user could ever realistically rely on for verifying the authenticity of keys.

I'm not quite sure what you mean here. (...) That said, if the client software is not encrypting the content then the IMAP (or any other) provider can do nothing but store the data encrypted at rest, and then at best getting a passphrase from you to use on the key to decrypt it - which is basically useless.

I mean the above, but I don't think it's useless. Encrypting all user data at rest in a way it can't be retrieved without the user password is a meritory goal in itself. Inevitably, you're going to be doing off site backups. Protecting each user's data individually is important.

Lavabit also doesn't preclude one from using S/MIME or PGP. I'd say anyone sufficiently security conscious to be using a provider such as Lavabit should use S/MIME or PGP for any sensitive content, and have it deleted ASAP.

Even with S/MIME or PGP, I find some properties that depend on the email provider (as is) useful. As I said above, I find it useful for an email provider to encrypt data at rest with the user's password. I find it even more useful for email providers to demand TLS be used on every SMTP connection, as well as checking the certificates used in those connections. Anything that can prevent wholesale tapping of everyone's data at the exchange, anything that can force adversaries to expend effort to access each individual's data, helps.

The real problem with encrypted email is not in the user interface of the clients. ... But, the underlying problem still exists: The secure generation, storage and exchange of keys....

This is pretty spot on. I think software with poor usability characteristics is a big part of the problem, but key distribution is an even bigger problem.The web of trust is difficult to participate in, but it could be made easier with software. For example, apart from the basic issue of whether I can trust my phone with Google services installed, there is no good reason why and friend and I shouldn't be able to easily mutually sign keys using just our phones. Similarly, there is no good reason that I shouldn't be able to use a QRCode or equivalent from a business card, or indeed from another person's phone display at a conference, to get their public key.Of course, the other side is that if it is too easy then people may be too careless. If I'm signing your key, I really need to be very bloody certain that you are who you say you are. For a government, ID are reasonably straightforward to forge so signing someone's key based on nothing but an ID check is insufficient. Really, I should only sign keys for people I have known for some time - ideally years.

Anyway, I guess what I'm saying is that key distribution is a big problem, but that it is made much worse by bad software making key exchange more difficult than it needs to be.

That's nonsense, and you should know it. And did you really have to bring Apple into this? iMessages are encrypted from when they leave the phone, so there is a big difference in the amount of effort any company operator would have to go through to read the messages, and a big difference in the amount of eye-averting happening at Apple vs Lavabit. In both cases the use of the "can't" might be incorrect, but there is still a big difference.

No, it's not. He is absolutely right.

Data in flight was encrypted every step of the way, and data at rest was irrecoverably encrypted as well. Somewhere in the middle data was unencrypted in RAM, but still, Lavabit can't be taped without Lavabit's cooperation. If it could we wouldn't be discussing their corporate harikiri.

iMessage may be end-to-end, but Apple is the central directory for iMessage public keys. With Apple's cooperation tapping a user is as easy as providing anyone who sends messages to him with a different key, and standing in the middle watching. Would Apple harikiri before swapping Snowden's keys?

Assuming a system like iMessage can offer the assurances Apple did, because of [buzzword] end-to-end asymmetric encryption [/buzzword] is another mistake the Ads crowd seems to fall for every single time.

Ok, then maybe there was some info I don't have, but I read the article and to me it states plainly that in Lavabit's case there was no encryption going on sending or recieving, only, if you trust Lavabit, in storing on their servers. This is very different and much less secure than what Apple does. The two cases thus can not be seen as being the same or similar, from a point of view of for instance the operator's easy of interception. Possible in both cases, yes, but much more difficult in Apple's case. Just because you want to label end-to-end-encryption a 'buzzword' doesn't make it so, or irrelevant. Or if you think so, please explain.

Marlinspike confirms the confusion I had when first digging into this story. At the time, I questioned it in the forum, but was told that there were two different types of accounts, one free and one paid, and while the free account indeed made it possible for mails to be read, the paid one didn't. Was that in fact not quite correct? I haven't dug through all the comments here, so sorry if this question has already been addressed.

Ok, then maybe thee was some info I don't have, but I read the article and to me it states plainly that in Lavabit's case there was no encryption going on sending or recieving, only, if you trust Lavabit, in storing on their servers.

Data in flight was protected through SSL/TLS when accessing the server through HTTPS, IMAP or POP3 and hopefully SMTP as well. Data at rest was protected by asymmetric crypto, and was irrecoverable without the user's password. Data in RAM was unencrypted, as needed for an IMAP and webmail provider, unless you used S/MIME or PGP, which you could and should do, and which puts you in control.

This is very different and much less secure than what Apple does. The two cases thus can not be seen as being the same or similar, from a point of view of for instance the operator's easy of interception. Possible in both cases, yes, but much more difficult in Apple's case. Just because you want to label end-to-end-encryption a 'buzzword' doesn't make it so, or irrelevant. Or if you think so, please explain.

In iMessage, end-to-end is a buzzword because Apple controls both the keys, the end-point software and the undisclosed protocol. You trust Apple with authentication, you trust them not to MITM messages, you trust them not to leak keys, you trust them not to have backdoors in the protocol, you trust them not add backdoors in the future, and you take their word on it all.

I keep seeing people grouse about how Gmail (or webmail) convinced people that email should be free -- but there have been completely free email accounts for at least 20 years, and they also came as 'freebies' for anyone that paid for internet service or attended a university.

The problematic changes that truly led to this mess were two-fold:1) Organizations decided to stop hosting their own mail servers and pay Google to have Gmail addresses with their own domain attached. I don't know how cost-effective this is; I do know that my previous ISP, Sonic.net, had near-perfect spam protection via SpamAssassin.

2) People were encouraged to stop using POP3 and transition to IMAP, despite virtually none of us having a reason to need 24/7 access to our full email archive and the existence of the 'leave mail on server' option for when we did check away from home.

The real question, I guess, is how we could possibly change the above two situations?

If webmail itself is also a security issue, then add that, but it shouldn't be *that* big of a deal; there were a lot of decent clients when they were the norm, and they weren't remotely "hard" to set up (writing in in "pop.my.isp" and "smtp.my.isp" was about it). With people heavily relying on mail client apps on smartphones, it shouldn't be that hard a transition -- all we'd need is to find a way to make them easily sync with people's laptops & tablets...

How about support anyone who is interested in privacy rather than an either or proposition. Clearly Lavabit could have kept quiet, even if you think their claims were bluffs or lies; the guy running it did seem to care in the end about privacy. The most folks that are supported in this area the more people will see it as a market and the more chance of a real solution. No money, no chance.

Crazy. One clarification - When the article says LB stored the passphrase on the server, does that mean that:a. It is storing the plaintext or whatever copy of the passphrase in a file or database somewhere; orb. That the passphrase is not actually permanently stored, but the article is just referring to it being stored ephemerally in memory at the time of decryption, and not much longer than that?

I ask because (a) seems like a massive oversight, while (b) is a lot more design out of the system.

"Despite what anyone tells you, end to end encrypted e-mail is not possible in a webmail world."

Sure it is. Anything a stand-alone client can do, a browser can do. You just have to do all the crypto client side, in the browser, and never give your keys to the server, but rather carry them with you yourself from machine to machine.

(For broad values of "can" and "just".)

Exactly. The author either doesn't understand that you can implement stuff client side (Javascript for example) or he is making the leap that because doing so could potentially be too slow (in execution cycles) to be usable equates to "not possible"

For a long time I used email on Linux. When the SPAM got too bad I wrote my own SPAM filter. But it was a never ending arms race. I had to constantly update my SPAM filter. I finally gave up, got an account on GMail and changed the MX records to forward my email. GMail has an excellent spam filter. Although every spammer in the known Universe has my email address, I rarely see any SPAM. Without the GMail filter I could not use email.

Perhaps the point here is to use this crypto-email only for other encrypted email and all free text email would be rejected. But then you'd have to have too email accounts, one for common open text email and one that was only used for encrypted communication.

Most people are not going to go to this trouble. You would have to have something really covert to say. A more usable course would be to have email that can do both encryption and open text. But then this runs into the SPAM problem.

Personally, I wish that G-mail would go the 'nuclear route' and contact the people/ISP's of the people who are sending all of that spam e-mail and have their internet connections revoked until they clean the spambot on their machines.Yes, that is what it is 90% of the time.

What a scam!But the similar analysis could have been done since the beginning . Too much biased advocacy journalism and lack of serious critique everywhere

Reading between the lines, I think you just nailed it. Right on the center.

I will be expecting the professional thing to do now, that would be to reach out to Ladar Levison, offering his right to response and posting it ASAP if he so desires.

It's no news that I'm not the sharpest pencil in the box, nonetheless I'm sensing a kind of a lightweight attack on him and his service. All cleverly disguised with technical arguments and sprinkled with a handful of accusations.

If this guy, a well respected security guru is right on the issues he addresses, and I have no reason to believe otherwise, he would do better reaching out to Ladar & Co. and offering his expertise, if in the end, he's altruistic enough to side with us the internet peasants and tech ignoramus.

Or at the very least his counsel, pro bono or not. Of course he is in no obligation to do so, but maybe he should have finished this article NOT ONLY by pointing to other promising alternatives, but also extending his much needed helping hand and wits.

Anyway, just my thoughts, now you can rape my ass with negative votes. Peace out.

I was going to upvote you, but -1 for complaining about downvotes and another -1 for unnecessary vulgarity, so I had to downvote you instead.

I think the fundamental problem in all of the "security" schemes is the use of SSL certificates signed by CAs. Every three-letter agency possesses 'authentic' root certificates signed by the CAs themselves. We need an asymmetric encryption method for webmail that doesn't rely on central CAs.

"Despite what anyone tells you, end to end encrypted e-mail is not possible in a webmail world."

Sure it is. Anything a stand-alone client can do, a browser can do....

Exactly. The author either doesn't understand that you can implement stuff client side (Javascript for example) or he is making the leap that because doing so could potentially be too slow (in execution cycles) to be usable equates to "not possible"

If you start doing the decryption with javascript, then there are a number of issues that make it impractical and not totally secure. The question of where the private key is stored still exists. For practical and usability reasons, it's most convenient for the service to maintain the keys on their servers. It's possible that those keys can be password protected to provide limited protection against snooping, but users are notoriously bad at picking good passwords. Alternatively, you have to find some way to let the user store the private key themselves, leaving them wholly responsible for keeping it secure and backed up.

But assuming you have a workable solution for private key storage, you also need a way for the browser to perform the decryption of the email content, which is separate from normal decryption performed as part of the SSL/TLS connection. If, as you suggest, this is done by some JavaScript in the page. Then that exposes a huge security hole.

If you give the JavaScript access to the key and the user's password for decrypting the key, then it is also possible for that script to send a copy of the password and/or decrypted key back to the server. You have to have a certain level of trust in the service provider that they won't do this. But, that is exactly what HushMail did, and they were forced to snoop the credentials of some specific users in order to turn over unencrypted emails to the authorities.

It's also, unfortunately, the approach taken by services like LastPass when you log in via the website, rather than the extention, or use their security check tool. Users have to trust that LastPass is never going to send any javascript for the purpose of stealing their credentials. But they could certainly do so if they were ordered to. They could theoretically even direct this malicious version of the script to a specific IP address or user account, so no-one else could possibly notice it.

But, let's assume you've solved the key storage problem and you have enough trust in the service provider to believe their scripts that they are sending you are not malicious, the next problem is that by having all mail encrypted, you basically lose all ability to search your email. You're limited exclusively to client side searching, and performing that in the browser is completely infeasible. You would have to download all encrypted mail from the server, decrypted it, index it and search it all with javascript, which runs in a single process in a web browser. Good luck solving performance issues with that.

The only way to solve this problem would be to run your own trusted private server with which you can entrust your private key, so that it can store, index and search all your mail for you, where you would have to be running your own private instance of a "webmail" service. But for all intents and purposes, doing that is, from the perspective of your email service provider, functionally equivalent to you running a standard IMAP client and receiving PGP encrypted mail.

I think the fundamental problem in all of the "security" schemes is the use of SSL certificates signed by CAs. Every three-letter agency possesses 'authentic' root certificates signed by the CAs themselves. We need an asymmetric encryption method for webmail that doesn't rely on central CAs.

You're on the right track, but not quite there...

The fundamental problem is that the legal system is being used to exploit 3rd party relationships. Eliminate the 3rd party, employ existing crypto tools (SSL, SSH, TLS, etc...) and the privacy problem mostly goes away. You can't stop the government from asking for the info and being compelled to provide it but you won't be unaware of the request.

There are open source solutions that provide many / most of the common services you can pay 3rd parties for (contacts, calendaring, email, file storage, etc...). They don't always integrate with every device quite as nicely as some commercial offerings but they do get the job done.

What a scam!But the similar analysis could have been done since the beginning . Too much biased advocacy journalism and lack of serious critique everywhere

Reading between the lines, I think you just nailed it. Right on the center.

I will be expecting the professional thing to do now, that would be to reach out to Ladar Levison, offering his right to response and posting it ASAP if he so desires.

It's no news that I'm not the sharpest pencil in the box, nonetheless I'm sensing a kind of a lightweight attack on him and his service. All cleverly disguised with technical arguments and sprinkled with a handful of accusations.

If this guy, a well respected security guru is right on the issues he addresses, and I have no reason to believe otherwise, he would do better reaching out to Ladar & Co. and offering his expertise, if in the end, he's altruistic enough to side with us the internet peasants and tech ignoramus.

Or at the very least his counsel, pro bono or not. Of course he is in no obligation to do so, but maybe he should have finished this article NOT ONLY by pointing to other promising alternatives, but also extending his much needed helping hand and wits.

Anyway, just my thoughts, now you can rape my ass with negative votes. Peace out.

I was going to upvote you, but -1 for complaining about downvotes and another -1 for unnecessary vulgarity, so I had to downvote you instead.

Read again my friend, I explicitly said "you are more than welcome to down-vote."

Simple, because one can be somewhat trained in decent narrative and clever use of rhetoric, enough to convince the fast reader or those more clever but in a hurry. But still, one could be fundamentally full of Sh#!t (last word scrambled so no sensibility is hurt)

After all, down votes don't add that much to an otherwise enriching conversation. In the end, we all want the internet to be a better place, don't we? I know I do...

Instead, I would have appreciated pro or counter arguments to mine. And that indeed backs up a down (or up) vote.

But, let's assume you've solved the key storage problem and you have enough trust in the service provider to believe their scripts that they are sending you are not malicious, the next problem is that by having all mail encrypted, you basically lose all ability to search your email. You're limited exclusively to client side searching, and performing that in the browser is completely infeasible. You would have to download all encrypted mail from the server, decrypted it, index it and search it all with javascript, which runs in a single process in a web browser. Good luck solving performance issues with that....

I know nothing about building a search index so help me along. Can your client build the index piecemeal as it reads each email then updates that index on the server? That index file could be stored with asymmetric encryption so it's not at risk at rest.

So it's not just the providers making snake-oil claims - something we strive very hard to avoid and that practice does cost us the occasional user - it's that people reward that kind of behaviour even when they are being shown claims do not add up.

I guess the only thing we can really do is continue to work on providing real security to the extent we can, and otherwise focus on making it more usable because people could be a whole lot more secure already if the technologies that exist were being used.