At the heart of the argument is a tough question: How much security, and of what kind, should be expected from a company that provides "secure" email -- or, for that matter, "secure" anything? Especially when email is so inherently hard to secure?
Lavabit: Insecure by design?
Moxie's critique revolves around the exact mechanics of the way emails were encrypted, stored, and retrieved by the user. What bothered him was the lack of verifiability in the system and how the system wasn't designed to really uphold the standards of privacy and security it touted.
"The ciphertext, key, and password," Marlinspike wrote, "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, and whether it was or not makes little difference. ... Even though they advertised that they 'can't' read your email, what they meant was that they would choose not to."
Marlinspike also took exception to the way the password supplied by the user also does double duty as an encryption key, a practice frowned upon by password researchers. TrueCrypt, the disk-encryption system that's currently the subject of a crowdfunded independent security audit, uses passwords to generate and secure an encryption key, which is in turn used to decode data. (The password itself isn't a key.)
Because of these issues, Marlinspike couldn't recommend contributing to a crowdfunded effort to open-source Lavabit's system, one spearheaded by Levinson himself.
The definition of "secure"
Levinson also took exception to the way Marlinspike had characterized Lavabit's services. In his op-ed, Levinson pointed out: "Marlinspike is assuming that the Lavabit system was designed to be a substitute for the security provided by end-to-end encryption systems like PGP. It was not. Lavabit's encrypted storage feature was designed solely to protect e-mails at rest."
But the real issue isn't whether Marlinspike assumed such things. It's whether Lavabit's users — previous, current, and future — would have made those assumptions.
Levinson points out that Lavabit described in its own documentation how it only secured email at rest and how the end-user was responsible for providing his or her own transport security.
That by itself may not have been enough. End-users need and expect security to be deployed in a package that has as few moving parts as possible. Sadly, the current state of email doesn't permit end-to-end security without a huge hassle, so Levinson might well have been forced to choose between an easier but less secure implementation or a more secure but increasingly complex one.
Sign up for CIO Asia eNewsletters.