Re: replay field size

["Theodore Y. Ts'o" <[e-mail]>]

   From: "Niels Ferguson" <[e-mail]>
   Date: Wed, 12 Feb 1997 18:30:37 +0100

   What are the requirements? I havn't been part of the IPsec discussion, and
   I don't have very much time to spend on it, but this seems to be fairly
   fundamental.....

   BTW, if the hash is used to ensure message integrity, and there is a
   separate MAC to ensure authenticity, then you could eliminate the hash. A
   MAC provides integrity verification as well, but it doesn't help you
   distinguish between a integrity violation and a key-mismatch. Unless
   precise error reporting is very important, you could leave the hash out.
   Furthermore, the MAC is more efficient, as it requires half as many bits to
   provide the same security level (assuming the key is secret of
   course).

The fact that you haven't been following the IPsec discussion is pretty
obvious now.  (Although I apologize for the loose use of terminology
which has obviously confused you.)

Note that what we're talking about is HMAC SHA --- so we *are* talking
about a MAC, not just a hash.  See draft-ietf-ipsec-ah-hmac-sha-04.txt
for more details.  It is computed by as follows:

	HMAC-SHA(K, text) = SHA (K XOR opad, SHA (K XOR ipad, text))

where ipad is the byte 0x36 repeated 64 times, and opad is the byte 0x5C
repeated 64 times.

The question is whether or not we should truncate the value returned by
the SHA in the above question to 128 bits or not.  Hugo Krawczyk, a
cryptographer from IBM, has made the claim that in this case, truncating
the hash result is a *good* thing, because (a) since it is a MAC,
birthday attacks aren't an issue (as you commented because it only
requires half as many bits), and (b) it denies information to an
attacker who is trying to perform an analytic attack on the MAC.

						- Ted