Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex <mrex(_at_)sap(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf