RFC 2857 (rfc2857) - Page 2 of 7


The Use of HMAC-RIPEMD-160-96 within ESP and AH



Alternative Format: Original Text Document



RFC 2857          HMAC-RIPEMD-160-96 within ESP and AH         June 2000


   In this memo, HMAC-RIPEMD-160-96 is used within the context of ESP
   and AH.  For further information on how the various pieces of ESP -
   including the confidentiality mechanism -- fit together to provide
   security services, refer to [ESP] and [Thayer97a].  For further
   information on AH, refer to [AH] and [Thayer97a].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].

2. Algorithm and Mode

   [RIPEMD-160] describes the underlying RIPEMD-160 algorithm, while
   [RFC 2104] describes the HMAC algorithm.  The HMAC algorithm provides
   a framework for inserting various hashing algorithms such as RIPEMD-
   160.

   HMAC-RIPEMD-160-96 operates on 64-byte blocks of data.  Padding
   requirements are specified in [RIPEMD-160] and are part of the
   RIPEMD-160 algorithm.  Padding bits are only necessary in computing
   the HMAC-RIPEMD-160 authenticator value and MUST NOT be included in
   the packet.

   HMAC-RIPEMD-160-96 produces a 160-bit authenticator value.  This
   160-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 160-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-RIPEMD-160-96.

   The length of 96 bits was selected because it is the default
   authenticator length as specified in [AH] and meets the security
   requirements described in [RFC 2104].

2.1  Performance

   [Bellare96a] states that "(HMAC) performance is essentially that of
   the underlying hash function".  [RIPEMD-160] provides some
   performance analysis.  As of this writing no detailed performance
   analysis has been done of HMAC or HMAC combined with RIPEMD-160.

   [RFC 2104] outlines an implementation modification which can improve
   per-packet performance without affecting interoperability.






Keromytis & Provos          Standards Track