Re: AH padding after MD5/SHA1 hash value

[Bart Preneel <Bart.Preneel@xxxxxxxxxxxxxxxxxxx>]

I just want to point out that the 96 bits was chosen as a compromise
(m = number of bits in the MAC, n is the number of bit of the hash):
  - increasing m makes a guessing attack more difficult
     (success probability of forgery is 2*{-m})
  - decreasing m makes a birthday attack (based on internal collisions)
      more difficult 
     (complexity of forgery is 2*{n/2} known text-MAC pairs and
       2*{n-m} chosen text/MAC pairs). 
  - m=96 has the advantage that it provides alignment. 

It is hard to compare two different attacks. And collecting 2**{64} 
known text/MAC pairs is far from feasible today.
Nevertheless, one can learn from this that - paradoxically - 
increasing m may reduce security (the intuition behind this is that 
one gives away more information). Especially in the case of MD5, 
I would advise against increasing m beyond 96.

For details: 
B. Preneel, P.C. van Oorschot, "On the security of iterated
Message Authentication Codes," IEEE Transactions on Information Theory, 
Vol. 45, No. 1, January 1999, pp. 188--199 (journal version of
our Crypto'95 paper).   

--Bart Preneel
-------------------------------------------------------------------------------
Katholieke Universiteit Leuven                       tel. +32 16 32 11 48
Dept. Electrical Engineering-ESAT / COSIC            fax. +32 16 32 19 86
K. Mercierlaan 94, B-3001 Heverlee, BELGIUM    

                           bart.preneel@esat.kuleuven.ac.be
                        http://www.esat.kuleuven.ac.be/~preneel
-------------------------------------------------------------------------------


On Tue, 13 Jun 2000, Jun-ichiro itojun Hagino wrote:

> 
> 	Correct me if I'm wrong.  I have a question about AH packet.
> 
> 	From what I understand from the wording in RFC240[234],
> 	- for sender side, it is not illegal to attach more than 96 bits
> 	  into authentication data field.  RFC2403 does not require us to
> 	  attach exactly 96bits.  It just say "truncated value using the
> 	  first 96 bits MUST be supported".  It is not clear to us whether
> 	  96bit truncation is the requirement, or not.
> 	  This seems odd while we call those AH algorithms as "HMAC-MD5-96".
> 	  If we do not require truncation to 96bits, why we call it "96"?
> 	- Due to the way the document is written, receiver side will not
> 	  notice even if the peer attaches more meat than 96 bits.
> 	  Inbound check is done like this:
> 	  (1) compute 128bit(MD5) or 160bit(SHA1) hash
> 	  (2) compare first 96bit with authentication data field
> 	  the receiving side will notice it only if it is picky about the
> 	  length of AH portion length.
> 
> 	We (KAME) have never noticed this during past interop events, since
> 	we only generate 96bit authentication data, and we do not care about
> 	too-long authentication data (we do reject too-short authentication
> 	data).  We noticed that a MAJOR implementation attach the whole
> 	160bits for HMAC-SHA1, and 128bit + 32bit padding for HMAC-MD5.
> 
> 	Now.  Why the document is written this way?  If my understanding is
> 	correct, (1) we allow junk data to be attached at the end of
> 	authentication data, and (2) we have no real requirement to check
> 	if the junk data is rewritten or not.  Even if man-in-the-middle
> 	rewrites junk data portion, we will never notice, and data exchange
> 	should go just fine.  But, this worries me.
> 
> 	Is it specwise okay if we reject any packet with longer-than-96bit
> 	authentication data?  I know that we will not be able to interop
> 	with the particular implementation mentioned above.  I hope more
> 	clarification to appear in the document.
> 
> itojun
> 
> 
> RFC2402 chapter 2:
> >    0                   1                   2                   3
> >    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   | Next Header   |  Payload Len  |          RESERVED             |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |                 Security Parameters Index (SPI)               |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |                    Sequence Number Field                      |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |                                                               |
> >   +                Authentication Data (variable)                 |
> >   |                                                               |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> RFC2403 chapter 2:
> >   HMAC-MD5-96 produces a 128-bit authenticator value.  This 128-bit
> >   value can be truncated as described in RFC 2104.  For use with either
> >   ESP or AH, a truncated value using the first 96 bits MUST be	<---
> >   supported.  Upon sending, the truncated value is stored within the	<---
> >   authenticator field.  Upon receipt, the entire 128-bit value is
> >   computed and the first 96 bits are compared to the value stored in
> >   the authenticator field.  No other authenticator value lengths are
> >   supported by HMAC-MD5-96.
>