[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: HMAC-IP (Truncated HMAC-SHA)
>
> 2. HMAC-SHA IP Authentication with Replay Prevention
> <draft-ietf-ipsec-ah-hmac-sha-01.txt>
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by August 20, 1996.
I propose the following change to the above draft (page 6).
Replace:
> (7) apply SHA to the stream generated in step (6)
> (8) The sender then zero pads the resulting hash to a 64-bit boundary
> for word alignment. The receiver compares the generated 160-bit hash
> to the first 160-bits of authentication data contained in the AH.
With:
(7) apply SHA to the stream generated in step (6) and output the first
(leftmost) 128 bits of the result.
--------
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 HMAC.
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
PS: In the next weeks I will be reading e-mail very sporadicly (like,
maybe, once each two weeks :), so do not get angry if I do not respond
(especially after Tuesday).
Follow-Ups: