S. Dale Morrey
sdalemorrey at gmail.com
Thu Apr 17 13:04:42 MDT 2014
I believe that's what I am doing at present. I guess at least for testing
I can pass in the private key and see if the server creates the same
keypair as the client. Then sign the same message between them and compare
the sig hashes at each step. Probably need to do that as a unit test
anyways in case someone decides to muck with one of the libraries.
On Thu, Apr 17, 2014 at 12:54 PM, Paul Seamons <paul at seamons.com> wrote:
> 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 ordinal
> 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
>> 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
>> 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
>> 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
>> 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
>> 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.
> 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