On Tue, Mar 8, 2011 at 12:19 PM, Martin Rex <mrex(_at_)sap(_dot_)com> wrote:
resend (Sorry, for the typos.)
Martin Rex wrote:
The truncation of hashes/PRFs/HMACs is a trade-off.
A trade-off between collision-resistance and how much clue
is provided about the input.
TLSv1.0 (rfc2246) references RFC-2104 (HMAC)
TLSv1.1 (rfc4346) contains a normative reference to RFC-2104 (HMAC)
TLSv1.2 (rfc5246) contains a normative reference to RFC-2104 (HMAC)
http://tools.ietf.org/html/rfc2104#section-5
5. Truncated output
Applications
of HMAC can choose to truncate the output of HMAC by outputting the t
leftmost bits of the HMAC computation for some parameter t (namely,
the computation is carried in the normal way as defined in section 2
! above but the end result is truncated to t bits). We recommend that
! the output length t be not less than half the length of the hash
! output (to match the birthday attack bound) and not less than 80 bits
(a suitable lower bound on the number of bits that need to be
predicted by an attacker).
Ok, but this is just a handwavy rationale. As far as I'm aware, the
actual cryptographic
analysis is as Hovav has stated.
-Ekr
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf