Hugo Krawczyk wrote:
The technical results in my 2001 paper are correct but the conclusion
regarding SSL/TLS is wrong. I assumed that TLS was using fresh IVs and that
the MAC was computed on the encoded plaintext, i.e. Encode-Mac-Encrypt
while TLS is doing Mac-Encode-Encrypt which is exactly what my theoretical
example shows is insecure. The later padding attacks showed that the
theoretical example of insecurity had a very practical instantiation in
TLS. While the paper shows correctly that MAC-then-Encrypt can be secure
with both CBC and stream ciphers, it also shows that it requires a LOT of
care about encoding - it turned out that TLS/SSL was not doing that. So if
you want to keep Mac-then-Encrypt then you must change the encoding as well
as how you apply the MAC. Changing to Encrypt-then-MAC is a much safer
solution.
I agree with you that your paper demonstrates problem with
mac-extend-encrypt schemes. And that it fails to notice that
TLS applies CBC padding after computing the MAC and before encryption,
and is therefore an mac-extend-encrypt scheme that can be susceptible to
decryption oracles.
But I strongly disagree to the assertion that "Encrypt-then-MAC" would
be a much safer scheme than *TRUE* MAC-then-Encrypt _withou_ any
extension inserted before the encryption such as CBC-padding.
In fact, the pad-mac-encrypt scheme for TLS-CBC-ciphersuites, as suggested
by Serge Vaudenay, is provably safer than the currently favoured
encrypt-then-MAC scheme.
-Martin