[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:

..(deleted)
...

Date: Thu, 31 Oct 96 19:52:21 EST
To: IPSEC@TIS.COM
Cc: rob.glenn@nist.gov, shu-jen.chang@nist.gov
Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-sha-03.txt
Sender: ipsec-approval@neptune.tis.com
Content-Length: 3592

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.

-------------

Krawczyk, et. al.            Informational                      [Page 4]

RFC 2104                          HMAC                     February 1997


5. Truncated output

   A well-known practice with message authentication codes is to
   truncate the output of the MAC and output only part of the bits
   (e.g., [MM, ANSI]).  Preneel and van Oorschot [PV] show some
   analytical advantages of truncating the output of hash-based MAC
   functions. The results in this area are not absolute as for the
   overall security advantages of truncation. It has advantages (less
   information on the hash result available to an attacker) and
   disadvantages (less bits to predict for the attacker).  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).  We propose denoting a realization of HMAC
   that uses a hash function H with t bits of output as HMAC-H-t. For
   example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
   and with the output truncated to 80 bits.  (If the parameter t is not
   specified, e.g. HMAC-MD5, then it is assumed that all the bits of the
   hash are output.)
...

References

   [ANSI]  ANSI X9.9, "American National Standard for Financial
           Institution Message Authentication (Wholesale)," American
           Bankers Association, 1981.   Revised 1986.

   [MM]    Meyer, S. and Matyas, S.M., Cryptography, New York Wiley,
           1982.

   [PV]    B. Preneel and P. van Oorschot, "Building fast MACs from hash
           functions", Advances in Cryptology -- CRYPTO'95 Proceedings,
           Lecture Notes in Computer Science, Springer-Verlag Vol.963,
           1995, pp. 1-14.

End of include message
----------------------------------

Hope this helps to understand the question.


		Luis Saiz

---------------------------------------------------------------------

Protocol cryptanalysis is essentially formalized paranoia.

G. Simmons.

---------------------------------------------------------------------