4 ms·

Here's how Lavaboom works. I hope this will alleviate your worries about emails being sent as plaintext (for PGP users). 1. alice@lavaboom.com sends an email t

by simi_ 11y ago

Here's how Lavaboom works. I hope this will alleviate your worries about emails being sent as plaintext (for PGP users). 1. alice@lavaboom.com sends an email to bob@gmail.com Alice already has a keypair (generated automatically at registration), and Bob has one too. Alice adds Bob as a contact (or does nothing and is matched to Bob's key from a public key server), and sends him an email. The email contents + metadata is encrypted before they leave the Lavaboom email client, and are encrypted all the way to Bob. If Bob uses an email client with PGP support, then he can decrypt the email. 2. alice@lavaboom.com sends and email to zulu@lavaboom.com Same scenario as above, except that key exchange is done automatically for Lavaboom users (and emails don't leave our servers, making the process even more secure). 3. alice@lavaboom.com sends and email to carla@gmail.com Carla doesn't use PGP, so Alice's email needs to be sent as plaintext. However, before storing the email to the database, it is encrypted with Alice's key, and the plaintext version (residing in RAM) is deleted as soon as the mailer reports successful delivery. This way, only Alice has access to her data, and Lavaboom is Zero Knowledge in respect to email contents.

bradleybuda 11y ago
This is a reasonable approach, but there's a weak link in public key exchange. If Lavaboom (or any other trusted third-party) is facilitating public key exchange, there's nothing preventing them from saying "DE:AD:BE:EF" is Bob's public key when in fact it belongs to Eve the attacker. Not to say that Lavaboom would do this maliciously, but they might be compelled to do so by a state actor or law enforcement. As a rule of thumb, a messaging system S can only be zero-knowledge if you have exchanged a secret or key with someone else outside of system S. See the HN discussion on iMessage: https://news.ycombinator.com/item?id=7315964 https://news.ycombinator.com/item?id=7315964
- pzduniak 11y ago
  We plan to improve it in the nearest future. Yesterday I started work on support for message signing, the server part should be ready next week. Later we'll add support for fetching keys from external exchanges (such as pgp.mit.edu).
declan 11y ago
> Alice's email needs to be sent as plaintext Thanks for your explanation! Though in your hypothetical Carla uses Gmail, and Google supports SMTP TLS. So the email would be encrypted in transit to Google's servers. The problem, which the previous poster may be alluding to, is when a lavaboom user emails a non-PGP user with an account at an email provider that fails to support SMTP TLS. When I wrote about this for CNET two years ago, Hotmail, Yahoo, and AOL did not support it: http://www.cnet.com/news/how-web-mail-providers-leave-door-open-for-nsa-surveillance/ http://www.cnet.com/news/how-web-mail-providers-leave-door-o... Now it looks like all three of those companies do, so the question is: Which providers still fail to, two years post-Snowden disclosures?
- simi_ 11y ago
  TLS transport is nice to have, but some people can work around it. [0] That's why I only considered PGP, but you're right, SMTP TLS is important. We've also been toying with SMTorP. [1] 0: http://en.wikipedia.org/wiki/PRISM_%28surveillance_program%29 http://en.wikipedia.org/wiki/PRISM_%28surveillance_program%2... 1: https://github.com/mailpile/Mailpile/wiki/SMTorP https://github.com/mailpile/Mailpile/wiki/SMTorP
e12e 11y ago
Just pointing out that 3) isn't really a meaningful guarantee, as you can keep a copy of the session key. I'm not saying that you do, just saying that there's no way to verify either way. I don't think this detracts from your service in a meaningful way, though. Do you support clear-signing and/or choosing to send in the clear? (I'm asking mostly out of curiosity, but from a security perspective it can be important in order to be able to send deniably (eg: no, wasn't me that sent that file to a journalist -- look, it's a plain email, anyone could've sent it...)).
- pzduniak 11y ago
  All encryption is done clientside, all we see are armored PGP messages. Cleartext signing isn't supported right now, but it's in our issue tracker and I believe that it should be implemented during the next few weeks.
  - e12e 11y ago
    > All encryption is done clientside, all we see are armored PGP messages. Are you saying 3) above is wrong? Or are you saying that the client, when sending a plain-text message, first encrypts that message, and stores it on your servers, and then sends the email directly? Because that is the only way you can guarantee that you don't have a means to access a copy of the email that is sent un-encrypted. I understand that when sending encrypted emails (which I gather is your current main focus), the email is encrypted by the client before it is sent on to you. Another question: how well does this all interop with traditional email+gpg? Would it take a lot of effort to use your service with something like mutt? Without looking at the client code, I'm guessing client-server is all http(s)? So in order to make a non-browser client one would have to wrap the client-server communication some how (eg: sync mail from server to disk, and set up a binary("sendmail"), or smtp proxy for sending mail)?
    - pzduniak 11y ago
      Right, I ignored sending unencrypted emails as they can be already considered "broken" as soon as they reach Gmail. Those emails are the only ones whose plaintext we see for a short amount of time, but we get rid of it as soon as we send it out to a remote server. Regarding RFC-compatible PGP emails - unfortunately right now it doesn't interop well at all. The server does support sending of PGP/MIME emails, but IIRC the frontend doesn't have any code for that. Internally we try to use our own PGP Manifest format for everything - it leaks the attachments count, but it's a lot faster and easier to parse (for example during clientside search index generation that we're working on). PGP/MIME switch in the app is in plans, but we're far from implementing such thing. Client-server is all HTTPS, either over plain requests or a SockJS bridge. I've already written a non-browser client that automatically sends "onboarding" emails and forwards emails to our support system - you can see its sourcecode here: https://github.com/lavab/lavabot https://github.com/lavab/lavabot. If there's enough interest, we might even create an official CLI client for the service - I've recently suggested a native app design that might work pretty well in such use case ;)

by simi_ 11y ago

bradleybuda 11y ago

This is a reasonable approach, but there's a weak link in public key exchange. If Lavaboom (or any other trusted third-party) is facilitating public key exchange, there's nothing preventing them from saying "DE:AD:BE:EF" is Bob's public key when in fact it belongs to Eve the attacker. Not to say that Lavaboom would do this maliciously, but they might be compelled to do so by a state actor or law enforcement. As a rule of thumb, a messaging system S can only be zero-knowledge if you have exchanged a secret or key with someone else outside of system S. See the HN discussion on iMessage: https://news.ycombinator.com/item?id=7315964 https://news.ycombinator.com/item?id=7315964

pzduniak 11y ago
We plan to improve it in the nearest future. Yesterday I started work on support for message signing, the server part should be ready next week. Later we'll add support for fetching keys from external exchanges (such as pgp.mit.edu).

declan 11y ago

> Alice's email needs to be sent as plaintext Thanks for your explanation! Though in your hypothetical Carla uses Gmail, and Google supports SMTP TLS. So the email would be encrypted in transit to Google's servers. The problem, which the previous poster may be alluding to, is when a lavaboom user emails a non-PGP user with an account at an email provider that fails to support SMTP TLS. When I wrote about this for CNET two years ago, Hotmail, Yahoo, and AOL did not support it: http://www.cnet.com/news/how-web-mail-providers-leave-door-open-for-nsa-surveillance/ http://www.cnet.com/news/how-web-mail-providers-leave-door-o... Now it looks like all three of those companies do, so the question is: Which providers still fail to, two years post-Snowden disclosures?

simi_ 11y ago
TLS transport is nice to have, but some people can work around it. [0] That's why I only considered PGP, but you're right, SMTP TLS is important. We've also been toying with SMTorP. [1] 0: http://en.wikipedia.org/wiki/PRISM_%28surveillance_program%29 http://en.wikipedia.org/wiki/PRISM_%28surveillance_program%2... 1: https://github.com/mailpile/Mailpile/wiki/SMTorP https://github.com/mailpile/Mailpile/wiki/SMTorP

e12e 11y ago

Just pointing out that 3) isn't really a meaningful guarantee, as you can keep a copy of the session key. I'm not saying that you do, just saying that there's no way to verify either way. I don't think this detracts from your service in a meaningful way, though. Do you support clear-signing and/or choosing to send in the clear? (I'm asking mostly out of curiosity, but from a security perspective it can be important in order to be able to send deniably (eg: no, wasn't me that sent that file to a journalist -- look, it's a plain email, anyone could've sent it...)).

pzduniak 11y ago
All encryption is done clientside, all we see are armored PGP messages. Cleartext signing isn't supported right now, but it's in our issue tracker and I believe that it should be implemented during the next few weeks.
- e12e 11y ago
  > All encryption is done clientside, all we see are armored PGP messages. Are you saying 3) above is wrong? Or are you saying that the client, when sending a plain-text message, first encrypts that message, and stores it on your servers, and then sends the email directly? Because that is the only way you can guarantee that you don't have a means to access a copy of the email that is sent un-encrypted. I understand that when sending encrypted emails (which I gather is your current main focus), the email is encrypted by the client before it is sent on to you. Another question: how well does this all interop with traditional email+gpg? Would it take a lot of effort to use your service with something like mutt? Without looking at the client code, I'm guessing client-server is all http(s)? So in order to make a non-browser client one would have to wrap the client-server communication some how (eg: sync mail from server to disk, and set up a binary("sendmail"), or smtp proxy for sending mail)?
  - pzduniak 11y ago
    Right, I ignored sending unencrypted emails as they can be already considered "broken" as soon as they reach Gmail. Those emails are the only ones whose plaintext we see for a short amount of time, but we get rid of it as soon as we send it out to a remote server. Regarding RFC-compatible PGP emails - unfortunately right now it doesn't interop well at all. The server does support sending of PGP/MIME emails, but IIRC the frontend doesn't have any code for that. Internally we try to use our own PGP Manifest format for everything - it leaks the attachments count, but it's a lot faster and easier to parse (for example during clientside search index generation that we're working on). PGP/MIME switch in the app is in plans, but we're far from implementing such thing. Client-server is all HTTPS, either over plain requests or a SockJS bridge. I've already written a non-browser client that automatically sends "onboarding" emails and forwards emails to our support system - you can see its sourcecode here: https://github.com/lavab/lavabot https://github.com/lavab/lavabot. If there's enough interest, we might even create an official CLI client for the service - I've recently suggested a native app design that might work pretty well in such use case ;)