This text focus not on the solution for the challenge, but on the point of the challenge itself.
As soon as I completed #38 I checked others solutions, as I didn't feel like I grasped everything this challenge offered. It turned out that I went very close to others path: confusion, modular math, seeking the point of the challenge. And when I was out of things to squeeze out it, tried to find a more reasonable solutions...
This time without examples, since people could be quite defensive regarding their solutions. But let's get to the questions: what are we really asked to do in this one.
So in the end of the day I concluded that I mostly miss the point of the challenge.
I was puzzled why was it proposed to play with b value, as it's private. And then found a very suitable link which makes things very explicit. (Kudos to the one who left this link in his solution.)
Most of my solution was based on "simplifications" using modular arithmetic. But... It doesn't make sense to play with the parameters, as dictionary attack doesn't rely on it at all. (The confusion that is found in many solutions...)
After reading the linked section it turns out that it's expected not to simplify calculations with parameters, but to pass the server validity check (an example), without which the dictionary attack would be plainly impossible, since the client would reject guesses!
My previous solution already traveled this path: for zero-key challenge I was required to comment out safeguards in the lib.
So in a more realistic setting most of simplifications would just lead to kind of "SrpAuthError::IllegalParameter".
PS
Good passwords are still able to save the day in many cases. From the first of SRP challenges I used a random password, which boiled down this one to brute force, keeping client pretty secure even with MITM.
Latest comments (0)