Ted Unangst <t...@tedunangst.com> wrote: > > Using the names hmac-sha2-256-96 and hmac-sha2-512-96 is a violation of > > the spec since that namespace is managed by IANA. They could be > > implemented as vendor extensions (hmac-sha2-256...@openssh.com and > > hmac-sha2-512...@openssh.com). > > Any reason to do so? Are the truncated hashes particularly > beneficial?
Probably not. You may remember from a number of releases back that we used to support HMAC-SHA2-256-96 in IPsec after an early draft, but had to change this to HMAC-SHA2-256-128 to comply with RFC4868 when people belatedly remembered that the HMAC result shouldn't be truncated further than half the length of the hash output, as per RFC2104. Now, that is 15-year-old advice. In his 2011 overview, http://www.cs.ucdavis.edu/~rogaway/papers/modes.pdf Rogaway writes: 9.7. Truncation. HMAC truncated to t bits is, inevitably, subject to an attack that forges with probability q_v/2^t in q_v verification attempts; as a consequence, the parameter t should, in most cases, be kept fairly large. Why, then, truncate at all? One reason for allowing MAC truncation is the obvious one, to lessen bandwidth or storage costs. More interestingly, truncation appears to make the birthday attack less effective, because internal collisions can no longer be identified by collisions in the HMAC outputs. A little truncation may thus improve security. We emphasize, however, that while there are proofs that truncation will not degrade security by more than the addition of the term that we just mentioned, there is no known proof that truncation can improve security--not even in the random-oracle model. We suspect, however, that this is more indicative of technical difficulties in the proof--or the lack of a really serious effort--than the absence of a quantifiable improvement. We emphasize that the concrete security loss from truncation is "only" the q_v/2^t term that one "must" be for truncation; we are not speaking of the more severe drop in security as one sees when truncating tags with GMAC (10.6) or GCM (12.6). -- Christian "naddy" Weisgerber na...@mips.inka.de
