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

[[e-mail] (Martin Rex)]

Ralf Skyper Kaiser wrote:
> 
> Is this preference based on security concerns or personal preference and
> ease of implementation/adaption?

  - kiss principle (least amount of protocol and code changes)
  - don't fix if it ain't broken
  - conservative design, higher security margin.
  - personal preference

Stream & AEAD ciphers use XOR for encryption and neither supports random
padding, so manipulating known plaintext can be achieved with 100% precision.
I therefore want to ensure that my integrity protection has a very high
security margin.


> 
> (Reading the Serge Vaudenary thread  suggest the latter - which is fine by
> me - its worth considering the trade off.)
> 
> Encrypt-then-mac has some other security benefits. (Among others that the
> decrypt routine never has to process bogus/bad messages
> [e.g. those where the MAC would fail in current encrypt-mac].).

Which benefits are this?

I am not aware of any security benefit for the real world from
doing EtA over AtE.

If MAC erros were common in the wild, I would know about it,
because I would get customer inquiries about it and regularly see
it in error logs from customers.  During the last 10 years there was
only one occasion where a customer had a low, but persistent amount
of MAC errors.  On investigation, it wasn't MAC errors, it was
actually RSA decryption failures, caused by a firmware bug in
that customers SSL accellerator (for which the vendor produced
a firmware patch after we reported the problem).

-Martin