Home/ Questions/Q 8716981
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T06:12:34+00:00

I’m developing a game in Java that will be packaged as an applet, and

  • 0

I’m developing a game in Java that will be packaged as an applet, and I’m working on the networking aspect. I’ve designed a session flow that will work for the frequency of requests and the security needs, without requiring the use of SSL. The data transmission process is loosely based off of the way facebook signs their signed_token used with their OAuth process. Here’s the simplified context:

  • my php/java implementations use hash_hmac/javax.crypto.Mac to generate an obscured signature for signing a payload, based on a shared, secret, unique token and a varied JSON payload
  • both outputs have to match exactly, because they’re part of a larger encode/decode compression scheme
  • this signature will be passed through URL with the payload, and is used to verify the payload for validity and integrity

As you can infer, if they don’t match, then I have dropped packets of data and errors due to invalid data sent. My issue is that, while the hex encoding of the result matches perfectly, the raw binary doesn’t seem to ever match. Below are the extracted php and Java test cases I set up:

Note: Because of the differences in how php and java generate the JSON structure for php associative arrays / java hashmaps, I’m using the value of the secret in place of the string payload so that both fields are consistent between platforms.

Php:

$secret = "922ec205d8e4d0ea06079d60a5336fffd9cf0aea";
$json = $secret; //json_encode($test_array);
$hmac_a = hash_hmac('sha256',$json,$secret);
$hmac_b = hash_hmac('sha256',$json,$secret,$raw=true); 
echo(htmlentities($hmac_a)."<br/>\n");
echo(htmlentities($hmac_b)."<br/>\n");

In-browser output:

ff21a9e468ac49863e5e992324ac8bc92f239a08100b0f329b087be16f5ad382

ÿ!©äh¬I†>^™#$¬‹É/#š2›{áoZÓ‚

Java:

Mac hmac = Mac.getInstance("HmacSHA256");
SecretKeySpec secret_key = new SecretKeySpec(Charset.forName("UTF-8").encode(this.secret).array(), "HmacSHA256");
hmac.init(secret_key);
byte[] digest = hmac.doFinal(this.secret.getBytes("UTF-8"));
System.out.println(hexify(digest));
System.out.println(new String(digest,"UTF-8"));

Console output:

ff21a9e468ac49863e5e992324ac8bc92f239a08100b0f329b087be16f5ad382

�!��h�I�>^�#$���/#� 2� {�oZӂ

When copied to php and told to echo, that second string looks like this:

:�!��h�I�>^�#$���/#���2{�oZӂ

Note that while the hex is identical, the binary is different, but contains the same ending ( oZÓ‚ ) when displayed from the same source. Actually, it contains all of the more common characters (!hI>^#$/#2{oZÓ,) in order. I played around with copying the console output to php then displaying as a binary string, regular string, utf8_encode’d binary/regular string, and also utf8_encode’ing $hmac_b. Nothing seems to make the raw versions match up.

I’ve run mb_detect_encoding on php’s hmac, and it told me UTF-8. I’ve also set everything in javax.crypto.Mac to UTF-8, and displayed as UTF-8, but no dice. I know Java’s UTF-8 isn’t different than php’s UTF-8, because that defies the concept of having standard character sets. What’s going on here?

Note: While I now prefer and am able to use the hex version for URL encoding, I’d still like to know what’s going on with this character set nonsense, and possibly how to fix it.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’m no Java expert, but it looks like you’re doing two different things…

    You are using htmlentities() in PHP, which is converting characters like ÿ to &yulm;, whereas your Java snipped is trying to dump out UTF-8 data.

    Why are you actually expecting valid UTF-8 data after a HMAC? UTF-8 is for representing Unicode characters, not random hashes.

    Using this in PHP:

    $secret = "922ec205d8e4d0ea06079d60a5336fffd9cf0aea";
$json = $secret;
$hmac_a = hash_hmac('sha256',$json,$secret);
$hmac_b = hash_hmac('sha256',$json,$secret,$raw=true); 
echo $hmac_a . "\n";
echo $hmac_b . "\n";

    I get the following (in a UTF-8 aware terminal):

    ff21a9e468ac49863e5e992324ac8bc92f239a08100b0f329b087be16f5ad382
�!��h�I�>^�#$���/#2{�oZӂ

    This is entirely expected. $hmac_b is effectively binary being interpreted as UTF-8, so it will be full of invalid UTF-8 sequences. Don’t expect it to be characters. You will be better looking at it in as ISO-8859-1 output, which isn’t multibyte:

    ff21a9e468ac49863e5e992324ac8bc92f239a08100b0f329b087be16f5ad382
�!��h�I�>^�#$���/#ï¿2ï¿{�oZÓ

    (There’s also a control character on the end of that output \x82)

    The point is, you’re comparing apples with oranges in pear packaging.

    • 0