Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LavaBit's Architecture (2009)

possibility.com

Post reply on HN
Print view View original

21–30 of 58 posts

Re: LavaBit's Architecture (2009)

#21

Post by muyuu »

Xurinos wrote: post #7
captn3m0 wrote: post #5

Earlier quoted context omitted.

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 intermittent…

A no-trust-required system would consist of taking these sources and hosting your mail yourself. Which pretty much defeats the purpose, since what you want to avoid is hosting your own email (another alternative).

Honestly I lend more towards phasing out email completely. Maybe providing gateways to other protocols.

Re: LavaBit's Architecture (2009)

#22

Post by umsm »

captn3m0 wrote: post #3

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…

You could always make it open-source and allow users to "download" and "upload" their mailbox. This way, when one service provider is shutdown, you can find a host and install the email system and upload your mailbox.

I had a similar idea, but I have no time to execute it.

Re: LavaBit's Architecture (2009)

#23

Post by pilif »

cypherpunks01 wrote: post #17
pilif wrote: post #9

Earlier quoted context omitted.

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?

Could very well be. You can try and check all Received:-Headers, but there's no obligation that the MTA actually has to write whether TLS was used, nor can you be sure that the MTAs aren't simply adding some TLS string without actually having used TLS. Of the big email providers, only Gmail supports TLS.

Re: LavaBit's Architecture (2009)

#24

Post by bradleyjg »

wfn wrote: post #16
vader1 wrote: post #6

Earlier quoted context omitted.

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 the…

If you have to customize the client anyway, you might as well encrypt the metadata. It looks like you can use an unmodified IMAP server -- your MTA would encrypt each mail part individually and your mail client would decrypt.

The sticking point is server side search, which is available in IMAP4. You'd either have to skip that, or implement one of the search over encrypted data algorithms (which are rather slow).

Re: LavaBit's Architecture (2009)

#25

Post by toddh »

tehwalrus wrote: post #13
chayesfss wrote: post #2

That 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.

Ladar was kind enough to answer the questions in an architecture template I have for High Scalability (http://highscalability.com/architecture-template-advice-need...). 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.

Re: LavaBit's Architecture (2009)

#26

Post by wfn »

bradleyjg wrote: post #24
wfn wrote: post #16

Earlier quoted context omitted.

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 the…

If you have to customize the client anyway, you might as well encrypt the metadata. It looks like you can use an unmodified IMAP server -- your MTA would encrypt each mail part individually and your mail client would decrypt. The sticking point is server side search, which is available in IMAP4. You'd either have to skip that, or implement one of the search over encrypted data algorithms (which are rather slow).

> If you have to customize the client anyway, you might as well encrypt the metadata.

Yes, but then you'd need a custom extension, whereas the proposed setup would be covered by, e.g., Enigmail for Thunderbird. Depends on the userbase / use case - if one were to set up such a system for themselves, then yes, this would be nice.

> It looks like you can use an unmodified IMAP server -- your MTA would encrypt each mail part individually and your mail client would decrypt.

Yes, that's the plan :) No need to modify the mail server itself.

> The sticking point is server side search, which is available in IMAP4. You'd either have to skip that, or implement one of the search over encrypted data algorithms (which are rather slow).

That is true, and this would indeed involve writing custom code/extensions. Normally, email subjects are not encrypted / presumed 'public' (in a sense), so one way to do it would be to simply allow searching for email subject lines, which would not be stored encrypted on the server. Not sure how much customization server-side this would require.

edit another way to look at it would be, it shouldn't be possible to do any kind of search on the server. The client (which would presumably actually store all the mail archives (e.g. in an encrypted container which could be hooked up to a simple automatic offsite backup solution)) would do all the search. Again, however, depending on the setup, this might require some customization.

Re: LavaBit's Architecture (2009)

#27

Post by tptacek »

conductor wrote: post #18
tptacek wrote: post #15

Earlier quoted context omitted.

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)…

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.

Re: LavaBit's Architecture (2009)

#28

Post by bradleyjg »

wfn wrote: post #26
bradleyjg wrote: post #24

Earlier quoted context omitted.

If you have to customize the client anyway, you might as well encrypt the metadata. It looks like you can use an unmodified IMAP server -- your MTA would encrypt each mail part individually and your mail client would decrypt. The sticking point is server side search, which is available in IMAP4. You'd either have to skip that, or implement one of the search over encrypted data algorithms (which are rather slow).

> If you have to customize the client anyway, you might as well encrypt the metadata. Yes, but then you'd need a custom extension, whereas the proposed setup would be covered by, e.g., Enigmail for Thunderbird. Depends on the userbase / use case - if one were to set up such a system for themselves, then yes, this would be nice. > It looks like you can use an unmodified IMAP server -- your MTA would encrypt each mail…

Well I guess it comes down to how important you think the metadata is. In reponse to your edit, if you are storing everything client side than POP works and is considerably simpler. Heck you could even just do local delivery.

The idea for IMAP with encrypted mail parts would be to allow multiple clients to access a remote mail store where the remote mail store could not read any of the stored email or its metadata even if it wanted to.

You'd also want your MTA to reject mail not sent over TLS. No matter what you do though if the remote server is compromised -- technically or legally -- your future emails are subject to capture.

Re: LavaBit's Architecture (2009)

#29

Post by tehwalrus »

toddh wrote: post #25
tehwalrus wrote: post #13

Earlier quoted context omitted.

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.

Ladar was kind enough to answer the questions in an architecture template I have for High Scalability ( http://highscalability.com/architecture-template-advice-need... ). 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.

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

Re: LavaBit's Architecture (2009)

#30

Post by bradleyjg »

conductor wrote: post #18
tptacek wrote: post #15

Earlier quoted context omitted.

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)…

The client would have to be open source in order for that to work. Otherwise they can just force the provider to put a backdoor in the client code.

Probably open source with no downloadable binaries would be best. Maybe even better would be something like only pulling off a source control system so there's an easily accessible audit trail. The idea being not necessarily to prevent an evil adversary, but to convince a judge that there's no way to convincingly be an evil adversary.

Post reply on HN