Hacker News Reader

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

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

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

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

1: https://github.com/mailpile/Mailpile/wiki/SMTorP

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

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.

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

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.

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

Thank you for the link -- I suppose it should've been obvious you'll have some use for command line tools internally, if only for automation (but automation is important, how else can my backup cron job let me know it's completed/failed? :-)

Not so good that you don't (currently) interop all that well. I can understand that gpg/mime is a bit hard, and have some properties that aren't great (metadata/subject header...).

As for plaintext being "broken" when reaching gmail, I suppose I've grown to be a different kind of pragmatic lately. Lets put it this way: I still enjoy postcards, and while (some) encryption is trivial (with the right tools, some of which you are building!) -- I really don't need "another messaging app" (but secure!). I need email that is easy to secure/so easy that always encrypt is useful.

Then again, most of the email I send and receive go to public mailinglists -- without clearsigning, I'd have no use for your product (yet -- none of my private contacts use gpg, and are likely to move to your platform just to get it).

That's not to say I'm not interested to see where you end up, and wish you all the best with your project!