The Use of HMAC-RIPEMD-160-96 within ESP and AH
Extracted elements (14)
A 160-bit key length was chosen based on RFC 2104 recommendations: keys shorter than the authenticator length decrease security strength, while keys longer than the authenticator length do not significantly increase security strength.
The 96-bit authenticator length was selected because it is the default authenticator length specified in the AH specification and meets the security requirements described in RFC 2104.
As of the time of writing, there are no known issues that preclude the use of HMAC-RIPEMD-160-96 with any specific cipher algorithm in ESP.
A strong pseudo-random function MUST be used to generate the required 160-bit key, per the guidance in RFC 1750.
For use with either ESP or AH, a fixed key length of 160 bits MUST be supported. Key lengths other than 160 bits SHALL NOT be supported.
Padding bits computed during HMAC-RIPEMD-160 authentication value computation MUST NOT be included in the packet.
HMAC-RIPEMD-160-96 is an authentication mechanism for use within IPsec ESP and AH. It combines HMAC (RFC 2104) with RIPEMD-160 to provide data origin authentication and integrity protection.
HMAC-RIPEMD-160-96 operates on 64-byte blocks of data. It produces a 160-bit authenticator value which is truncated to 96 bits for use in ESP or AH. The truncated value is stored in the authenticator field; upon receipt the full 160-bit value is computed and the first 96 bits are compared.
For a 64-byte block hash like HMAC-RIPEMD-160-96, a birthday attack would require successfully processing 2**64 blocks, making it infeasible unless the underlying hash had collisions after only 2**30 blocks.
If weak keys for HMAC are ever identified, their use must be rejected and replacement keys or a newly negotiated Security Association must be requested. At the time of writing, no weak keys for HMAC are specified.
RIPEMD-160 was not originally developed as a keyed hash algorithm, whereas HMAC was designed for that purpose from the onset. Truncation of the resulting hash provides additional security, and specifications using HMAC are strongly encouraged to perform this truncation.
Security depends on correctness of implementation, security of key management, strength of the secret key, and correctness of all participating systems. RFC 2286 contains test vectors and example code to verify HMAC-RIPEMD-160-96 implementations.
The security of HMAC-RIPEMD-160-96 is based on the strength of HMAC and, to a lesser degree, RIPEMD-160. At the time of writing there are no known practical cryptographic attacks against RIPEMD-160.
The authenticator field carries the first 96 bits of the HMAC-RIPEMD-160 output. Upon sending, the 96-bit truncated value is stored; upon receipt, the full 160-bit hash is recomputed and its first 96 bits are compared to the stored value.