Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx

[Eric Rescorla <[e-mail]>]

On Tue, Mar 8, 2011 at 10:07 AM, Martin Rex <[e-mail]> wrote:
> Eric Rescorla wrote:
>>
>> On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex <[e-mail]> wrote:
>> > Eric Rescorla wrote:
>> >>
>> >> I don't understand this reasoning. Why does the output size of the
>> >> pre-truncated PRF
>> >> influence the desirable length of the verify_data (provided that the
>> >> output size is > than
>> >> the length of the verify_data of course).
>> >
>> > One of the purposes of a cryptographic hash function is to protect
>> > from collisions (both random and fabricated collisions).
>> >
>> > 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 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?
>
> What we're having are the two cases:
>
>  1)  R-160 truncated to 96 bits
>  2)  R-256 truncated to 96 bits
>  3)  R-160 with full 160-bits
>
>
> If your primary focus was collision avoidance, then
> 3) is stronger than 1) and 2) by a huge margin.

Yes, I totally agree.


> There may be reasons why you don't want (3), like an attackers ability
> to verify when he guesses keys correctly that are input to the PRF.
>
> When 20/12 is a good truncation ratio for a 160-bit PRF,
> then 48/12 looks like a poor truncation ratio for a 384-bit PRF
> (and SHA-384 is already a truncated SHA-512 anyway).
> Applying the 20/12 tradeoff to R-256 results in approximately (32/20)
> and to R-384 results in approximately (48/28) -- with (48/32) probably
> sufficiently close.

I don't understand this analysis at all. Again, are you arguing that
(1) and (2) have
different security properties?

If not, then why does it matter what the size of the input PRF is, as
long as it is >=
the size to which it is truncated?

-Ekr