paul at seamons.com
Thu Apr 17 12:54:41 MDT 2014
Backup a few steps. Sorry if this is basic - but brute force your way
Within both client and server start at the raw parameters, generate the
intermediates of your signature, compute the final signature. Output
the results of each of these steps and compare (translate raw bytes to
If the results don't match on client and server, your signing algorithm
isn't what you think. If it does match, you have a transport issue.
On 04/17/2014 11:56 AM, S. Dale Morrey wrote:
> 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.
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
More information about the PLUG