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