On 03/08/2011 11:33 AM, 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).
As I mentioned, that appears not to be the case here, but I have found
no written rationale for this design subtlety. I could be missing something.
It's also possible that some cipher suite or mode could be added in the
future that makes a collision on the verify_data significant.
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 think it's more comparable truncating SHA-1 down to 12 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?
I think he's arguing that anything cut down to 96 bits represents a
lousy hash function allowing practical collisions on today's hardware.
The implication for TLS protocol evolution (and anything else
interpreting bytes-on-the-wire) is to keep in mind that the
Finished.verify_data is simply not designed to resist offline collision
attacks.
Remember to bring this up the next time somebody suggests permitting
endpoints to use lousy RNGs, particularly in conjunction with
certificates with fixed DH parameters.
- Marsh
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf