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.
LavaBit's Architecture (2009)
11–20 of 58 posts
Re: LavaBit's Architecture (2009)
#12I 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 ) 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…
> 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.
Re: LavaBit's Architecture (2009)
#13That might be the best article/review I've ever read.
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.
Re: LavaBit's Architecture (2009)
#14> * 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.
Re: LavaBit's Architecture (2009)
#15I 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.
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.
Re: LavaBit's Architecture (2009)
#16Just 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…
For a couple of weeks now, I've been brainstorming about how to create a system like this. I'd very much like to use this sort of setup for my own emails, but it simply doesn't seem to exist, especially not as open source (while lavabit claimed to store your emails encrypted, there was no way for anyone to actually vet their approach). The most viable option I came up with so far is modding eCryptfs to allow "write o…
Nice plan. I've also been brainstorming ideas - I'm now considering setting up something similar (though I have less knowledge in these matters):
* encrypt all incoming mail to a public key associated with the recipient's email address (new account creation would have to involve uploading a public key; on the other hand, if we are only talking about one user, then it becomes much simpler)
* this can be done while there is nothing written to disk (via exim, etc.)
* either write the resulting encrypted email to disk, or keep it in memory (depending on paranoia level)
* ideally, check incoming email if it already has a PGP header; if it does, do not encrypt on top of that (this would confuse certain mail clients)
* user logs in via IMAP, downloads new mail, mail client can be set up to transparently decrypt mail. User is encouraged to then delete mail from the server
This wouldn't be user friendly in the traditional sense, but my initial goal presumes that compromises involving friendliness vs end to end encryption suck, so screw it. I'd like to set up something like that for personal + friends' use.
Your idea of passphrase ~== private key is very nice. Mine is more ugly in the usability sense (at least for the median user), but at least at no point in the process does the server have to do anything with the private key. Still, of course, it would be possible to wiretap the whole thing at the "process incoming mail and encrypt it" point..
Re: LavaBit's Architecture (2009)
#17Just 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…
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 communi…
Is it really true that most MTAs don't implement it?
Looking through a bunch of random emails of mine (on gmail), I see version=TLSv1 somewhere in the headers, which I thought indicated that STARTTLS was being used. Am I wrong about this? Or is there some intermediate MTA that might not be using TLS in this case?
Re: LavaBit's Architecture (2009)
#18I 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.
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.
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).
Re: LavaBit's Architecture (2009)
#19Just 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…
For a couple of weeks now, I've been brainstorming about how to create a system like this. I'd very much like to use this sort of setup for my own emails, but it simply doesn't seem to exist, especially not as open source (while lavabit claimed to store your emails encrypted, there was no way for anyone to actually vet their approach). The most viable option I came up with so far is modding eCryptfs to allow "write o…
if you're doing this on your own hardware, why not just encrypt your entire disk? (or just a single partition, and give imap access to that alone through unix perms or, if you want to go further, apparmor etc).
Re: LavaBit's Architecture (2009)
#20Old article, circa March 2009! Look at the monthly visits mentioned, and also this highscalability article- http://highscalability.com/blog/2009/3/30/lavabit-architectu...
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?