[sarciszewski]

They seem to confuse digital signatures with message authentication.

> Padding oracle: There is no padding oracle in Tutanota.

Interesting claim. They're using PKCS5 which means that, yes, there is a padding oracle vulnerability, but triggering it is orders of magnitude more difficult than null padding.

https://github.com/tutao/tutanota/blob/tutanota-1.9.2+/nativ...

[MatthiasPfau]

> 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.

[sarciszewski]

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

Because you put them on the same line item.

https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-pass...

> 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.

For fuck's sake, Google it. The top two search results explain it perfectly.

http://robertheaton.com/2013/07/29/padding-oracle-attack

https://blog.skullsecurity.org/2013/padding-oracle-attacks-i...

TL;DR if you aren't using authenticated encryption, because you're using CBC mode with a block cipher, an attacker can keep sending forged messages until it decrypts successfully. It's much easier to forge messages on zero byte padding than exploit PKCS(5|7), but attackers can still exploit padding errors to tell if their message decrypted.

[MatthiasPfau]

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.

[sarciszewski]

"The padding oracle is useless because we don't behave differently if decryption fails" doesn't really inspire confidence.

Why is there so much resistance to implementing authenticated encryption? It would literally take 10 minutes to implement, with constant time MAC verification on the recipient's end. That includes the time to unit test it.

Hell, I could send a pull request right now to do it if your team doesn't have the expertise on board.

Better yet: use Libsodium.

https://paragonie.com/blog/2015/09/how-to-safely-implement-c...

[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.

[sarciszewski]

> Please submit a pull request that keeps everything backwards compatible and works for all platforms.

Secure crypto is never backwards compatible with insecure crypto. If you want to expose your users to downgrade attacks, have fun.