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

[Eric Rescorla <[e-mail]>]

On Tue, Mar 8, 2011 at 10:30 AM, Martin Rex <[e-mail]> wrote:
> Eric Rescorla wrote:
>>
>> 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?
>
> In case they were both "ideal" - no.
>
> But in that case, asking anyone for the effort to replace
> 1) with 2) would be a complete waste of resources.
>
>
> If we move in a new, stronger crypto-algorithm, then we should not
> unreasonably spoil its properties.
>
> Truncating a SHA-384 based PRF to 12 octets is like using
> an sha384WithRsaEncryption signature with a 1024 bit RSA key,
> it is an imbalanced pairing of algorithms&keys.

Again, I don't understand this: TLS already (as of TLS 1.0) truncated
the PRF down
to 12 bytes, so we are already producing an output that is
substantially shorter than
the digest that is the basis of the function. If the security
arguments for why that
is good are valid (and FWIW I think they are) then as far as I can
tell they are
equally applicable to SHA-384.

-Ekr