MatthiasPfau

> Why is there so much resistance to implementing authenticated encryption?

We already stated that we are going to implement authenticated encryption. But when we do it we have to do it right. We have to keep everything backwards compatible and we can't enable one client to use the new implementation until all supported clients (JS, .NET (Outlook), Android and iOS) are upgraded. Implementing this kind of backward compatibility will not take only 10 minutes.

Please submit a pull request that keeps everything backwards compatible and works for all platforms. We are happy about everyone who wants to contribute.

Thanks for clarifying.

> an attacker can keep sending forged messages until it decrypts successfully

There is simply no way for an attacker to find out if his forged messages decrypt successfully besides having full control of the recipients machine. The padding oracle is useless in this case.

> They seem to confuse digital signatures with message authentication.

Why do you think that? Of course we (I am one of the founders of Tutanota) understand the difference of the two.

> They're using PKCS5 which means that, yes, there is a padding oracle vulnerability

Could you please describe the padding oracle? Knowing the padding algorithm is not enough to make up a padding oracle. The oracle must be able to decrypt the cipher text in order to tell the attacker if the padding is valid or not.

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.

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!

I am one of the founders. Thanks for your feedback. We will fix this early next year!

You can try out our beta-app by sending your email address for the Google Playstore to [email protected]

All data in Tutanota is encrypted with the user’s password. With Tutanota we want to protect our human right to privacy, particularly as we know most services save their user’s data unencrypted. We would very much like to hear your thoughts and recommendations!

Crypto within the browser is a challenge, but possible. Here are some points to consider: 1. You need strong random numbers. 2. The browser automatically downloads the client application on each reload. 3. XSS attacks are a problem for all applications running in a browser. 4. Beware of browser plugins: They might log keys entered (Never install evil plugins!)

This is how we mitigate these challenges: 1. We use the Fortuna algorithm to generate strong random numbers, seeded with crypto.getRandomValues(), mouse events, key events, ping times, and the state of the random generator of previous sessions. 2. We install the application to the browser cache. A reload only happens upon releasing an application update and the user gets notified automatically. Alternatively you can run your own application locally (see github). The download of the application is secured with SSL and DANE. 3. XSS: We use google-caja to mitigate XSS attacks and will introduce Content Security Policy (CSP) within a few months. Any further concerns, just ask!