[onli]

The statements about german law are wrong or at least very misleading, and that might be important here.

Mail Providers of a specific size here are obliged to implement Lawful Interception interfaces. It is quite obvious that in the current climate, there is no guarantee at all that those won't be used by the german intelligence and then transported to the NSA.

Note also that their source-link in that paragraph is not working.

However, the situation might actually work. If they have a true zero knowledge system, it could indeed be very hard in Germany to force them to produce additional data, and what they can't have they can't deliver. That is however not as clear-cut as they make it look like.

That is comparable to the Vorratsdatenspeicherung, ISPs saving the traffic metadata. While the effort to force them to do that failed, all ISPs still save those data - meaning that Germany is not the described data heaven.

[higherpurpose]

I doubt any system designed in such a way that the provider simply can't access the information, could be forced by authorities to provide some kind of backdoor into it, if it's a somewhat lawful country, and not one such as North Korea or whatever. Whether companies can be intimidated into doing it is a whole other story, but legally, I doubt any democratic government should be able to force them to do that.

[mike-cardwell]

Hushmail is a similar service, but uses a java applet for the client side crypto. It's my understanding that they have been legally compelled at least once to deliver a backdoored applet to the client in order to access the clear text email. I think they're Canadian. I don't have references to hand, but a Google search should turn some stuff up.

Whilst yu, "doubt any democratic government should be able to force them to do that", I on the other hand suspect that most (if not all) democratic governments have ways of doing exactly this.

[akerl_]

Except those two things are mutually exclusive: A provider that can put a backdoor in can access the data, they're just choosing not to right now. Relevant example:

http://www.daemonology.net/blog/2012-01-19-playing-chicken-w...

[ianopolous]

Here's an example of that for PrivateSky: http://www.ibtimes.co.uk/gchq-forced-privatesky-secure-email...

[aswerty]

PrivateSky looks like it had the same failing as LavaBit in that the service provider actually had access to the decryption key for your email. So encryption in these services was vulnerable to a court order imposed on the service provider to use or share the key.

I'm not saying Tutanota don't have an issue like this but their main selling point appears to be that this isn't the case.

[e12e]

Looks like they have a true zero knowledge system, up to the point when they have to implement logging of the password on the client side, and transmitting it to the server. At that point, if I understand the system, they have access to everything.

I don't see much point in this, as long as you can't host your own mail servers (you can host your own "server" in order to have somewhere to get the client from -- which is a step in the right direction -- but as I understand it, you can't use this as a webmail front-end for your own server(s)).

[aswerty]

Just with regards to the password being transmitted to the server. A quick look at the source code shows a bunch of crypto files. They could, and probably are, encrypting client side and just comparing the cypher text. Someone need to do a bit more digging to verify that.

[e12e]

From the FAQ:

> Your private key is encrypted with your password and then stored on our servers in encrypted form so that only you have access to it. In this design your login password receives the status of the private key. Your password is salted and hashed on your device before being transmitted to Tutanota. With this method we guarantee an integrated confidentiality and we allow you to access and decrypt your emails from desktops and mobile devices instantly.

And:

> Your private and your public keys are generated locally within your browser upon registration. Your private key is encrypted with your password. This way your login password receives the status of the private key. The key is encrypted so strong that only you can use the key for encrypting and decrypting data. This is why a strong password is essential. An automatic password check on the client makes sure that you use a strong password. Your password is never transmitted to the server in plain text. It is salted and then hashed with bcrypt locally on your device so that neither the server nor we have access to your password. We can not reset your password. With this innovative design you can access your encrypted inbox from any device (desktop, mobile) easily.

I've not looked at their "automatic password check", but generally passwords such as "Password2014" are considered secure (Three character groups, long password...).

At any rate, if you host your own client, and one can turn off loading of images and other in-line resources -- this looks better than most "secure web mail" clients I've heard of.

But if you allow them to host the client, I don't see how they can't just change the js to log your password. And they only have to do it once, because they then have access to your private key (they store a copy, and only need your password for access).

[MatthiasPfau]

I am one of the founders, thanks for your discussion. We only load the app into your browser cache upon an update of which the app notifies you. However, we are very aware of the challenges that come along with making browser-based encryption secure. We are looking into ways how to easily verify that the JS executed in the browser matches the published open source code on Github. If you have any recommendations here, let us know!

[e12e]

As long as it is only a client-side app, why not refactor it so it can be hosted directly from github? What you're saying is that users can a) verify a release and host it themselves, b) trust you to serve up good code, c) trust the code you release on github. In b) they trust you're not complying with demands from a covert or overt agency, in c) they're trusting that you are not publishing subtly subverted code, or that github is complying with demands from a covert or overt agency (and in a) they're trusting that their host/colo isn't complying with demands from some agency.

In all a), b) and c) users are also trusting the transport layer, which in general means trusting the CA systems -- which of course means that the whole thing is moot -- the system is hopelessly insecure.

At least with a) you can host the client inside the firewall/security boundary -- and so a) can be as secure as any other solution.

It'd still be a lot more interesting if you at least published an API, so that other's could implement and run their own server (network) -- and not need to rely on a single company for access to their data.

[MatthiasPfau]

Thanks for your feedback! Hosting directly from github might be a good idea for the ones that regard github as a trusted third party. However, github would gain the possibility to manipulate the code to gain access to your accounts...

We plan to create an API and already started brainstorming on it: https://github.com/intermail/api/wiki

Regarding trusting the CA systems: We use DANE to secure your connection to our servers.