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

31–40 of 58 posts

Re: LavaBit's Architecture (2009)

#31

Post by old-gregg »

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…

The tech required for a truly safe email lives on a client, not a server: http://en.wikipedia.org/wiki/S/MIME

Re: LavaBit's Architecture (2009)

#32

Post by wfn »

bradleyjg wrote: post #28
wfn wrote: post #26

Earlier quoted context omitted.

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

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

agree & agree. Overall, the email protocol is fucked either way. :) As of now, I'm looking into, e.g. Pond [1]. Of course convincing people to just go ahead and move to something else is kind of quixotic / sisyphean; though it might be possible for a small circle of acquaintances where encryption is actually critical.

[1]: https://pond.imperialviolet.org/

Re: LavaBit's Architecture (2009)

#33

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

Re: LavaBit's Architecture (2009)

#34

Post by pktgen »

santry wrote: post #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.

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.

Re: LavaBit's Architecture (2009)

#35

Post by sorbits »

old-gregg wrote: post #31
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…

The tech required for a truly safe email lives on a client, not a server: http://en.wikipedia.org/wiki/S/MIME

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.

Re: LavaBit's Architecture (2009)

#36

Post by VikingCoder »

zokier wrote: post #12
walden42 wrote: post #10

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

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

Meaning, in practice they're centralized.

Re: LavaBit's Architecture (2009)

#37

Post by jonknee »

santry wrote: post #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.

Lavabit also flipped the bit and destroyed everyone's emails (without much complaint, at least that I have read). The goal was security, not availability. If security is the goal it's better to fail hard than fail [possibly] insecurely. POP/IMAP email also backs up itself--you retain a copy on your own machine.

Re: LavaBit's Architecture (2009)

#39

Post by old-gregg »

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

Earlier quoted context omitted.

The tech required for a truly safe email lives on a client, not a server: http://en.wikipedia.org/wiki/S/MIME

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

Re: LavaBit's Architecture (2009)

#40

Post by Tloewald »

tptacek wrote: post #15
Tloewald wrote: post #11

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.

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.

I don't think you've addressed my point. I don't hand my private key to anyone, including the service operator, so there's nothing they can cough up to make anything happen.

If you go back to the original backpack encryption model -- I leave my padlocks out in public and tell people to send me messages at some dropoff spot (alt.wesley.crusher.die.die.die for example) and collect my encrypted (padlocked) messages whenever I see fit, which I then unlock with the key I have never given out.

This could obviously be dressed up like email if necessary. E.g. set up a mail server that bounces all unencrypted incoming messages to me with a "try again using this public key".

Yes, the authorities can track my attempts to access the server (but guess what, they already can). And because my inbox requires no password to access they can't tell me from any random person or bot trying to access my mail.

The authorities (and anyone else) can also deluge me with encrypted spam (including spam I can't decrypt :-)). It's not perfect.

Post reply on HN