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

51–58 of 58 posts

Re: LavaBit's Architecture (2009)

#51

Post by wfn »

wildgift wrote: post #50
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…

That's funny. I was thinking of exactly the same thing. Another thing to do is limit how much email is kept, so old mail is automatically purged.

I suspect lots of people are considering these kinds of designs these days. :) There's been some discussion on various mailing lists, usually assinine, but once in a while clever folk join in.

> Another thing to do is limit how much email is kept, so old mail is automatically purged.

Makes sense.

I'm also not sure how easy it would be to provide an option for the user to choose, for example, whether to accept incoming mail over a plaintext channel. SMTP TLS handshake takes place immediately after the initial "hello". Ideally there could be two servers listening (the user would have to decide which server to use, each of which would imply a different email suffix), one with a forced TLS mode, and each user could choose which mode to use. Maybe I'm overthinking things over a problem that is unsolvable in the framework of the email protocol (which does suck in this regard).

Re: LavaBit's Architecture (2009)

#52

Post by lstepniewski »

wildgift wrote: post #49
sorbits wrote: post #35

Earlier quoted context omitted.

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.

Here's an idea: public mail pools. The entire email message is encrypted and randomly routed to one of many addresses. Each customer downloads all the messages from all the addresses in the pool. You try to decrypt each message, and the ones that decrypt are (obviously) yours. The rest belong to someone else. To make life tougher on spies, add fake email messages to the pool regularly.

That's exactly how BT Sync (http://labs.bittorrent.com/experiments/sync.html) works, but for data.

Re: LavaBit's Architecture (2009)

#53

Post by vader1 »

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…

I also considered the approach of transparently encrypting all incoming mail with the user's public key, but it has a couple of downsides, mainly:

* This only works if all of a user's clients support GPG. I'm looking for a solution that would work for any average Joe (on his desktop, phone and tablet) rather than a solution geared towards technical people.

* This process only encrypts the email's body, and not the metadata (from, to, subject, headers containing IP addresses, etc). As a bunch of people have shown after the PRISM fallout, analysis on metadata alone can reveal an incredible amount of private information.

* It would be impossible to support features such as server-side search, effectively making email search on your mobile devices impossible.

Of course any solution to this problem will be a compromise between security and usability, so let's hope a number of different solutions will see the light of day, so that everyone can choose the solution that works the best for them.

Re: LavaBit's Architecture (2009)

#54

Post by vader1 »

andrewcooke wrote: post #19
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…

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

Firstly because I'm looking to create a solution that can be hosted centrally: the average email user is simply never going to setup and host their own mailserver and setup the encryption.

Secondly: simply using a regular encrypted partition for both SMTP and IMAP access means that partition has to be mounted permanently, otherwise new incoming mails couldn't be delivered. This means if a hacker were to gain access to the system, or if a party would force the server operators to give them access to the servers, all emails would be instantly compromised.

Re: LavaBit's Architecture (2009)

#55

Post by wfn »

vader1 wrote: post #53
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…

I also considered the approach of transparently encrypting all incoming mail with the user's public key, but it has a couple of downsides, mainly: * This only works if all of a user's clients support GPG. I'm looking for a solution that would work for any average Joe (on his desktop, phone and tablet) rather than a solution geared towards technical people. * This process only encrypts the email's body, and not the me…

Nice, yes, thanks the reply, agree with everything.

> This process only encrypts the email's body, and not the metadata (from, to, subject, headers containing IP addresses, etc). As a bunch of people have shown after the PRISM fallout, analysis on metadata alone can reveal an incredible amount of private information.

I also had the idea to have encrypted containers something akin to what you are proposing, with PGP for the body underneath. It gets complicated..

Anyway,

> Of course any solution to this problem will be a compromise between security and usability, so let's hope a number of different solutions will see the light of day, so that everyone can choose the solution that works the best for them.

I very much agree. Here's to hoping to see multiple solutions soon :)

Re: LavaBit's Architecture (2009)

#56

Post by vader1 »

pilif wrote: post #9
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…

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…

Of course a system such as this will not provide you with foolproof protection against any adversary ever. If that is what you need, email is not what you're looking for, period.

But there is in fact an enormous difference between the proposed system and traditional email hosting. With traditional email hosting, all it takes is one FISA rubber stamp, one hacker gaining access to the mailserver or any of its backups, one rogue or compromised employee to access the entire history of every email you have ever received or sent.

In the proposed system, assuming it is properly implemented, the only way to snoop on your emails is tapping the line between the local and remote SMTP server, easily prevented if both parties use SSL. The system could even, based on the user preferences, warn about this ("Warning: this email was not delivered via SSL, it could thus have been intercepted while on the wire") or block incoming/outgoing SMTP entirely if the remote party doesn't support SSL.

It's not a solution against (government) snooping per se, especially not a solution against a party such as the US government specifically targetting you. But it is a defense against half of the world population's email history indefinitely being stored in your friendly neighborhood NSA facility.

Re: LavaBit's Architecture (2009)

#57

Post by VikingCoder »

zokier wrote: post #42
VikingCoder wrote: post #36

Earlier quoted context omitted.

In theory, sure - but in practice... Most of my friends are @yahoo.com, @gmail.com, or their ISP. Meaning, in practice they're centralized.

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…

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.

Re: LavaBit's Architecture (2009)

#58

Post by sorbits »

old-gregg wrote: post #39
sorbits wrote: post #35

Earlier quoted context omitted.

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.

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

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

Post reply on HN