Best practice for sending a signature hash between java & javascript?

S. Dale Morrey sdalemorrey at
Thu Apr 17 11:56:38 MDT 2014

I'm working on a mobile API for something rather sensitive.
The first time a device connects each user generates an ECDSA keypair.
During all subsequent calls, an SHA256 hash is made of all the input
variables along with an nonce or timestamp.  The hash is then signed by the
ECDSA key.

I do this to ensure that the user is who they claim, and it also prevents
replay attacks, since each hash must be unique we also make sure it can
only be used once.

These hashes are byte arrays so I then hex encode them and add them to the
params of the request.
The method used is HTTP POST and I don't have multi-part form encoding
enabled, because the hex encoded byte array should be a perfectly valid
ascii string.

On the device I have a test suite that validates the hash and the signature.
The process is hash the input, encode the hash,  decode the hash check the
hash against the signature (which also just underwent the same process).

It validates just fine on the device.

However when I send the post request to the server,
I hex decode the strings back into byte arrays (for hash and sig) the sig
comes back as invalid (does not conform to spec).  Note that the sig is
checked for a number of attributes such as a leading byte 0x30 etc.  This
is where it is failing.  The webserver never even gets the chance to
validate that the signature matches the publickey.

Now it's important to note that the mobile device is android and thus using
java, while the web service is written in node and uses the npm ecdsa
package.  Nevertheless I've looked at the algorithms for decode and
signature checking and they appear to be the same to me.
Furthermore the ecdsa params are using the same named curve both on web and

To my mind this means the problem is in the serialization and transmission
steps.  Even though the strings look identical when I view them (I have
data logging on the device and server logs on the server), something must
be getting munged.

One alternative I had considered is using multi-part forms and base 64
encoding but that seems like overkill and later the mobile API might be
used for more limited platforms where multi-part forms may not be available.

Does anyone have some suggestions?  This just seems to me like a problem
that must've been solved years ago.


More information about the PLUG mailing list