PHP Client

Issue #8 resolved
Keith Wagner created an issue

Simon - I am attempting to create a working PHP client to work with your thinbus-php server. I'm getting as far as a matching calculation for "u" but I can't derive matching "S" values. Do you see a problem here:

$u = new BigInteger($this->hash($this->Astr . $this->Bstr), 16); $x = new BigInteger($this->hash($this->salt . $this->hash($this->password)), 16); $kgx = $this->k->multiply($this->g->powMod($x, $this->N)); $aux = $this->a->add($u->multiply($x)); $S = $this->B->subtract($kgx)->powMod($aux, $this->N);

Comments (5)

  1. simon repo owner

    The way that I would approach debugging this is to write a php unit test where I can inject a particular random number. Take a look at the code in ThibusTest.php where I use "notRandomNumber" for this purpose. Then I would git clone the original thinbus-js-srp project and get a dump of the random, public, and interim values from the original test.

    To get the values from an original test uncommented out all the "console.log" statements in thinbus-srp6client.js. Then I would run the java build with "mvn test" and it will print out the "console.log" statements. The Java build runs a JavaScript test "testMutualAuthentiation" in the file TestSRP6JavascriptClientSessionSHA1.js which does an end-to-end flow. It has commented out "println" statements which you can put back in. You can delete the other Test*.js files to speed thing up and reduce the noise.

    Once you have a dump of the random numbers of a working test you can plug them into your new test. Print out all the values you new test uses and compare with all the random, public and interim values of the original test and you will find the problem. You will also have the JavaScript code running to within the original test to compare statement by statement with your new code.

    (Note that there is a SHA256 test but it doesn't have commented out println statements but clearly that's a trival change to make).

  2. Keith Wagner reporter

    Thanks Simon! Building up a matching Java client to this project wasn't what I was looking to do. Since I was building both sides in PHP, it was fairly straight forward to debug each side as it goes through the equations. With some work, I finally got it working!!!!

    I have attached a working PHP Client SRP6a Class. I could probably work on a few test cases if that might help others. Anybody can feel free to email me: kw at AmericanLinux dot com

    Keith

  3. simon repo owner

    Hi Keith,

    Great work!

    I have committed your code with some minor modifications as ThinbusSrpClient in commit 0795f5c.

    I upgraded the way generateX works to be RFC 2945 compliant. That specification hashes userID into the password as well as the salt. That makes things slightly more secure under certain failure modes at the cost of having to generate a new verifier if the user changes either their email address or their password.

    It also means that the PHP client code matches the JavaScript and Java versions. This ensures that verifiers created with any of those languages should be able to login users using any of the other language. Then people can generate a temporary password and verifier in PHP, email out the temporary password, and have the users login using the temporary verifier using a browser.

    If you upgrade your deployment to use the version I committed you will need to have your users regenerate their verifiers so that it has the userId hashed into it. I also change the method sigs slightly to match the other languages (such as the ability to specify whether or not to hash the session key).

    Thanks!

    Simon

  4. Log in to comment