Re: [TLS] padding bug

[Nikos Mavrogiannopoulos <[e-mail]>]

On 09/24/2013 12:24 PM, Ben Laurie wrote:

>>> Just a small amount of Schadenfreude here when I point out that 
>>> as I was reading through the long list of GnuTLS security 
>>> advisories at http://www.gnutls.org/security.html it seems that a
>>> number of them would have been avoided through the use of the EtM
>>> that Nikos has been so strongly opposed to :-).
>> 
>> I don't understand what does this prove. I was one of the first to
>>  ask for a solution to the issue. Pointing an issue in your draft 
>> doesn't mean I'm against solving the problem.
> 
> The issue you claim is that it does not defend against key recovery 
> attacks. I am not aware of any key recovery attacks against HMAC,
> and MAC truncation was not proposed as a countermeasure for a key 
> recovery attack against any MAC.

Hello Ben,
 I believe it would be better to consult the opinion of an expert on
hash functions and MAC designs. The fact that you (or me for that
matter) don't know something doesn't mean much.

> Can you provide a reference for your claim?

I believe we make circles. I previously referenced IPSec (RFC2104) at:
http://www.ietf.org/mail-archive/web/tls/current/msg09832.html
The same RFC references the Preneel-van-Oorschot paper.

I take your question that you actually read RFC2104 and the
Preneel-van-Oorschot paper and you disagree with their points?

PS. I attach the comment of Bart Preneel on the topic (a cryptographer
with significant expertise on hash functions).

regards,
Nikos

-------- Original Message --------
Subject: Re: truncation of MACs
Date: Tue, 24 Sep 2013 10:51:37 +0200 (CEST)
From: Bart Preneel <[e-mail]>
To: Nikos Mavrogiannopoulos <[e-mail]>

> As I am not familiar with new trends in MACs may I ask you whether 
> this practice of truncation is still believed to provide benefits?

Nikos,
I hope all is well.

There is a tradeoff: if you output more bits, it becomes
harder to predict the whole string (that is, to forge the MAC)
On the other hand, you release more information about the
internal state, hence attacks based on internal collisions
as discussed in the Crypto '95 paper with Paul van Oorschot
becomes more efficient - in some sense you expose more information
about the secret key.

If we look at the attacks during the last 18 years, it is
clear that no (forgery) attack has found that exploits the
fact that a subset of bits of say HMAC-MD5 is easier to predict
than any other subset or that exploits truncation (except for
a reduced guessing cost). On the other hand, several (key recovery)
attacks on MAC algorithms (including HMAC-MD4 and HMAC-MD5)
have been found based on internal collisions. These attacks
would become more difficult if fewer output bits are available.

I am in general more concerned about key recovery attacks (allowing
an unlimited number of forgeries) than about forgery attacks.

My conclusion is that my intuition as cryptanalyst was correct
and that it would be best to shorten the output of a MAC
algorithm to half the internal state.

Note that many strong designs in the SHA-3 competition are
wide-pipe, which means that the internal state is larger than
the output; this is to preclude multi-collision attacks,
long message second preimage attacks, and herding attacks on
hash functions (these are attacks on hash functions discovered
between 1999 and 2005 that exploit the fact that the output size
is equal to the internal state). There is some solid theory
underpinning these design choices.
Part of the current controversy on the NIST planned draft
for SHA-3 (FIPS 202) is that the Keccak design was wide-pipe
while the planned draft will reduce the internal state to increase
performance.

While hash functions are not exactly the same as MAC algorithms, I
believe that these developments in hash functions go along the
same lines as our recommendations from 1995:
  - new attacks are discovered that exploit the fact that the
    size of the output is equal to the size of the internal state
  - the response is to make designs with internal state equal to
    twice the output state.


I hope that this helps.

Regards,
Bart