Re: [TLS] padding bug

[Ben Laurie <[e-mail]>]

On 24 September 2013 15:28, Bodo Moeller <[e-mail]> wrote:
>
>> > I take your question that you actually read RFC2104 and the
>> > Preneel-van-Oorschot paper and you disagree with their points?
>
>
>>
>> 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.
>
>
> I think this reasoning is not quite right because that attack requires
> *internal* collisions (and the internal state wouldn't be truncated).

That's what makes it harder :-)

>  Of
> course, it's not an attack on HMAC.
>
>
>>
>> d) If you _really_ want to defend against this attack, the right
>> answer is to design hash functions with bigger internal state.
>
>
> Exactly. Given a particular l-bit MAC with an l-bit internal state,
> truncating its outputs (such as to l/2 bits) isn't demonstrably an
> improvement.  Rather, if we want an l-bit MAC, it makes sense to have an
> internal state larger than l bits.
>
> Nikos, you pointed to RFC 2104. The following is a literal quote from that
> RFC: "The results in this area are not absolute as for the overall security
> advantages of truncation."  In particular, encrypt-then-MAC with untruncated
> MACs isn't a broken design.  (Assuming hypothetically there's a key recovery
> attack on the MAC alone, the encryption step means that the attacker can't
> pick MAC inputs after all.)
>
> Bodo
>