Eric Rescorla wrote: > > On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex <mrex@xxxxxxx> 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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf