Re: Last Call: HMAC-IP (Truncated HMAC-SHA)

William Allen Simpson <wsimpson@greendragon.com> Sun, 11 August 1996 21:44 UTC

Date: Sun, 11 Aug 1996 21:37:26 +0000
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5409.wsimpson@greendragon.com>
To: iesg@ietf.org
Cc: ipsec@TIS.COM
Subject: Re: Last Call: HMAC-IP (Truncated HMAC-SHA)
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

I had proposed shortening the length of the SHA output last winter.

However, there was strong consensus on the ipsec-dev list that multiple
lengths be supported.  And thus, the language in draft-simpson-ah-sha-
kdp-00.txt.  I urge these authors to insert this facility in their draft:

   Therefore, several options are available for data alignment (most
   preferred to least preferred):

   1) only the most significant 128-bits (16 octets) of output are used.

   2) an additional 32-bits (4 octets) of padding is added before the
      SHA1 output.

   3) an additional 32-bits (4 octets) of padding is added after the
      SHA1 output.

   4) the SHA1 output is variably bit-positioned within 192-bits (24
      octets).

   The size and position of the output are negotiated as part of the key
   management.  Padding bits are filled with unspecified implementation
   dependent (random) values, which are ignored on receipt.

   Discussion:

      Although truncation of the output for alignment purposes may
      appear to reduce the effectiveness of the algorithm, some analysts
      of attack verification suggest that this may instead improve the
      overall robustness [PO95a].

   ...
   [PO95a]  Preneel, B., and van Oorshot, P., "MDx-MAC and Building Fast
            MACs from Hash Functions", Advances in Cryptology -- Crypto
            '95 Proceedings, Santa Barbara, California, August 1995.



> Date: Fri, 9 Aug 1996 23:37:23 +0200 (METDST)
> From: Bart Preneel <Bart.Preneel@esat.kuleuven.ac.be>
> I would not even see a problem to shorten the SHA-1 output to
> 64 bits.  When considering attack scenarios, I would be much more
> worried about an attacker who uses the known text-MAC pairs to
> obtain information on the key than about an attacker who tries to
> predict some bits to forge a MAC for two reasons:
>  - a key recovery is more serious than a forgery
>  - for concrete hash functions such as MD5 and SHA-1, I feel
>    that the first attack is more likely (just intuition).
>

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Re: Last Call: HMAC-IP (Truncated HMAC-SHA) H.Krawczyk
Re: Last Call: HMAC-IP (Truncated HMAC-SHA) Bart Preneel
Re: Last Call: HMAC-IP (Truncated HMAC-SHA) William Allen Simpson