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

41–50 of 58 posts

Re: LavaBit's Architecture (2009)

#41

Post by jedbrown »

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

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

That is not how the POP or IMAP protocols work. To make the system work with existing clients, the server needs to have the plain text when it is sending to the client. Surely this is also how they complied with valid warrants (wait until user logs in, then execute warrant).

Asymmetric encryption on the server means that an intruder can't read the content (except possibly for those accounts where the private key passphrase is still in memory) and nobody can search old mails until a user logs back in.

Re: LavaBit's Architecture (2009)

#42

Post by zokier »

VikingCoder wrote: post #36
zokier wrote: post #12

Earlier quoted context omitted.

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

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 federation does work.

Currently the major pain point in the architecture of email arises when people bind their online identities to singular email providers, even when email has nice facilities of not doing so by having a domain independent from the mail provider and setting appropriate MX records.

Re: LavaBit's Architecture (2009)

#43

Post by Tloewald »

jedbrown wrote: post #41
Tloewald wrote: post #40

Earlier quoted context omitted.

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

That is not how the POP or IMAP protocols work. To make the system work with existing clients, the server needs to have the plain text when it is sending to the client. Surely this is also how they complied with valid warrants (wait until user logs in, then execute warrant). Asymmetric encryption on the server means that an intruder can't read the content (except possibly for those accounts where the private key pass…

Um huh? What the heck are you talking about? Imap and pop can't tell if the body text of a message is plaintext or not beyond poop left by encoding /encrypting engines. Certainly my proposed system would allow plaintext messages disguised as encrypted messages to be sent to the end user, but so what?

I am not talking about how lavabit worked, I am asking why not design a system where the service provider need hold no private keys and thus have no way to comply with requests for keys. Yes, they can help the government track users and they can try to install malware on your machine, but fundamentally they don't know whether you're reading your email on a mac, pc, raspberry pie, or microwave oven.

Here's a pgp encrypted message. What can't I send by conventional email? (Or simply post on usenet, as my earlier post.) "They" can try to track every person who inadvertently downloads messages left for me.

-----BEGIN PGP MESSAGE----- Version: BCPG C# v1.6.1.0

hQEMAz/dtuqQ9lvGAQf/Rqb+/hNYGhdTli66144SlhBIDineb9uY0tc7p5kDOEm1 DmwqoQNoyX8LshRe1YlpCIiS7nW6Mmzhs86U65yA2/W4Rfs0gsfBx8R//01bBr54 qgRAMsoW426hIVc16XjlIVy+o7/FrynHkY3Vf0E7Ft7qbHL2OcKjIMxDtl0mK2dj W2c5/rvTiZeq6j1iKTn22DaD94PFjHVcE7H4IRGRKRnp5TxgZq0OAzGD00aSqWMM 4xZdiqFNr7J9o9Akoz8qYotSBjLXFoep+pDyD8EU9I6oA4Eqea3Ka2YXQ9m6/QwS 9VS6cPYccfqjms4X0V/E+fWRnkpyXomVETSamar2IMktO4BiRY6/qCjhpUywcag8 bJ+rOFrwVsSS+xy3XpXvRtlYRPGk8dA/BYH4b3Wz =D8kd

-----END PGP MESSAGE-----

Re: LavaBit's Architecture (2009)

#45

Post by andrewcooke »

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

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

the "persistent component that doesn't automatically update itself" that tptacek was talking about is the software used to generate keys, do encryption etc.

the safe alternative is that each user has to go find and install reliable third party software themselves. this is already possible with gpg et al and it is not used.

so instead someone needs to package the crypto code. and as soon as you do that, if there's any kind of update process, the code package can be forced (apparently) to modify the code to leak information.

so sure, you can do this securely. it's already possible, but it's not popular. and anything easy enough to be popular appears unreliable.

Re: LavaBit's Architecture (2009)

#46

Post by e12e »

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

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…

I still think one of the sanest ways to do this is to set up a filter that takes an email message on standard input, and outputs the same message to a Maildir/mbox[1], with the body encrypted with the recipients public key (possibly signed by a server key, but that wouldn't add all that much in terms of security, as the server key would have to be always available).

1: Probably one filter that takes an email on standard input, and writes an encrypted "copy" on standard output, and another program that takes a message on standard input and delivers it to a Maildir/mbox:

    #.forward pseudocode:
    | gpg-encrypt-to-self | deliver
Optionally check if the mail is already encrypted:

    if is-gpg-message
    then
      deliver
    else
      encrypt-to-self|deliver
    fi

Re: LavaBit's Architecture (2009)

#48

Post by wildgift »

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…

What about 1) requiring STARTTLS, 2) encrypting incoming mail that isn't already encrypted, using the customer's public key. The message then cannot be decrypted by anyone but the customer. (The customer experience is that all the messages they download are encrypted.)

Re: LavaBit's Architecture (2009)

#49

Post by wildgift »

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.

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.

Re: LavaBit's Architecture (2009)

#50

Post by wildgift »

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…

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.
Post reply on HN