LavaBit's Architecture (2009)
possibility.com
LavaBit's Architecture (2009)
1–10 of 58 posts
Re: LavaBit's Architecture (2009)
#2That might be the best article/review I've ever read.
Re: LavaBit's Architecture (2009)
#3Just 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.
Re: LavaBit's Architecture (2009)
#4Just 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…
It's very interesting. Something like this is really required. How ever, if this is a private project then people may not have absolute trust on it. If it is open source, independent verification is possible which will improve user trust. Also when malicious unnamed agents come after you through legal channels, you can drop the service like lavabit but some one else can setup an independent server and do a direct import of user data from your servers with user permission.
Re: LavaBit's Architecture (2009)
#5Just 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…
It's very interesting. Something like this is really required. How ever, if this is a private project then people may not have absolute trust on it. If it is open source, independent verification is possible which will improve user trust. Also when malicious unnamed agents come after you through legal channels, you can drop the service like lavabit but some one else can setup an independent server and do a direct imp…
My plan was to keep it open source, and have free accounts, as far as possible. The monetization could have come from extra storage, like GMail, or custom domains.
Re: LavaBit's Architecture (2009)
#6Just 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 only" mounts by supplying it directly with the derived public key for the passphrase instead of the passphrase itself. This would allow you to use vanilla components such as postfix & dovecot instead of having to write a custom application server.
Using the maildir format, incoming mails could be written to the write-only mount without having to read any files from the mount. On IMAP login, the mail daemon would use a passphrase derived from the login password to mount the maildir as read-write, using unshare to ensure that the mount is visible to that process alone, and automatically unmounting it when the IMAP user logs out.
Thoughts and ideas are welcome :)
Re: LavaBit's Architecture (2009)
#7Earlier quoted context omitted.
It's very interesting. Something like this is really required. How ever, if this is a private project then people may not have absolute trust on it. If it is open source, independent verification is possible which will improve user trust. Also when malicious unnamed agents come after you through legal channels, you can drop the service like lavabit but some one else can setup an independent server and do a direct imp…
My plan was to keep it open source, and have free accounts, as far as possible. The monetization could have come from extra storage, like GMail, or custom domains.
Every time I see the phrase "open source", I mentally add "but not open binary"; how do I know that the service that is run uses binaries that are compiled from that open source alone? with trusted libraries? After all, anyone can employ a site-specific patch in their build process that adds additional "features" to their normally open source project.
Is there a reasonable way to have trusted individuals intermittently audit the service?
Re: LavaBit's Architecture (2009)
#8Just 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…
If you don't care about metadata then imho the approach presented in a blog post[1] linked in your firespotting thread is most reasonable. Most importantly the private key never touches the mail-server.
If you do care about metadata then you could do some lavabitesque tricks in addition to encrypting the message bodies.
[1] https://grepular.com/Automatically_Encrypting_all_Incoming_E...
Re: LavaBit's Architecture (2009)
#9Just 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 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.
Re: LavaBit's Architecture (2009)
#10I 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 around security and privacy in the first place.