

LavaBit's Architecture (2009) - yankcrime
http://possibility.com/LavabitArchitecture.html

======
captn3m0
Just after the PRISM scandal exploded, I came up with the idea of encrypted-
storage based email [1]. Unfortunately, within a little while of thinking of
this, I read about lavabit and realized that they had the exact same security
model that I was thinking of.

Now that lavabit's gone, I think there is a good opportunity for someone in a
sane country with good data-protection laws.

[1]:
[http://firespotting.com/item?id=1632](http://firespotting.com/item?id=1632)

~~~
pilif
Considering that STARTTLS is still optional and most MTAs don't implement it,
what value is there behind storing the mail encrypted? Because governments are
storing every email anyways, when they want to get to my data, why would they
bother asking you to decrypt it for them (which you can't) instead of just
looking at the SMTP communication between $OTHERSERVER and you.

With a very high likelyhood, that SMTP communication is unencrypted.

Of course $EVILGUY might have encrypted their message before sending it, but
then you can't help the government anyways.

IMHO, as it stands currently, encrypted mail storage provides a false sense of
security.

~~~
old-gregg
The tech required for a truly safe email lives on a client, not a server:
[http://en.wikipedia.org/wiki/S/MIME](http://en.wikipedia.org/wiki/S/MIME)

~~~
sorbits
The problem is that only the body is encrypted. Who you are communicating with
(and in term, who they are communicating with) is at least as sensitive as
what you are writing.

~~~
old-gregg
But that's a different problem though, it exists outside of email. The meaning
of "who you are" changes depending on how high/low you're on the OSI stack:
sometimes it's 00:C0:C1:A4:C8:29 or 60.56.228.48 and sometimes it's
anon2342foobar@yahoo.com

If they're wiretapping everything, there's no way for you to hide the fact of
a communication taking place, but at least you can protect the data itself
using client-side encryption.

~~~
sorbits
> _If they 're wiretapping everything, there's no way for you to hide the fact
> of a communication taking place, but at least you can protect the data
> itself using client-side encryption_

No, you misunderstand. With S/MIME, the email headers are _not_ encrypted.
This means someone can go to your email provider, get all your emails, and
even though these are all S/MIME encrypted, build a nice graph of who you are
communicating with, how often, correlate with significant dates, see the
subject of each letter, file names of attached files, etc.

------
santry
> * How do you backup and restore your system?

> All critical servers use RAID 5.

Unfortunately RAID 5 (or any other flavor) is not a backup solution. It
doesn't account for user error, RAID controller failure and numerous other
scenarios.

It seems LavaBit had an interesting product, but this seems like a pretty
critical design failure.

~~~
pktgen
It's much harder to delete things from backups though. Lavabit promised that
when you deleted a message, it was actually deleted. Redundancy against
hardware failure but not against user error, software error, etc. was probably
part of their security-convenience tradeoff.

------
chayesfss
That might be the best article/review I've ever read.

~~~
tehwalrus
It is taken directly from the Lavabit "about us" pages* - I read them all a
few weeks ago when I signed up and paid for pro! :)

* - the pages are gone now, which is why they needed to be mirrored somewhere.

~~~
toddh
Ladar was kind enough to answer the questions in an architecture template I
have for High Scalability ([http://highscalability.com/architecture-template-
advice-need...](http://highscalability.com/architecture-template-advice-
needed)). I guess they also used it for their about page, which makes sense
given all the work that went into it. He's a very nice guy, a shame to see how
things went down.

~~~
tehwalrus
I'm still hopeful they'll all emigrate to Iceland (or somewhere) and start up
again. Slightly hopeful, anyway.

------
negativity
It would be really awesome if the LavaBit team released all their trade
secrets, including their C code for their custom daemons, and other
substantial details, as an open source project. ...that is, if there's truly
no hope, and they've shuttered the business for good, and never plan on re-
opening their doors and returning to business.

Hardware and Service Provider expenses aside, this would represent an
opportunity for many people to create their own systems and participate in a
distributed, federated network of professionally vetted, (ostensibly) secure
e-mail services, based on field tested architectural standards.

If the company is dead, why not turn lavabit.com into the homepage of a
project spawned from the ashes of the original business.

------
Tloewald
I don't understand why the service provider needs to store or provide any
keys. Let the customer generate a private and public key, store the private
key anyway he/she chooses, and then broadcast an address/public-key combo to
would-be contacts. You can communicate using a totally insecure file-sharing
service -- e.g. usenet, anonymous FTP, or mailinator.

~~~
tptacek
Unless you're shipping the customer a persistent component that doesn't
automatically update itself every time they connect to the service, you might
as well just store the keys, because (as LavaBit apparently discovered) if a
court decides you need to cough up your users info, they'll probably just get
you to install whatever code is needed to make that happen.

~~~
conductor
If I understand correctly, the decryption code was in the server, so the user
was providing the password for the private key, and the code from the server
was doing the encryption/decryption (by server-side or client-side execution,
I don't know). This scheme could be backdoored by altering that server-side
code. So, why not keep the code on the client-side (like signed, verified
browser add-on or native application)? Then there will be no way to get the
password of the private key from the user (except by installing a malware with
some 0-day browser vuln).

~~~
tptacek
Note that Chrome extensions can suffer from essentially the same problem,
since they can autoupdate.

The reason nobody does this, though, is that end-users don't want to install
software on their machines. Unfortunately, there is a fundamental conflict
between desire to run software off of other people's machines rather than your
own and desire for cryptographic security.

------
walden42
I believe that the LavaBit fiasco just proves the need for a decentralized
system with no central points of failure. Although it's still in the beginning
stages, bitmessage
([https://bitmessage.org/wiki/Main_Page](https://bitmessage.org/wiki/Main_Page))
offers a solution similar to the bitcoin protocol.

I would more people to start using solutions such as these instead of email.
Although email has served its purposed for a long time, it was never designed
around security and privacy in the first place.

~~~
zokier
> I believe that the LavaBit fiasco just proves the need for a decentralized
> system with no central points of failure

That's probably the only thing e-mail actually does really well.
Centralization is definitely not the problem with email. Lack of end-to-end
encryption and meta-data leakage are the real problems.

~~~
VikingCoder
In theory, sure - but in practice... Most of my friends are @yahoo.com,
@gmail.com, or their ISP.

Meaning, in practice they're centralized.

~~~
zokier
From a technical point of view, they are not centralized. Gmail is a massively
decentralized system in itself, a feature partially enabled by emails
flexibility. Even if gmail would go down, (other) emails would still continue
flowing. And when gmail would come back online, most messages would find their
destination due the store-and-forward nature of email.

The fact that even you mention several providers shows that federation does
work.

Currently the major pain point in the architecture of email arises when people
bind their online identities to singular email providers, even when email has
nice facilities of not doing so by having a domain independent from the mail
provider and setting appropriate MX records.

~~~
VikingCoder
From a legal perspective, GMail is operated by one corporation which can have
a single warrant issued, and be forced to reveal all of your emails, no matter
how many servers your account resides upon.

Even if you do end-to-end encryption, they're still going to see who you're
sending email to.

With a more decentralized system that for instance does onion routing it might
be possible to radically improve privacy.

------
yarapavan
Old article, circa March 2009! Look at the monthly visits mentioned, and also
this highscalability article-
[http://highscalability.com/blog/2009/3/30/lavabit-
architectu...](http://highscalability.com/blog/2009/3/30/lavabit-architecture-
creating-a-scalable-email-service.html)

I wonder how much of this architecture still exits and how much has changed!

Do they still host servers, use CentOS+Apache+MySQL+Memcache or was there an
architectural change with more apt software components?

------
wildgift
I'm guessing that the government wants Lavabit's private keys. Maybe they
already sniffed the traffic and now need keys to decrypt it. What do you all
think?

------
caycep
actually, I'm wondering if something like this could fit the bill for a HIPAA
compliant medical communication system?

------
wenming
ok?

