HMAC cryptojs client and JAVA on server

Not applicable

Hi All,

We are using Crypto-js on client and Apigee Proxy and everything works fine.

We are in process of implementing JAVA HMAC on server. (using JAR frhttps://github.com/apigee/iloveapis2015-hmac-httpsignature/tree/master/hmac/calloutI).

HMAC created by Crypto-JS and HMAC created by hmac-edge-callout.jar are different.

Please advice

0 10 3,721
10 REPLIES 10

you want to create or verify HMAC in the api proxy?

what do you mean by implementing JAVA HMAC on server? - are you refererring to the javacallout in the proxy?

is it the encoding? are you comparing the same encoding [hex or base64] with js and java?

Not applicable

Thank you Madhavan.

I would like to verify the HMAC created in Javascript in JAVA call out .

Please find below code I use

JS code:

 apiSecret= CryptoJS.enc.Utf8.parse(apiSecret);
 data = CryptoJS.enc.Utf8.parse(data);
// var hashSign = CryptoJS.HmacSHA512(data, apiSecret);
 var hashSign = CryptoJS.HmacSHA512(data, apiSecret).toString(CryptoJS.enc.Hex);

JAVA Code:

         Mac hmac = Mac.getInstance(javaizedAlg);
            SecretKeySpec key = new SecretKeySpec(signingKey.getBytes(), javaizedAlg);
            hmac.init(key);
            byte[] hmacBytes = hmac.doFinal(stringToSign.getBytes("UTF-8"));
            String sigHex = Hex.encodeHexString(hmacBytes);
            String sigB64 = Base64.encodeBase64String(hmacBytes);

assuming,

javaizedAlg=HmacSHA256

signingKey=apiSecret

stringToSign=data

then hashSIgn should be == sigHex, is it not the case?

please find below code which we use in the java call out. hmac.alg SHA-512 hmac.javaizedAlg HmacSHA512

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <JavaCallout async="false" continueOnError="false" enabled="true" name="JC-Verify-HMAC"> <DisplayName>JC Verify HMAC</DisplayName> <Properties> <!-- name of the variable that holds the key //{verifyapikey.verify-api-key.client_secret}--> <Property name="key">{verifyapikey.verify-api-key.client_secret}</Property> <Property name="algorithm">SHA-512</Property> <Property name="string-to-sign"> {request.verb}{client.scheme}://{request.header.host}{message.uri}{request.content}{request.header.merchantId}{request.header.Nonce}{request.header.timestamp}</Property> <Property name="hmac-base64">{request.header.Authorization}</Property> <Property name="debug">true</Property> </Properties> <FaultRules> <FaultRule name="rule1"> <Step> <Name>RF-invalid-hmac</Name> </Step> <Condition>hmac.error != null</Condition> </FaultRule> </FaultRules> <ClassName>com.apigee.callout.hmac.HmacCreatorCallout</ClassName> <ResourceURL>java://hmac-edge-callout1.jar</ResourceURL> </JavaCallout>

Sorry about it. We are using SHA 512. in the call out we are sending the HMAC as authorization header and sigHex is not matching the Authorization header.

hmac.algSHA-512
hmac.javaizedAlgHmacSHA512

Can you please send me sample code which works on Crypto-js . May be iam doing wrong.

js

> secret = c.enc.Utf8.parse('abcd')
{ words: [ 1633837924 ], sigBytes: 4 }
> data = c.enc.Utf8.parse('abcd')
{ words: [ 1633837924 ], sigBytes: 4 }
> c.HmacSHA512(data,secret).toString(c.enc.Hex)
'c8c20e325ab11f24e7e2babbefd25397c2a63e61ab4e047e2251a70194059872ff3cb0ae9379284296b84640f484e85d538b4781159ed7734aa5787bb0711112'
> c.HmacSHA256(data,secret).toString(c.enc.Hex)
'e1a20dce13e4953e3d50e7f6651a0ce862a655fc84c35352447eff99a5a02852'

java

		Mac hmac = Mac.getInstance("HmacSHA256");

		SecretKeySpec key = new SecretKeySpec("abcd".getBytes(), "HmacSHA256");

		hmac.init(key);

        byte[] hmacBytes = hmac.doFinal("abcd".getBytes("UTF-8"));

        System.out.println( bytesToHex(hmacBytes));

just make sure, the alg is 256 in both or 512 in both

Not applicable

Can someone please help me.

Hey @Pradeep Ande, I took a close look at your policy, you may want to try removing the leading space on this line:

<Property name="string-to-sign"> {request.verb}...
                                ^

Not applicable

@Kurt Kanaskie, That works you nailed it.. .Thank you and appreciate it...

@Mukundha Madhavan Thank you for your assistance.