
More Than One Third of Tutanota Emails Are End-To-End Encrypted - Kaylan
https://tutanota.com/blog/posts/encryption-percentage
======
sarciszewski
Did they ever fix their protocol?

[http://seclists.org/fulldisclosure/2015/Jun/58](http://seclists.org/fulldisclosure/2015/Jun/58)

How do they prevent man-in-the-middle attacks on their customers, even if
their server is the one performing the attack?

~~~
winstonschmidt
They commented on this on Reddit:
[https://www.reddit.com/r/fulldisclosure/comments/3anfjk/tuta...](https://www.reddit.com/r/fulldisclosure/comments/3anfjk/tutanota_encrypted_email_service_malleable/)

"This is not a vulnerability in Tutanota. We have built Tutanota with multiple
layers of protection for our users. We currently use TLS and DANE to protect
authentication and data integrity and (only tunneled) RSA-OAEP and AES-CBC to
provide confidentiality. We have always communicated this transparently, it is
nothing new. Neither the confidentiality nor the integrity of our users' data
has been at risk. However, we know that the implementation is not perfect
regarding this detail. That is why we are going to implement the following
features as soon as possible: - Signatures/MAC - 2-factor authentication -
Algorithms resistant to attacks of quantum computers - Simple verification of
downloaded Tutanota apps Regarding the described issue, we know of two
possible attacks on AES-CBC. Neither of them is feasible against Tutanota
users: - Bit flipping: You need access to the plain text email and you have to
be the MITM. - -Plaintexts are available at the sender and recipient only. We
use secure TLS algorithms and DANE to protect against MITM. - Padding oracle:
There is no padding oracle in Tutanota. Tl;dr There is no known vulnerability
in Tutanota. Security is the heart of Tutanota, and we will fix
vulnerabilities immediately."

~~~
tptacek
An end-to-end encrypted messaging company claiming to use DANE to protect end-
users. Sheesh.

~~~
sarciszewski
Especially when the objection I raised is that the server can perform
privileged active attacks on the client software.

I'd say avoid Tutanota.

------
sillysaurus3
_" There is simply no reason NOT to encrypt anymore Even to people not very
interested in protecting their privacy, there is simply no reason anymore to
let the spies look into their mailbox while they can have exactly the same
product with automatic encryption."_

Actually, there are good reasons not to: Spam filtering. People have forgotten
how bad spam was. It isn't possible to fight spam centrally when all email is
encrypted.

Pretending that there aren't any downsides isn't the way forward. It's
important to be open about the issues at stake, then say what's possible with
the tools that can be created.

~~~
belorn
Let's imagine a world where spammers has to encrypt their emails. That would
initially be a hassle and resource demanding, but it would be used against
spammers. The recipient could demand a resource demanding encryption which for
a normal server take about a second but if you were to send out millions it
would be impractical.

~~~
StavrosK
If that's so easy to do, why don't recipients "demand" some proof-of-work
right now?

There's also exactly zero overlap between encryption and proof-of-work. I
don't see why you phrase it as if encryption makes proof-of-work either
possible or easy.

~~~
gburt
The network effect changes (very expensive) which limit adoption of proof of
work also limit adoption of encryption. Assuming encryption is adopted, the
vendor(s) involved could simultaneously demand using Hashcash or another email
proof of work system.

One should seriously estimate and discuss the environmental implications of
such a change before working towards it though, I think.

[https://en.wikipedia.org/wiki/Hashcash](https://en.wikipedia.org/wiki/Hashcash)

------
ClintEhrlich
It's ironic: In many ways, the simplest problems are the hardest for hackers
to solve. We naturally understand programs and protocols that flummox average
users, including PGP and Bitcoin. Donning the veil of techno-ignorance is an
elusive skill, so it can take a long time to figure out how something valuable
can be reduced to a truly idiot-proof format.

Lots of different approaches to encryption have pitched themselves as the
easy-to-use replacement for PGP. Alas, so far, none of them have taken the
world by storm.

~~~
sillysaurus3
_Lots of different approaches to encryption have pitched themselves as the
easy-to-use replacement for PGP. Alas, so far, none of them have taken the
world by storm._

That's good, though. PGP is the only one that's given true safety. Everything
else has broken, either in theory or (mostly) in implementation. The problem
is a social one, and it doesn't need to be solved quickly. It's fine if it
takes several more decades before we find the right model.

Those that want to protect themselves can do so. Those that don't, don't. Not
such a bad outcome, all things considered.

It seems like PGP's web of trust model was the mistake, anyway. There's not
much wrong with the model of "here's my pubkey, and now you can send me data
securely." The key can be intercepted or subverted, but what changed since the
80's was the rise of instant messaging. In 2015, you're often talking to
people in realtime, and you want to talk and send data to them securely. To do
that, you're exchanging keys in realtime, over some kind of chat program.
(Even emailing someone a pubkey counts as a form of chat.) In that context,
the web of trust is unnecessary.

~~~
toothbrush
Emailing somebody your public key sounds like a really bad idea. What about
your friend's evil sysadmin who replaces the public key that you sent with
another one, thereby enabling MITM? You might as well not use PGP in that
case. Of course, once your friend has established that it was indeed your
public key, it's all fine, but doing initial key exchange over unauthenticated
channels sounds like a recipe for disaster.

~~~
mitchtbaum
> What about your friend's evil sysadmin who replaces the public key that you
> sent with another one, thereby enabling MITM?

You could also send with it detached key signatures from mutually trusted
friends. This would add weight to your claim that this key belongs to you.
Then, your recipient can check that your message's contents (including your
pubkey) are signed by a key that your receiver can adequately measure
authenticity. Does that seem right?

If a hostile MITM modifies your message and/or your key and signature, then
these friend's signatures won't match. If they change these signatures as
well, then those won't match the receiver's already trusted keys.

[Aside: One other way I have played with was to rate another signed message by
a friend (who sent me his pubkey as an email attachment) with a likelihood
that he wrote it, and then I checked if that message's signature matched. As a
qualitative heuristic test, it did increase my confidence in that key
significantly, though I would have liked to have some trusted 3rd parties
witness his possession of it.]

------
serichsen
OK, so who manages the keys, and how?

I am aware of only two general principles to do this: centralized certificate
authorities (possibly chained), and decentralized assurance, a. k. a. web of
trust. Their advantages and drawbacks seem pretty clear by now.

So, which is it, and if a CA (which I'd assume), who has the keys and how is
crytographic trust obtained?

------
ratsmack
There is nothing wrong with PGP, and I don't understand the desire to see its
demise. I agree that it has not been properly integrated with MUA's to the
point it is seamless for casual users, but I believe it's the best we have for
now.

------
st3fan
I think that should read "Only one third of emails are end-to-end encrypted".

