I-D ACTION:draft-ietf-ipsec-ah-hmac-sha-03.txt

[HUGO@watson.ibm.com]

Ref:  Your note of Thu, 31 Oct 1996 19:06:38 -0500

I insist with my previous recommendation.
Define hmac-sha to output 128 bits (out of the final 160 bits result).
It most probably help security and saves up to 64 bits
in 64-bit alignments.

Hugo

PS: I am appending a message that I sent to the list a couple of months
ago on this issue. If anyone has a good reason against this recommendation
please send it to the list.


> Thus, I am proposing that instead of padding the 160 bits of SHA output
> to 192 bits, truncate the result to 128 bits.
>
> Beyond the advantage for bandwidth, this truncation is plausible to
> add to the security.
>
> In general, it is an old practice to truncate MACs. In the context
> of keyed-hash this has been explicitely proposed by Preneel and van
> Oorschot (Crypto'95). I do not know of any *proof* that
> truncating adds to the security. However, there are examples of attacks where
> this is the case. And as long as you do not truncate "too much"
> then everything indicates that it helps. In particular, I know of no
> reason how or why truncating HMAC-SHA to 128 bits would hurt in any scenario.
>
> Note: Be careful not to get confused with the unkeyed uses of SHA.
> There, collision resistance is usually the sacred goal and truncating the
> output HURTS HURTS HURTS (because of birthday attacks).
> For keyed-hash for message authentication the story is very different.
> Actually, the justification for truncation in [PV] is *exactly*
> because it helps *against* birthday attacks.
> (Yes, I know it sounds confusing but that's the way it is...)
> Still in the application of HMAC the 160 bits in the definition of SHA help
> as the length of the *intermediate* results of the compression function,
> but not as the final result.
>
> ANyway, truncation as a general method has an advantage (less information
> available to the adversary) and a disadvantage (less bits to predict for the
> attacker). When truncating 160 to 128 the advatage is far more significant
> than the disadvantage (It would be different if we truncated to 64 bits;
> that would make me uncomfortable -- 80 bits for SHA or even for MD5 are my
> "personal minimum".)
>
> BTW, in the RFC on HMAC that I am submitting to the IETF there is a section
> on truncation of HMAC output.
>
> ----------
>
> The patent issue:
>
> There is a patent by Novell (US 5349642) that claims keyed hash functions
> for message authentication. Such claim would cover (I am not a lawyer!)
> all hash based schemes that have ever been suggested in this WG, including HMA
> Fortunately, the filing date of that patent is Nov 3 1992, while
> Gene Tsudik's paper proposing such functions appeared in Infocom in May 1992.
> (This work is also part of Gene's UCLA's PhD dissertation of May 1991).
>
> The one element that does not appear in Tsudik's work is truncation.
> However, truncating the output of MAC functions is an old and very well
> known practice in cryptography. For example,
>
> [MM]    Meyer, S. and Matyas, S.M., Cryptography, New York Wiley, 1982.
>
> [ANSI]  ANSI X9.9, ``American National Standard for Financial
>         Institution Message Authentication (Wholesale),'' American
>         Bankers Association, 1981.   Revised 1986.
>
> and therefore a hard to defend claim (I'm not a lawyer!!).
>
> After consulting with Jeff Schiller and the WG chairs, it became clear
> to me that the existence of Novell's patent shouldn't be an obstacle to
> include a section on truncation in the HMAC rfc, and more significantly,
> to propose it for adoption for AH-HMAC-SHA.
>
> Hugo
>

---

• Prev by Date: ISPEC docs in AFS
• Prev by thread: ISPEC docs in AFS
• Index(es):
  • Main
  • Thread