Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

[Ralf Skyper Kaiser <[e-mail]>]

On Thu, Nov 14, 2013 at 4:00 PM, Nikos Mavrogiannopoulos <[e-mail]>wrote:

> On Thu, Nov 14, 2013 at 4:47 PM, Ralf Skyper Kaiser <[e-mail]>
> wrote:
>
> > 1. EtA discards a malicious packet earlier than AtE. This means the
> packet
> > is processed by less programm code and the attacker has less chance to
> > trigger a vulnerability in the program code (We are talking buffer
> overflow
> > [etc!] here as well and not just crypto-vulns).
>
> This is an often repeated argument. How many of these attacks are we
> currently seeing in TLS that doesn't use EtA? None. The difference in
> processing is really negligible to be used in a serious attack.
>
> > 2.With AtE there is a correlation between the MAC and the plaintext. This
> > turns any known-plaintext attack into a ciphertext only attack and you
> > should not have a correlation even if this correlation can not be
> exploited
> > today by public cryptanalytic means.
>
> I don't understand your point. How would they work when the MAC is
> encrypted?
>
> Both EtA and AtE have weak points, depending what you trust more, the
> cipher or the MAC. With EtA you need to trust the MAC as any attacker
> has access to the MAC and the actual authenticated data (which is the
> ciphertext).
>
>
Program code:
With EtA you need to trust the MAC. With AtE you need to trust the cipher
_and_ the MAC.

Correlation with plaintext:
I do not understand your argument. With EtA there just is no correlation.
That's a good thing. Only with AtE there is (that's a bad thing).

regards,

ralf

regards,
> Nikos
>