Re: [TLS] padding bug

[Ben Laurie <[e-mail]>]

On 24 September 2013 12:26, Nikos Mavrogiannopoulos <[e-mail]> wrote:
> 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.

I have consulted experts. This is why I am puzzled by the objection.

>> 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?

Actually, I did, and I don't disagree with their points, but I
disagree with _your_ points.

a) The paper describes a collision attack, not a key recovery attack.

b) Step one of the attack is "find a collision". Since that is
impractical, even for (untruncated) HMAC-MD5, hash truncation provides
no useful defence against the attack.

c) In any case, the whole point of the truncation defence is to make
it harder to go from _observing_ a colliding MAC to the ability to
construct more collisions. But it mostly does this by making it easier
to observe MAC collisions.

d) If you _really_ want to defend against this attack, the right
answer is to design hash functions with bigger internal state.


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

In which he says he was right for the wrong reasons. So, you need to
reference the right papers (i.e. the ones that describe key recovery
attacks) so we can evaluate the severity of these attacks. I am not
aware of any even vaguely practical attacks against even HMAC-MD5, let
alone any HMAC we're actually contemplating.

Please present your evidence.

(Incidentally, he also agrees that the right answer is to have larger
internal state, not to truncate. SHA-3 gives us this, right?).