Remember Lavabit, the “secure email” service that was closed down by its owner Ladar Levison, ostensibly to avoid complying with a government request to access their “secure emails?” Specifically, emails from one of their most famous clients, Edward Snowden?

Something that always bothered me about the story: Lavabit claimed on their home page (see screenshot above) that their system was designed so that even their administrators couldn’t read users’ emails. I assumed this meant they were using some kind of public/private key scheme to encrypt emails, so that they would be encrypted while on Lavabit’s servers in a form that could not be decrypted even by Lavabit.

So how then could the government read those emails without the private keys of each user? Well, it turns out that Lavabit’s claim they couldn’t read emails simply wasn’t true. Their basic design was not secure at all, as cryptographer Moxie Marlinspike explains: Op-Ed: Lavabit’s Primary Security Claim Wasn’t Actually True.

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:

1. At account creation time, the user selected a login passphrase and transmitted it to the server.
2. 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.
3. 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.
4. 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.

So the claim on Lavabit’s home page that they couldn’t read stored emails was simply false. The promise of security they made to their users was a lie. They promised not to read the emails, but breaking that promise would have been trivially easy with the way their system was built — and that’s why the feds wanted access.

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.

Yep. And it raises the issue of whether Lavabit’s owner is telling the truth about the real reasons for shutting down his business, as well.