Lavaboom: Zero-Access Encrypted Email Service Hosted in Germany
techcrunch.com
techcrunch.com
edit: just to point out, we're running a Indiegogo campaign! https://www.indiegogo.com/projects/lavaboom
How do you prevent the scenario of being forced to provide a poisoned client-side encryption payload, just like e.g. Hushmail was?
2. We'll have Chrome/Firefox extensions for something similar to "signed binaries"
3. We offer the option to run the web client yourself (git clone https://github.com/lavab/web && cd web && npm install && gulp && open "http://localhost:5000")
4. We'll build native desktop and mobile clients.
Hope this answers your question.
I don't really understand this fascination with hosting things outside of the US "for security" (from apparently, mostly US citizens). Personally I'm in Norway, where the secret police have been spying on "dissidents" (it used to be the "far" left, nominally the neo-nazis/fascists (although they missed the only terror attack, despite having a tip before the fact) -- now it's the "radical" Muslims (you know, a clearly defined threat to national security, aka "brown scary people")).
But regardless of how one feels about using Stasi methods to help perpetuate and sustain illegal wars on the middle east -- one thing should be abundantly clear: Nowhere (AFAIK) does foreign citizens have any rights to not be spied on by local intelligence services. And of course all of NATO is working together on gathering it (along with Sweden, which Norwegian intelligence reportedly work closely with).
All that said, while I think we should all work at taking back our respective governments, and strive for a better (more free) political environment -- I don't think the only measure for an email service should be "am I now safe from state-sponsored actors". In fact, I think that should actually be pretty low on the list.
Use gpg, or give up. More significantly, if you can't do the work for a proper web-of-trust/key distribution and verification, you can't be secure (in the sense indicated above).
I still think services like these are miles better than you-are-the-product, like gmail/outlook.com etc.
Good luck on your service!
The "NSA can spy on you argument" doesn't really apply here. You just try to provide solid security against that. Having poor security in "America" wouldn't save you from NSA anyway.
I also don't think Germany will be a safe haven for someone working against the drone program if that involves leaking classified information (otherwise known as espionage, even if it stems from altruistic motives).
I feel people are as much in denial about the likelihood of spying by European governments, as many were about the NSA (and for no better reason -- the NSA was documented to break the law long before Snowden, and so have various European governments).
I don't really see this as much of a win either way. But perhaps it's good marketing copy.
(1) run the web client on your own machine, and use Lavaboom this way - if you trust your own computer, of course
(2) install a Chrome/Firefox extension to have some proof that the code is the same as the one at github.com/lavab/web - this is still WIP on our end
Signed native binaries are the best solution IMHO, we're aiming to get there for most major platforms, as I said.
Theoretically we can prove (via Chrome packaged apps, for example) that the code running on Lavaboom's servers (or locally if you run the web app yourself) is from our public repos. If the code doesn't do magic stuff like dynamically changing itself, and since we use TLS to deliver it, it should be impossible to maliciously alter what's running on the client side, unless we leverage some hypothetical unknown-yet browser-specific vulnerabilities(?).
Also, network activity can be monitored, theoretically the users will be able to detect ~if~ when we start streaming their data to NSA servers. Unless you assume our server is completely compromised and we do the streaming ourselves.
By the way, that's why I designed the system with the premise that we ourselves can't be trusted (e.g. haxorz pwnd us etc.) i.e. asymmetric encryption everywhere. Here's for instance some of my actual data (ignore the pre-refactoring messiness): https://gist.github.com/andreis/70c8f5bb1d811f6ac7db
PS: I'm not saying a web app are ideal for what we do, as I mentioned in another comment we started with it due to sheer pragmatism, and we're planning native apps (or at the very least cordova/electron "native" apps). I would really appreciate your thoughts on the matter.
Thanks for answering
We make key management easier by offering the option to enable Lavaboom Sync, basically your public and (encrypted) private keys stay on our server and get downloaded on login.
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.
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
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?
0: http://en.wikipedia.org/wiki/PRISM_%28surveillance_program%2...
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...)).
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.
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)?
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 ;)
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!
Waiting for this to mature ;)
I can try to incentivise you to submit a bug report by promising an extra invite code once you submit an issue. :) (Just link this comment when you email hello@lavaboom.com)
2) We support true end to end email encryption (it's not perfect, but a lot better than encrypting emails using some password in ProtonMail). Also you can manage all of your keys yourself if you wish, or keep your keychain encrypted on our server, just like in ProtonMail.
3) I'm definetely biased, but our stack is far better - ProtonMail uses PHP, which has a questionable reputation, meanwhile we use a static-typed language in the backend (Go).
4) Lavaboom is designed with hosted installations in mind - as soon as we sort out all the basic functionality of the "public version" (ie. hosted on lavaboom.com), we will start work on a self-hosted version which will make running it locally a lot easier - even on a Raspberry Pi :)
5) You can check all of our claims in the source code - we have nothing to hide!
5) Lavaboom to other providers emails use asymetric encryption. ProtonMail on the other hand... http://security.stackexchange.com/questions/58541/how-are-pr... :)
I might have repeated some points, but generally Lavaboom is a far more advanced product, which is in early stages on development. Right now I wouldn't recommend using Lavaboom for casual emailing, but I think that we will have all of ProtonMail's functionality during next two to three months and by the end of the year we should have a stable product with far more functionality for truly privacy conscious people.