Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
Java 2.0.8, Java 2.1.0
-
Apache cxf 2.1.12 & 3.2.2-SNAPSHOT
Apache Santuario 2.0.8 & 2.1.0
WSS4j 2.2.x / 1.6.x packed with cxf
Description
in org.apache.xml.security.algorithms.JCEMapper, all HMAC Algorithms are specified with a "keylength" that equals the length of the Hash-Algorithms output.
eg.:
{{
algorithmsMap.put(
XMLSignature.ALGO_ID_MAC_HMAC_SHA1,
new Algorithm("", "HmacSHA1", "Mac", 160, 0)
);
}}
This is incorrect per specification:
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf
Chapter 2.3:
B Block size (in bytes) of the input to the Approved hash function.
H An Approved hash function.
Chapter 3:
_...When an application uses a K longer than B-bytes, then it shall first hash the
K using H and then use the resultant L-byte string as the key K0...
Chapter 4:
- If the length of K = B: set K0 = K. Go to step 4.
- If the length of K > B: hash K to obtain an L byte string, then append (B-L) zeros to create a B-byte string K0 (i.e., K0= H(K) || 00...00). Go to step 4.
- If the length of K < B: append zeros to the end of K to create a B-byte string K0 (e.g., if K is 20 bytes in length and B = 64, then K will be appended with 44 zero bytes x'00').
So the keysize of any HMAC may be of any size. Apache CXF and WSS4J in the Versions mentioned in the "Environment" Field, expect "keysize" to be 0 in this case.
Santuario returning 160 for HmacSHA1, leads to wss4j and cxf to trim any 24 byte key to 20 byte length and THEN continue to act according to NIST specification and pad 44 bytes of 0x00, which is bound to produce the wrong HMAC for any reciever who correctly uses the original 24 bytes and pads only 40 times 0x00.