At 5:08 PM -0800 3/8/11, Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 3:55 PM, Peter Gutmann
<pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz> wrote:
Martin Rex <mrex(_at_)sap(_dot_)com> writes:
Truncating HMACs and PRFs may have become first popular in the IETF within
IPSEC.
It wasn't any "may have become first popular", there was only room
for 96 bits
of MAC data in the IP packet, so MD5 was truncated to that size.
This is an odd claim, since:
(a) RFC 1828 (http://tools.ietf.org/html/rfc1828) originally specified
not HMAC but a keyed MD5 variant
with a 128-bit output.
(b) The document that Martin points to has MACs > 96 bits long.
Can you please point to where in IP there is a limit that requires a
MAC no greater than 96 bits.
-Ekr
What Peter probably meant to say was that IPsec chose to truncate the HMAC
value to 96 bits because that preserved IPv4 and IPv6 byte-alignment for
the payload. Also, as others have noted, the hash function used here is
part of an HMAC calculation, and any collisions have to be real-time
exploitable to be of use to an attacker. Thus 96 buts was viewed as
sufficient.
Steve
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf