On Tue, Mar 8, 2011 at 10:15 AM, Marsh Ray <marsh@xxxxxxxxxxxxxxxxxx> wrote:
> On 03/08/2011 11:33 AM, Eric Rescorla wrote:
>>
>> On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex<mrex@xxxxxxx> wrote:
>>> Cutting down the SHA-384 output from 48 to 12 octets significantly
>>> impairs
>>> its ability to protect from collisions. It's comparable to
>>> truncating the SHA-1 output from 20 to 5 octets.
>
> I think it's more comparable truncating SHA-1 down to 12 octets.
Yes, this matches my analysis.
>> I don't understand this analysis. Consider two ideal PRFs:
>>
>> * R-160 with a 160-bit output
>> * R-256 with a 256-bit output
>>
>> Now, consider the function R-256-Reduced, which takes the first 160
>> bits of R-256.
>> Are you arguing that R-256-Reduced is weaker than R-160? If so, why?
>
> I think he's arguing that anything cut down to 96 bits represents a lousy
> hash function allowing practical collisions on today's hardware.
Perhaps, but this isn't a digest but rather
a MAC, and so the attack model is different. Without knowing the key, you
basically have a 2^{-b} chance of producing an input which will pass the MAC
check, where b is the length of the MAC. Note that additional computational
power doesn't help much here because you still need to search the entire
key space, not the output space, in order to break the MAC.
However, the answer to *this* question is a distinct from whether a different
size hash function used as the basis for a MAC demands a different truncation.
-Ekr
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf