On Tue, Mar 8, 2011 at 12:19 PM, Martin Rex <m...@sap.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
