Date: Sun, 21 Jun 2015 16:59:01 -0400
From: Scott Arciszewski <scott@...agonie.com>
To: fulldisclosure@...lists.org
Subject: [FD] Tutanota Encrypted Email service - Malleable Ciphertext
 (AES-CBC with no MAC)

Hi Full Disclosure readers,

The symmetric-key encryption used in Tutanota is vulnerable to ciphertext
malleability (a.k.a. arbitrary bit rewriting), since they fail to
authenticate their ciphertexts. The offending code snippet (for the Android
version of their app) is here:

https://github.com/tutao/tutanota/blob/7902514b846539643586baba10f293bf8ac975fc/native/src/android/de/tutao/plugin/Crypto.java#L246-L261

I am not the first to discover this implementation/design flaw. It was
previously reported by Richard, and beforehand by Steve Weis on Twitter.

https://tutanota.uservoice.com/forums/237921-general/suggestions/7858974-tutanota-is-using-unauthenticated-aes-cbc-encrypti

Isn't this quite serious for an encrypted email service?
> https://twitter.com/sweis/status/595051847934672898
>
> We're in May... Shouldn't fixing this be a high priority before the end of
> the year?
>
Their official response was to decline the ticket with this message:

The first focus of Tutanota is on encryption, but authentication will also
> be added. Authentication will not be achieved by MACing the messages like
> proposed because the session keys are one-time keys. Digital signatures
> need to be used. We have created this request to track that feature:
>

Indeed, they've confused the purpose of a MAC with the purpose of a digital
signature.

In a nutshell for non-crypto people reading this: MACs are Message
Authentication, digital signatures are "Identity" Authentication. MACs are
typically performed on symmetric encryption, digital signatures are
typically applied using asymmetric encryption. They're almost night and
day, although they (tragically) share the same word in the English language
(and possibly many others).

I opened a follow-up ticket with a link to one of our blog posts explaining
why authenticated encryption is necessary in the hopes that they would read
it, understand the mistakes they are making, and correct them.
https://paragonie.com/blog/2015/05/using-encryption-and-authentication-correctly

However, considering this has been publicly recognized by others and
declined by their development team, I feel that immediate full disclosure
is appropriate.

On that note, Paragon Initiative offers code review services if anyone
would like us to look at their pet cryptography project and verify the
correctness of their implementations. PHP, Java, .NET, Python, you name it.
Keep us in mind if you (or your employer, if applicable) needs such a
service.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists