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

[Martin Rex <[e-mail]>]

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.


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.


-Martin