Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

From: Peter Gutmann <[email-masked]>
Date: Tue, 24 Sep 2013 04:52:42 +0000

Nikos Mavrogiannopoulos <[email-masked]> writes:

>The innovate refers to how the current EtA proposal by Peter ignores all best
>practices in implementing EtA in protocols.

You seem to be saying there that HMAC has security problems unless it's
truncated, which is something that AFAIK no other cryptographer has ever
noticed.  Perhaps you could clarify the weakness for the list, and then
consider publishing a conference paper on it.  It sounds like an amazing
breakthrough in the cryptanalysis of HMAC.

>Existing EtA protocols like IPSec truncate the HMAC to avoid revealing the
>whole internal state of the hash algorithm.

S/MIME doesn't truncate it.  TLS doesn't truncate it.  PGP (although that
doesn't really use a MAC, but still...) doesn't truncate it.

In any case TLS has, for some years now, allowed for truncated MACs.  If
anyone really feels this is an issue, they can use truncated_hmac to require
truncation to any length they feel comfortable with.

Peter.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 24 Sep 2013 10:06:08 +0200

On 09/24/2013 06:52 AM, Peter Gutmann wrote:

>> The innovate refers to how the current EtA proposal by Peter 
>> ignores all best practices in implementing EtA in protocols.
> You seem to be saying there that HMAC has security problems unless 
> it's truncated, which is something that AFAIK no other cryptographer 
> has ever noticed.  Perhaps you could clarify the weakness for the 
> list, and then consider publishing a conference paper on it.  It 
> sounds like an amazing breakthrough in the cryptanalysis of HMAC.

No I am not saying that and please do not twist my words to make a
point. I say that best current practice in protocols is to follow the
Preneel-van-Oorschot advice and do a truncation on the hash-based-mac to
prevent certain attacks (described in their paper). You do not follow
this advice on your proposal and you give no reasons why.

The only reason I've heard against truncation is some story you repeat
about IP headers space. Both the IPSec RFCs and people who participated
in the discussions say otherwise, and thus make your claim not convincing.

I may be wrong and truncation may not be needed, but you give not
convincing reasons why.

>> Existing EtA protocols like IPSec truncate the HMAC to avoid 
>> revealing the whole internal state of the hash algorithm.
> S/MIME doesn't truncate it.  TLS doesn't truncate it.  PGP (although 
> that doesn't really use a MAC, but still...) doesn't truncate it.

TLS doesn't truncate it because it uses the AtE mode which means it is
encrypted (and thus the simple hash-based-MAC attacks don't directly
apply). S/MIME and PGP aren't online protocols and use the MAC key for a
single message, thus several attacks don't apply to them.

regards,
Nikos