[12584] in cryptography@c2.net mail archive
Re: [Bodo Moeller ] OpenSSL Security Advisory: Timing-based attacks on SSL/TLS with CBC encryption
daemon@ATHENA.MIT.EDU (Anton Stiglic)
Tue Feb 25 10:38:54 2003
X-Original-To: cryptography@wasabisystems.com
X-Original-To: cryptography@wasabisystems.com
From: "Anton Stiglic" <astiglic@okiok.com>
To: "Bodo Moeller" <moeller@cdc.informatik.tu-darmstadt.de>,
<cryptography@wasabisystems.com>
Cc: <ietf-tls@lists.certicom.com>
Date: Tue, 25 Feb 2003 10:41:51 -0500
Bodo Moeller wrote:
> Actually there are three choices:
>
> Pad-then-encrypt-then-MAC
> Pad-then-MAC-then-encrypt
> MAC-then-pad-then-encrypt
>
> It's true that pad-then-encrypt-then-MAC appears to be the safest
> approach in general, but pad-then-MAC-then-encrypt would also have
> avoided these attacks.
By Pad-t-MAC-t-encrypt, do you mean a scheme where
the MAC is also encrypted, or is left aside (the encrypt and
authenticate method).
There are problems with the latter as well, see appendix C of the
paper from Krawczyk...
If it's the first, then I guess that what you mean by
Pad-t-MAC-t-encrypt is that you first pad the message (and
IV and whatever other context) such that when you append the MAC
(e.g 160 bits with SHA1-MAC) to the ciphertext the resulting size is a
multiple of the block cipher size. So when you decrypt, you don't
check the padding, but then after verifying the MAC you would take
out the padding (and I guess verify it...). You can't play with the
padding, because the MAC will fail. But if you are using CBC-DES
as a MAC, you need to make sure that the MAC is verified first,
not check the padding first, if not you *might* fall in to a similar trap
(I'm not certain a vulnerability would exist in that context, but it sounds
plausible).
>[...]
>The attack demonstrated by
>Vaudenay et al. users a less subtle timing difference (the difference
>between a MAC on about 256 SHA-1 input blocks and no MAC
>at all), but switching to Pad-then-MAC-then-encrypt should be considered
>for TLS 1.1.
Pad-t-MAC-t-encrypt sounds like an interesting avenue, but why
would you propose that for TLS 1.1 instead of just proposing the safe
Pad-t-Encrypt-t-MAC? If there is going to be a change,
might as well go with something that is provably secure, or is there some
reason (compatibility or something) to prefer Pad-t-MAC-t-Encrypt
that I do not see here?
--Anton
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
